Después de haber hablado un poco sobre la teoría de la monitorización tal y como la veo yo, sigo con la parte práctica. Como dice Pieter Hintjens, la teoría está bien, en teoría; pero en la práctica, la práctica es mejor. Vamos a ver si doy algunas pistas de alternativas para llegar más allá de lo que permiten las herramientas de monitorización estándares.

Empecemos suponiendo que uno de nuestros servidores, un martes cualquiera, a las 10:30 a.m., aparece con el load average (uno de esos parámetros tan usados como mal interpretados) tres veces más alto que lo normal en otros martes a la misma hora. ¿Cómo de malo es esto?

• Peligroso desde el punto de vista de la seguridad, porque puede implicar algún ataque, o que estemos mandando spam, o a saber qué.
• Peligroso porque podría ser debido a un problema hardware, y con ello ser la antesala de una caida total del servidor.
• Moderadamente serio en el caso en que simplemente se deba a que la conexión con nuestro servidor NFS se haya "atascado" (no es muy profesional, lo sé) de forma puntual, con lo que podría ser simplemente una pequeña congestión en la red, por decir algo.
• ¡Estupendo! Si se debe a que la última campaña de publicidad ha tenido éxito y nuestro servidor está a pleno rendimiento. En este caso tendríamos que ver si necesitamos más hierro, pero si el rendimiento es bueno podremos estar satisfechos por estar aprovechando esas CPUs por las que pagamos un buen dinero.

En definitiva, que nos vendría bien una monitorización algo más trabajada y capaz de ir algo más allá de los simples números.

Pongámonos en el escenario de un servidor IMAP que en momentos puntuales rechaza más validaciones de lo normal. Sabemos que los usuarios se quejan porque no pueden autenticarse contra el servidor, pero no sabemos el motivo exacto. Aquí el problema es otro, porque necesitaremos saber cuándo tenemos un ratio acierto/fallo alto, y a partir de ese momento decidir qué acciones tomar, ya sea en la línea de revisar conexiones de red, carga del sistema, descriptores de ficheros, estado del backend de validación .... El gran problema en este tipo de fallos puntuales es que son "difíciles de pillar", al poder pasar en cualquier momento, y sólo durante unos pocos segundos. Además, no siempre se deben a problemas fáciles de monitorizar, como son la carga o el consumo de memoria de los servidores. El que un sistema de monitorización se conecte bien a los equipos A y B no siempre significa que A no pierda tráfico cuando habla con B.

¿Y qué aplicaciones hay que revisen todo esto? Pues no lo sé; pero aunque las hubiera, como este blog no va sobre apt-get install y siguiente-siguiente, vamos a hacer algo moderadamente artesano.

No nos volvamos locos. Por mucho que nos lo curremos, y salvo el improbable caso en el que nos den tiempo suficiente para programarlo, es muy complicado picar un sistema de monitorización, con todo lo que implica, desde cero. Hacer una aplicación capaz de leer datos del sistema, analizarlos y parsearlos, con buen rendimiento y estabilidad, no es fácil. Además, si algo hay en el "mercado", son aplicaciones para monitorización de infraestructuras, que además funcionan muy bien. Dediquemos nuestro tiempo a escribir esa capa extra propia de nuestro entorno a la que no pueden llegar las herramientas generalistas.

Si hay un sistema de monitorización que destaca sobre los demás que conozco, ese es Collectd. ¡Ojo! No digo que Collectd haga mejores gráficos que Graphite, o que sea más configurable que Cacti o Munin. Lo que quiero remarcar es que Collectd es perfecto para esto que queremos hacer. ¿Por qué?

• Como la mayoría de aplicaciones serias, una vez configurada y puesta en marcha, podemos despreocuparnos de que se caiga o deje de funcionar.
• Tiene buen rendimiento. Todo el núcleo y los plugins están programados en C, y aunque esto no implique automáticamente que vaya a ir rápido, en mi experiencia funciona muy bien.
• Es modular. Tiene más de 90 plugins de todo tipo, desde los habituales para revisar la memoria o CPU, hasta otros más especializados, como Nginx o Netapp.
• Se divide en dos grandes grupos de plugins (hay más), uno para leer datos (de CPU, memoria, ...), y otro para escribirlos (a gráficos rrd, a un Graphite externo, ...).

