Alguien me ha dicho que le gusta más cuando no hablo de política… y tiene razón, a mí también me gustaría hablar de muchas cosas, pero es que la situación actual no parece la propicia. Algo de lo que quería hablar en esta nueva etapa de mi blog es de administración de sistemas. Un tema sobre el que tengo bastante experiencia profesional, y cada día más :). Ya casi soy un BOFH en toda regla. Así que voy a dedicar una serie de artículos a las herramientas de monitorización en Linux/Unix, que nos ahorran gran cantidad de esfuerzo a los administradores. En el primero, haré una pequeña introducción, y en los siguientes, detallaré mi experiencia con algunas de ellas. Comencemos:

Una de las grandes ventajas de los sistema Linux (y en general de todos los Unix) para los administradores de sistemas es la facilidad en la configuración, la supervisión y manejo de los servicios. Todas la configuraciones se pueden hacer por consola y línea de comando, y las comprobaciones sobre el estado de los servicios se puden automatizar de forma muy sencilla. Cuando se empieza a mantener un sistema y se hacen los primeros pinitos en shell script, uno de los temas que se abordan es la posibilidad de vigilar determinados sistemas, para comprobar su correcto funcionamiento. Gracias a comandos como ps, pgrep, cat, etc. y sistemas como cron podemos poner en marcha fácilmente scripts que nos avisen en el caso de que un sistema deje de estar corriendo, o incluso que lo levante automáticamente.

Por ejemplo, si queremos vigilar que Apache está corriendo podemos hacerlo con un script, de la siguiente manera:

#!/bin/bash
PID=$(cat /var/run/httpd.pid)
if ! kill -0 $PID
then /etc/init.d/httpd restart
echo Apache recargado a las $(date)
else
echo “Apache en orden”
fi

Básicamente este script lo que hace es comprobar el pid del proceso padre de Apache (reflejado en el fichero /var/run/httpd.pid). Si este proceso está corriendo, no hace nada, pero si no pues manda reiniciar el proceso. Por supuesto tiene que ejecutarse como root, y para automatizarlo, una buena manera es llamarlo desde cron. Además una de las cosas que hará de forma predeterminada en casi todos los sistemas es enviar un mail con la salida del comando a root, con lo que estaríamos sobre aviso del problema.

El caso es que este tipo de soluciones introducen un exceso de complejidad en los sistemas, ya que añaden piezas de código a mantener, son poco flexibles e inseguras. Si el demonio de cron es el que falla, entonces ¿quién se encarga de comprobar el de Apache? Para evitar estos problemas, hay varia soluciones, independientes de cron, sencillas de configurar y con mucha tradición en sistemas Unix. Una de ella son las daemontools de D.J. Bernstein, creador de QMail, djbdns y muchas otras piezas maestras del software seguro y de calidad. Personalmente, aunque me gusta su software, no suelo recomendar estas soluciones, porque tenemos otras disponibles, menos complejas y más flexibles, aunque sean un poco menos seguras. Es el caso de monit.

Monit es de esos sistemas a los que podrías llegara confiar tu vida. En pocas líneas de configuración (que normalmente podrás copiar y pegar de los ejemplos de la web o tras una búsqueda por internet) puesdes estar monitorizando decenas de servicios. En los que no sólo compruebas que funcionan, sino que además lo hacen correctamente. En el caso de que no lo hagan puedes definir un comportamiento razonable (como levantar el servicio tras varias comprobaciones, o simplemente avisar). Además tiene un interfaz web para ver el estado de los servicios, que es accesible a través de red local, internet o incluso desde un teléfono móvil. Y te avisa en todo momento de las dificultades que puedan surgir mediante el correo electrónico, o cualquier tipo de software de envío de mensajes con el que puedas crear una interfaz de comunicación. Básicamente es una pequeña maravilla, incluido con casi todas las distribuciones modernas.

Veamos el aspecto que tiene un ejemplo de monitorización real, de un servidor de correo IMAP, que yo mismo estoy usando:

check process imapd with pidfile /var/run/imapd.pid
group mail
start program = “/etc/init.d/courier-imap start”
stop program = “/etc/init.d/courier-imap stop”
if failed host 127.0.0.1 port 143 protocol IMAP then restart
if failed host 127.0.0.1 port 993 type TCPSSL protocol IMAP then restart
if 5 restarts within 5 cycles then timeout

en lenguaje llano, este ejemplo hace lo siguiente:

Primero comprueba que el proceso correspondiente al fichero de pid de imapd está corriendo. Asigna esta comprobación al grupo mail de los chequeos. Define cuales son los comandos que arrancan y paran el proceso. Y comienza a definir las pruebas que debe hacer para asegurarse de que todo funciona correctamente. En este caso hace una conexión plana, de protocolo IMAP al puerto 143 del ordenador local, y si no responde reinicia el proceso. La segunda comprobación es bajo SSL al puerto de IMAP-SSL, si no corre, reinicia. Finalmente advierte de que si, tras 5 reinicios en 5 ciclos de ejecución, no se levanta correcta y adecuadamente el servicio, debe dar un error de tiempo de espera agotado. En este caso informaría por correo electrónico, tanto si cambia el pid de un proceso vigilado (por ejemplo en un reinicio independiente de monit), si el proceso ha tenido que ser reiniciado, o si tras la serie de reinicios programados se niega a levantarse.

Como vemos, una sencilla herramienta, que puede ser muy potente, haciendo todo tipo de comprobaciones estándar, que saben de protocolos, o bien diseñadas por nosotros mismos, llamando a programas o scripts externos que, por ejemplo, traten de recuperar un correo-e de prueba mediante IMAP de un usuario del sistema. De esta forma se comprobaría que todo el sistema funciona de forma correcta.

En próximas entregas hablaré de otro software de monitorización muy interesante, como es nagios. Y de software de vigilancia gráfica, como cacti y otras aplicaciones basadas en los abuelos rrdtool y MRTG.

Compártelo:

Haz TrackBack de este Post | Suscríbete a los comentarios utilizando el Feed RSS