1 de 7 03/09/2007 12:16 p.m. Monitorización de servicios con mon 17-12-2003 por Sneb Introducción mon es un demonio que nos permite monitorizar servicios de nuestra red (tales como http, nntp, ftp, smtp, pop, etc). Los resultados pueden ser visibles a través de un interfaz web, y podemos configurarlo para recibir contingencias o alarmas a través de correo electrónico. Es un programador de propósito general para monitorizar la disponibilidad de servicios y lanzar alarmas cuando se producen fallos. Está diseñado con una arquitectura abierta, para facilitar la monitorización de nuevos servicios gracias a un interfaz común que puede ser implementado en diferentes lenguajes (C, Perl, shell, etc), señales SNMP y paquetes UDP específicos de mon. Cuando arrancamos el planificador mon, se lee un fichero de configuración que necesita para determinar los servicios que necesitará el monitor. El fichero de configuración por defecto es /etc/mon/mon.cf, pero se puede especificar otro si lo indicamos con la opción -c. Despues, el planificador entra en un bucle en el que se manejan las conexiones de los clientes, invocaciones al monitor y las alertas por fallos. Definiciones monitor periodo alarma hostgroup service Un programa que comprueba una cierta condición, devuelve verdadero o falso, y que opcionalmente produce una salida que puede ser procesado posteriormente por el planificador. Corrientemente los monitores detectan la disponibilidad del host a través de mensajes de eco ICMP o por conexiones a servicios TCP Un periodo de tiempo que será interpretado por el módulo Time::Period. Un programa que envia un mensaje cuando es llamado desde el planificador. El planificador hace saltar la alarma cuando detecta un error en un monitor. Cada alarma acepta una serie de argumentos desde la línea de comandos, además de los que vengan de la entrada estándar. Un host único o grupo de host, especificados por su nombre o por su dirección IP. Un conjunto de parámetros usados para lidiar con la monitorización de un recurso de un hostgroup. Los servicios se modelan habitualmente detrás de servicios como servidores SMTP, ecos ICMP, disponibilidad de espacio de disco en el servidor, o eventos SNMP.
2 de 7 03/09/2007 12:16 p.m. watch Vigilante: Un conjunto de servicios que se aplican a un grupo concreto. Instalación Es áltamente recomendable instalar el monitor en una máquina dedicada, a fin de que interfiera lo menos pasible en los resultados de los servicios monitorizados. Obviamente si la máquina donde están los servicios a monitorizar y el propio monitor son la misma, y esta se cae, no recibiremos los avisos, bien sean por correo eléctronico o por visualización en pantalla. Comentaré brevemente la instalación en debian Sid, que veremos que tiene una pequeña pega, aunque está prefectamente documentado en la nota que podemos leer en /usr/share/doc/mon/readme.debian. En el resto de distribuciones deberá procederse de la manera habitual de instalar software. Bueno, pues lo típico: apt-get install mon Si queremos usar el interfaz web para ver los resultados deberemos tener instalado un servidor web con soporte para servir CGI s. Aquí es donde tendremos problemas, porque la configuración por defecto de debian no deja el cgi en el directorio de donde apache los toma por defecto. Habrá que hacer un enlace simbólico del cgi monshow al directorio /usr/lib/cgi-bin de apache: cd /usr/lib/cgi-bin ln -s../../bin/monshow /usr/lib/cgi-bin A partir de entonces, podemos arrancar y parar el monitor con los típicos /etc/init.d/mon start y /etc/init.d/mon stop. Y de la misma forma recargar la configuración si hemos hecho cambios con /etc/init.d/mon reload. Configuración Tenemos un fichero de configuración por defecto en /usr/share/doc/mon/examples/mon.cf.gz. Tomando este como base nos podemos hacer una idea de las posibilidades del programa y es muy fácil adaptarlo a nuestras necesidades. Lo primero es copiarlo (descomprimido) a /etc/mon/mon.cf y a partir de ahí sacar ideas de lo que podemos hacer para monitorizar nuestros propios servicios. Las líneas que comienzan con se considerarán comentarios y no son procesadas. Opciones Globales Al principio nos encontramos con las definiones de opciones globales: global options cfbasedir = /usr/lib/mon/etc alertdir = /usr/lib/mon/alert.d mondir = /usr/lib/mon/mon.d maxprocs = 20 histlength = 100 randstart = 60s
3 de 7 03/09/2007 12:16 p.m. cfbasedir es el directorio raiz de nuestra configuración. Deberemos modificarlo para que apunte a /etc/mon/ que es donde hemos copiado nuestro fichero de configuración. alertdir es nuestro directorio de alarmas y mondir el directorio donde se encuentran los programas de monitorización. En debian no es necesario modificarlos. El parámetro maxprocs asigna un número máximo de procesos hijos que tendrá el monitor. Esto nos asegurará la aplicación ante situaciones incontroladas, normalmente provocadas por un fichero de configuración defectuoso, en las que el programa intanta hacer demasiadas cosas a la vez. El parámetro histlength es el máximo número de eventos que serán guardados en un fichero de históricos (este fichero puede ser asignado mediante la variable historicfile). El valor por defecto es 100 y puede ser modificado con la opción -k desde la línea de comandos. Cuando el servidor arranca, normalmente no todo deberá ser comprobado al mismo tiempo. Esto podría provocar retrasos antes de la primera comprobación y muy posiblemente una carga alta en el servidor si un montón de servicios han de ser monitorizados simultaneamente. Esta opción se usa para aleatorizar el arranque del primer test durante el arranque y despues de usar el comando reset. Si randstart está definido, no se arrancará el monitor hasta que haya pasado un tiempo aleatorio comprendido entre cero y randstart segundos. Autenticación A continuación el tipo de autenticación: authentication types: getpwnam standard Unix passwd, NOT for shadow passwords shadow Unix shadow passwords (not implemented) userfile "mon" user file authtype = getpwnam Se puede indicar una lista separada por espacios de tipos de autenticación a usar, que será comprobada en el orden dado por dicha lista. El tipo getpwnam, es el sistema de autenticación estandar de UNIX. Se compara la versión codificada con crypt de la password con la que nos da getpwnam. No funcionará si usamos shadow password en nuestro sistema. Si el tipo es userfile, entonces los nombres de usuario y las claves se leen de userfile, el cual puede ser definido mediante la variable de configuración userfile. El fichero consiste en una secuencia de líneas en el formato nombre-usuario : password. Password se almacena según el valor de hash retornado por la función de unix crypt. Nota: El formato de este fichero es compatible con el del fichero de usuario/password de apache, de manera que es posible usar htpasswd (que viene con apache) para manipular el fichero de usuarios de mon. Si el tipo es pam, entonces se usará PAM para la autenticación. Se usará el servicio global especificado por pam-service. En el arranque, se leerá el fichero especificado con la variable de configuración authfile. Este fichero define las restricciones que determinan los comandos que puede ejecutar un usuario. Veamos un ejemplo:
4 de 7 03/09/2007 12:16 p.m. command section list: all reset: root,admin loadstate: root savestate: root Significa que todos los clientes podrán ejecutar el comando list, root puede ejecutar reset, loadstate y savestate, y a admin se le permite el comando reset. Los hostgroups Los grupos de hosts nos servirán para agrupar máquinas que requieran de un servicio de monitorización similar, agruparlas bajo un seudónimo, y utilizarlo para simplificar la definición de monitores posteriormente. NB: hostgroup and watch entries are terminated with a blank line (or end of file). Don't forget the blank lines between them or you lose. group definitions (hostnames or IP addresses) hostgroup mailhost mail1 mail2 hostgroup workstations blue yellow red green hostgroup wwwservers www www2 hostgroup printers hp5si hp5c hp750c Como nos advierte el comentario, debemos dejar una línea en blanco al finalizar la definición de cada grupo de hosts, y lo mismo para los grupos watch que veremos despues. Vemos como por ejemplo hemos definido el grupo mailhost, y le agregamos las máquinas mail1 y mail2 (podríamos haberlas referenciado también por su dirección IP). Sobre ellas monitorizaremos los servicios smtp, imap y pop. Lo mismo para wwwservers, de este grupo nos interesa comprobar el servicio http. Los vigilantes Los vigilantes (watch) los definiremos para cada grupo de hosts que necesitemos. Cada entrada tendrá la siguiente sintaxis: Una línea watch con el nombre del hostgroup sobre el que se hará la monitorización. Dentro de esta, tantas secciones service como servicios queramos monitorizar, con sus parámetros propios. Dentro de cada servicio tantos periodos como deseemos que definirán las acciones a tomar en caso de alarma. Veámoslo con un ejemplo: watch wwwservers service ping description Ping para saber si la máquina está viva. interval 1m monitor fping.monitor period wd {Sun-Sat} alert mail.alert sneb@foobar.net alertevery 45m service http description Ver si el servicio http funciona. interval 1m monitor http.monitor
5 de 7 03/09/2007 12:16 p.m. period wd {Sun-Sat} alert mail.alert faro@blackhole.net upalert mail.alert -S "web is on alertevery 45m " sneb@foobar.net A las máquinas que hemos definido en el grupo wwwservers, les aplicamos dos monitores, uno de ping sólo para saber si la máquina está viva y otro de http para monitorizar este servicio propiamente dicho. Dentro de cada servicio hay una serie de parámetros: description interval Descripción breve, susceptible de ser utilizada por los programas cliente mediante su inclusión en mensajes de correo o en páginas web. Intervalo de tiempo que transcurrirá entre dos monitorizaciones de ese servicio. Se debe indicar la magnitud en que está expresado (s segundos, m minutos, h horas, d días). failure_interval Si un fallo persiste en el tiempo sin que le demos solución, el programa lanzará alarmas cada vez que expire el tiempo que hayamos definido en interval. Esto puede ser muy incómodo si no estamos en una consola del sistema en ese momento para arreglarlo. Imaginemos que hemos definido un vigilante con in intervalo de un minuto, y que nos envíe un correo electrónico a nuestra dirección de casa si hay un fallo. Esto enviaría un correo electrónico a nuestro buzón cada minuto si hay un fallo. Si no estamos leyendo el correo, nos podemos juntar con 120 correos en tan sólo 2 horas. Podemos ajustar el parámetro failure_interval para aumentar el periodo de comprobación en caso de fallos. interval 1m failure_interval 30m monitor Seguido del script que se ejecutará cuando el cronómetro que hemos especificado en interval se ponga a cero. Se le pueden pasar argumentos tipo shell. Al script se le pasará como último argumento las maquinas definidas en el watch en el que estemos trabajando, a no ser que terminemos la definición del monitor con ;; como una palabra separada. En este caso el grupo de hosts no será añadido a la lista de prámetros. period Esta acción provoca que el monitor sea invocado aún en el caso de que el grupo de hosts esté vacío por que las máquinas hayan sido deshabilitadas. Por defecto no se llamará al monitor si todas las máquinas se han deshabilitado. Un periodo agrupa una o más alarmas y variables que indican cómo de a menudo la alarma saltará cuando ocurra un fallo. El periodo puede especificarse de 2 formas, la primera especifica el perido de la manera de Patrick Ryan (Time::Period). Vea la función perl si quiere ampliar
6 de 7 03/09/2007 12:16 p.m. manera de Patrick Ryan (Time::Period). Vea la función perl perldoc Time::Period si quiere ampliar información o vea los ejemplos y ayúdese de esta tabla: Escala Código de Escala Valores posibles del rango Año (year) yr n donde n es un entero 0<=n<=99 ó n>1970 Mes (month) mo 1-12 ó jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec Semana (week) wk 1-6 Día del Año yd 1-365 Día del mes md 1-31 Día de la semana wd 1-7 ó su, mo, tu, we, th, fr, sa Hora hr 0-23 ó 12am 1am-11am 12noon 12pm 1pm-11pm Minuto min 0-59 Segundo (second) sec 0-59 diferentes sintasis para referirnos al invierno: jan feb nov dec} mo {Jan Feb}, mo {Nov Dec} mo {Jan Feb} mo {Nov Dec} Ahora un ejemplo un poco más complejo; Los lunes, miércoles y viernes, pero alternando semanas (una si y otra no), desde las 9 de la mañana hasta las 4 de la tarde: wk {1 3 5} wd {Mon Wed Fri} hr {9am-4pm} ts Los hosts que sigan no serán incluidos en la comprobación del servicio. exclude_period numalerts depend No ejecutar el monitor en ese periodo de tiempo. Por ejemplo parar el monitor de una base de datos los sabados de 2 a 5 de la mañana, porque es cuando se para para hacer backups. Esta opción limita el número de alarmas que saltarán ante un fallo. Este contador se resetea si una comprobación da positivo. Esta palabra clave se usa para especificar una expresión de dependencia, que será evaluada como verdadero/falso en el sentido booleano. Si se encuentra un error al evaluar la expresión, se loguea a través de syslog. Las expresiones del tipo grupo:servicio, son sustituidas por el valor del estado operativo actual del servicio especificado. Las sustituciones son comprobadas recursivamente, de tal manera que, si un servicio A depende de B, y B depende de C, entonces, el servicio A depende de C. Se considera que el servicio está activo (devuelve 1 ) en las situaciones: STAT_OK, STAT_COLDSTART, STAT_WARMSTART,y STAT_UNKNOWN. La palabra SELF se usa como clave para el grupo de monitorización actual. (SELF:service).
7 de 7 03/09/2007 12:16 p.m. Esta característica de mon puede ser útil para controlar alertas de servicios que dependen de otros servicios. Por ejemplo un test SMTP depende de que la máquina responda a los pings, o un servidor web puede depender de que el servidor de mysql para bases de datos esté arriba. alert upalert Un periodo puede contener muchas alarmas, las cuales son lanzadas cada vez que ocurra un fallo en el servicio. Acepta el parámetro exit en la forma exit=x y exit=x-y; esto hará que la alarma sólo salte si el error que devuelve el monitor está en el intervalo indicado. Las alarmas están (en debian) en /usr/lib/mon/alert.d. Conviene mirarlas todas para ver si se ajustan a nuestras necesidades. Aquí destacaré 2. mail.alert y file.alert. La primera nos mandará un informe de error a la dirección de e-mail que digamos. La segunda enviará el error a un fichero de log. Es complementario a alert. Se le llama cuando el estado del servicio pasa de ser negativo a positivo. Se suele pasar el parámetro -u para indicar al script de alarma que es un upalert. Interfaz de línea de comandos: moncmd moncmd nos permite enviar comandos al demonio mon y mostrar los resultados. - Esta entrada se esccribió el 17-12-2003 a las 19:21 y se archivó en las categorías Artículos. Puedes seguir las respuestas a esta entrada a través del feed RSS 2.0. Both comments and pings are currently closed. Un comentario a Monitorización de servicios con mon 1. 30-Aug-2004 a las 17:23 Robert nos cuenta: Hi, No se si tu ha tenido problema con el monitor process.monitor. No me funciona correctamente. Yo pongo en le mon.cf: process.monitor -c public y si mato el demonio example: httpd en el cgi or gui me aparece que esta en servicio. Yo puedo utilizar el comando snmpwalk -v 1 -c public machinename system y me aparace el resultado correcto. Si tu ha tenido este problema por favor mandame una respuesta. Package que utilizo son: net-snmp 5.0.8 Gracias por tu ayuda por adelantado.