Pero me he dejado lo mejor para el final: El que sea modular significa que podemos quitar todo lo que no necesitemos, como por ejemplo todos los plugins que pueden afectar al rendimiento del servidor (escribir en ficheros rrd, sin ir más lejos, puede ser delicado), y con ello tener un sistema de monitorización muy poco intrusivo, pero completo. Además, y aquí está lo bueno, podemos escribir nuestros propios plugins, ya sea en perl, python o C. Usaremos esta funcionalidad para la lógica de nuestra aplicación.

El ejemplo

Volvamos al caso del servidor de correo que genera errores de validación en algunos momentos de carga alta. En este contexto, para un diagnóstico correcto, lo normal es pensar que vamos a necesitar, por lo menos, los plugins de lectura relacionados con el uso de CPU, el load-average, el consumo de memoria y el de conexiones TCP para saber la cantidad de sesiones abiertas contra el servidor de validación. Pero, además, tenemos que saber cuándo está fallando el servidor, y esto lo haremos a partir de los logs de la aplicación, y del número de "Login OK" en relación a los "Login Error". Para conseguir esta información de logs usaremos el módulo "tail". El plugin de salida que escribiremos recogerá todos estos datos, los analizará, y generará un informe que nos mandará por correo (o reiniciará el servidor, o arrancará una nueva instancia de KVM, o lo que sea que programemos).

En otros posts he escrito demasiado código, y no tengo claro que esto no sea más una forma de despistar a la gente que algo útil. Lo que sí voy a hacer es escribir una estructura de ejemplo que puede seguirse a la hora de programar plugins de Collectd.

Empecemos con la configuración más básica de Collectd, una vez instalado en el equipo a monitorizar. Tened en cuenta que siempre es interesante usar una versión razonablemente reciente (para escribir plugins en perl se necesita una versión por encima de 4.0, y para python de 4.9, que salió en el 2009).

El fichero de configuración principal de Collectd es collectd.conf, independientemente de que esté en /etc, /etc/collectd, /usr/local/etc, o en cualquier otro sitio. Es fácil de interpretar, así que me voy a limitar a lo fundamental para el post. En un entorno real deberíais leer la documentación.

Interval 10

Con esta opción especificamos cada cuánto vamos a leer datos. Si estamos leyendo el consumo de memoria del servidor, hablamos simplemente de una lectura cada 10 segundos, pero si hablamos del módulo tail, como veremos más adelante, estaremos calculando el número de veces que aparece cierto mensaje en ese intervalo determinado.

Empezamos por los plugins de entrada que no necesitan configuración, y que se instancian simplemente con un "loadplugin":

LoadPlugin cpu
LoadPlugin load
LoadPlugin memory

Otros, como no puede ser de otra forma, necesitan alguna opción:

LoadPlugin tcpconns
<Plugin "tcpconns">
  ListeningPorts false
  RemotePort "3306"
</Plugin>

Tcpconns monitoriza las conexiones TCP del servidor. En este ejemplo necesitamos saber las sesiones abiertas hacia servidores Mysql, ya que es el backend que usamos para la autenticación. En realidad, deberíamos usar el plugin de mysql, que da toda la información que se obtiene a partir de un "show status", pero para este ejemplillo nos vale con esto.

Por último, en cuanto a los plugins de lectura se refiere, necesitamos el plugin "tail", que configuraremos para que siga el log de validaciones de usuarios (maillog), y las cadenas de texto "Login OK" y Login Failed":

LoadPlugin tail
<Plugin "tail">
        <File "/var/log/maillog">
                Instance "Email_auth"
                <Match>
                        Regex "^.*Login[[:blank:]]OK.*$"
                        DSType "CounterInc"
                        Type "counter"
                        Instance "login_ok"
                </Match>
                <Match>
                        Regex "^.*Login[[:blank:]]Failed.*$"
                        DSType "CounterInc"
                        Type "counter"
                        Instance "login_failed"
                </Match>
        </File>
</Plugin>

Podéis complicar la expresión regular todo lo que queráis. Hay algunas opciones de configuración adicionales que no se muestran en este ejemplo, pero que suelen venir bien, como "ExcludeRegex", con la que se pueden quitar ciertas cadenas de la búsqueda; útil en casos como cuando necesitamos eliminar de la búsqueda los "Login OK" de usuarios de prueba que lanzan otros sistemas de monitorización. A los que conozcáis MRTG y familia, además, os sonarán los "DSType" y "Type" de la configuración. Efectivamente, podemos hacer gráficos de todo lo que encontremos usando valores medios, máximos, .... En nuestro caso viene bien un "CounterInc", que no hace más que ir sumando todos los "Login OK|Fail", y que por lo tanto va a servirnos para hacer cálculos sencillos cada 10 segundos, y también en otros periodos más largos.

Y con esto terminamos la parte de lectura de datos. La información obtenida desde estos plugins servirá para detectar anomalías en el servicio y, a partir de ahí, para hacer otra serie de tests más específicos siempre que sea necesario.

En nuestro caso de uso no queremos generar ningún gráfico, así que solo necesitamos que collectd lance una instancia del script que vamos a escribir en lo que a plugins de salida se refiere. Por ejemplo, "/usr/local/bin/monitorcorreo.py" (sí, esta vez en python):

<LoadPlugin python>
        Globals true
</LoadPlugin>
<Plugin python>
        ModulePath "/usr/local/bin"
        LogTraces true
        Import "monitorcorreo"
        <Module monitorcorreo>
                Argumento1 1
                Argumento2 "Podemos pasar argumentos al script"
        </Module>
</Plugin>

Vale, ahora solo queda escribir la lógica de lo que queremos conseguir con la monitorización. Vamos, lo importante. Recordad que tenemos que recoger los datos que nos mandan el resto de plugins, hacer las comprobaciones que tengamos que hacer y, de ser así, tomar una acción. En realidad, el que programemos el script en Python o Perl hace que no tengamos demasiados límites, más allá de los que tenga el usuario con el que ejecutemos Collectd.

El Script

Centrándonos ya en lo que sería "/usr/local/bin/monitorcorreo.py", el script debe registrarse en Collectd llamando al método collectd.register_config(funcionConfig). Por supuesto, antes debéis haber importado el módulo collectd, y deberéis haber escrito una función "funcionConfig", que básicamente debería leer las opciones de configuración que hayamos escrito en collectd.conf y hacer con ellas lo que sea que necesitemos.

El siguiente método a llamar es collectd.register_init(funcionInit). En este caso, Collectd va a llamar a la función "funcionInit" antes de empezar a leer datos. Por lo tanto, suele usarse para inicializar las estructuras, conexiones de red y demás estado del plugin. En mi caso, por ejemplo, uso este método para inicializar una instancia de la clase donde guardo el histórico de los datos que voy leyendo (hay que programarla, claro), y también creo un socket PUB/SUB basado en ZeroMQ con el que publicar toda la información relevante. Puedo usar este socket para mandar información a otros equipos (a mi PC, por ejemplo), o para conectar el proceso sin privilegios que es Collectd con otro menos expuesto que sea capaz de reiniciar servicios o de tomar otras acciones que requieran permisos de root.

Lo siguiente es registrar lo que sirve para indicar que estamos ante un plugin de escritura, con "collectd.register_write(funcionWrite)". Esta es la función que llamará Collectd cada vez que quiera escribir los datos que haya leido. "funcionWrite" es, por lo tanto, donde se ejecuta toda la lógica de nuestro script.

Como he venido diciendo, la clave de lo que haga la función funcionWrite es algo ya demasiado particular como para escribirlo aquí. Las pistas que puedo daros, sin embargo, son las siguientes:

1. Si escribís algunas clases, con sus estructuras de datos y sus métodos, y las instanciais como "global", tendréis todo el histórico de datos (si lo queréis) durante todo el tiempo que esté collectd funcionando.

2. Collectd va a ejecutar funcionWrite cada vez que lea desde los plugins de lectura.

3. Si queréis hacer un ratio entre los "Login OK" y los "Login Failed" de una misma iteración de 10 segundos, con un contador incremental como CounterInc tendréis que restar los valores actuales a los de la iteración anterior, para sacar así los casos en estos 10 segundos. Dicho de otra forma, si ahora mismo hay 20 "Login OK" y 2 "Login Failed", y dentro de 10 segundos hay "27 Login OK" y 2 "Login Failed", en este intervalo de 10 segundos han habido 7 logins correctos y 0 fallidos. Este cálculo lo podéis hacer con comodidad si seguís la recomendación del punto 1. A partir de aquí podéis hacer las sumas, restas, divisiones o lo que sea que os apetezca.

4. Todas las mediciones que manda Collectd llevan un timestamp. Cuando llegue una medición con una marca de tiempo 10 segundos mayor, será el momento de hacer todos los cálculos que queráis, porque ya tendréis la imagen completa de lo que ha pasado en ese intervalo.

5. Para cada plugin de entrada, Collectd va a llamar a la función "funcionWrite" tantas veces como datos se generen, pasando como argumento un diccionario. En el caso del plugin de conexiones TCP, por ejemplo, se hace una llamada para cada estado posible (str(argumento)):

   collectd.Values(type='tcp_connections',type_instance='SYN_RECV',plugin='tcpconns',plugin_instance='3306-remote',host='192.168.10.20',time=1372071055.051519,interval=10.0,values=[20.0])
   
   collectd.Values(type='tcp_connections',type_instance='FIN_WAIT1',plugin='tcpconns',plugin_instance='3306-remote',host='192.168.10.20',time=1372071055.051519,interval=10.0,values=[2.0])
   
   collectd.Values(type='tcp_connections',type_instance='FIN_WAIT2',plugin='tcpconns',plugin_instance='3306-remote',host='192.168.10.20',time=1372071055.051519,interval=10.0,values=[4.0])
   
   collectd.Values(type='tcp_connections',type_instance='TIME_WAIT',plugin='tcpconns',plugin_instance='3306-remote',host='192.168.10.20',time=1372071055.051519,interval=10.0,values=[1.0])
   
   collectd.Values(type='tcp_connections',type_instance='CLOSED',plugin='tcpconns',plugin_instance='3306-remote',host='192.168.10.20',time=1372071055.051519,interval=10.0,values=[0.0])
   
   ...
   

   Otro ejemplo, este caso para el consumo de memoria:

   collectd.Values(type='memory',type_instance='used',plugin='memory',host='192.168.10.20',time=1372071405.0433152,interval=10.0,values=[415285248.0])
   
   collectd.Values(type='memory',type_instance='buffered',plugin='memory',host='192.168.10.20',time=1372071405.0441294,interval=10.0,values=[28184576.0])
   
   collectd.Values(type='memory',type_instance='cached',plugin='memory',host='192.168.10.20',time=1372071405.0494869,interval=10.0,values=[163659776.0])
   
   collectd.Values(type='memory',type_instance='free',plugin='memory',host='192.168.10.20',time=1372071405.050016,interval=10.0,values=[2551083008.0])
   

   Por último, esto es lo que manda el plugin tail.

   collectd.Values(type='counter',type_instance='login_ok',plugin='tail',plugin_instance='Email_auth',host='192.168.10.20',time=1372071405.0442178,interval=10.0,values=[27])
   
   collectd.Values(type='counter',type_instance='login_failed',plugin='tail',plugin_instance='Email_auth',host='192.168.10.20',time=1372071405.044635,interval=10.0,values=[2])
   

   Cada plugin genera los datos propios de lo que esté monitorizando, pero la estructura es siempre la misma. Hay que tener un poco de cuidado con los valores que se devuelven en "values", porque no son siempre una medición puntual aislada. Con nuestra configuración para tail sabemos que ese "values" tiene el número de líneas con login ok o failed desde que arrancamos Collectd, pero si lo hubiésemos definido como Gauge (por ejemplo), tendríamos otro valor diferente, y entraríamos en el terreno de los valores medios, máximos y mínimos tan de MRTG.

6. Si en una iteración se dieran las condiciones de fallo que hubiérais definido, como sería por ejemplo un 0.2% de fallos de Login en relación a los correctos, podéis usar la librería que más os guste de Python para hacer pruebas de todo tipo, desde un traceroute a una conexión a Mysql para lanzar una consulta determinada. En el caso de las validaciones, podríais completar el diagnóstico usando la librería IMAP de Python para capturar el error que devuelve el servidor. En definitiva, no hay límites.

7. Podéis enviar el informe de diagnósito por correo, o en un fichero de texto, o en un socket ZeroMQ, o de cualquier otra forma que permita Python. Podéis reiniciar aplicaciones, lanzar instancias de KVM, ....

Para no pecar de "abstracto", este es un esqueleto de ejemplo de un monitorcorreo.py cualquiera:

import collectd
'''import time, imaplib, socket, smtplib ...'''

class ClasesDeApoyo(object):
        '''
        Estrucutras de datos para guardar los valores que recibimos desde los plugins.
        Métodos para trabajar con los datos, ya sean actuales, o históricos.
        Métodos para relacionar los datos de distintos plugins.
        Métodos para generar informes, mandar correos, ....
        Métodos para hacer traceroutes, abrir sesiones IMAP, ....
        '''

def funcionConfig(argconfig):
        '''
        En argconfig se encuentran, entre otros, los argumentos que han entrado desde collectd.conf.
        '''
        global instanciasClasesDeApoyo
        '''
        Crear una instancia de las clases de apoyo, aunque se puede dejar para Init.
        Si se van a usar los argumentos de collectd.conf, se pueden leer en un bucle.
        '''

def funcionInit():
        '''
        Esta función se usa para inicializar datos. Puede ser interesante para llamar a métodos que abran conexiones, ficheros, ....
        '''
        global instanciasClasesDeApoyo
        '''
        Inicializar estructuras.
        Si todo ha ido bien, se registra en collectd la función Write.
        '''
        collectd.register_write(funcionWrite)

def funcionWrite(argdatos):
        '''
        Este es el método al que se llama cada vez que se genere un dato.
        Este método se encarga del trabajo real del script.
        '''
        global instanciasClasesDeApoyo
        '''
        Todos los valores vienen con un timestamp. Una idea es ir guardando estos valores en una estructura.
        Idea 1: Cuando el dato que se lea tenga un timestamp 10 segundos mayor que el anterior, es el momento de aplicar los calculos que tengamos que hacer, porque en ese punto ya tendremos la información de todos los plugins.
        Idea 2: Cuando hayáis leido los n datos que sabéis que se escriben en cada iteración, es el momento de aplicar los calculos que tengamos que hacer, porque en ese punto ya tendremos la información de todos los plugins.
        No siempre hacen falta todos los datos que recibimos desde collectd. Lo siguiente es un ejemplo.
        '''
        datos = {}
        datos["host"] = str(argdatos.host)
        datos["plugininstance"] = str(argdatos.plugin_instance)
        datos["typeinstance"] = str(argdatos.type_instance)
        datos["value"] = int(argdatos.values[0])
        datos["time"] = int(argdatos.time)
        datos["localtime"] =  str(time.strftime("%F %T",time.localtime(int(argdatos.time))))

        '''
        if datos["time"] < anteriordatos["time"]:
                instanciasClasesDeApoyo.hacerCalculos(datos)
        else:
                instanciasClasesDeApoyo.guardarDatos(datos)
        '''

collectd.register_config(funcionConfig)
collectd.register_init(funcionInit)