Monitorización en serio. Práctica

lun, 24 jun 2013 by Foron

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)
read more

Monitorización en serio. Teoría

vie, 07 dic 2012 by Foron

Os ahorro tener que leer todo el post para llegar a esta conclusión: El título es un poco sensacionalista, lo sé. Sigamos.

Uno de los aspectos más consolidados en lo que a la administración de sistemas se refiere es la monitorización. No hay infraestructura razonablemente seria que no tenga un ciento de monitores de carga de CPU, memoria consumida, tráfico de red, conexiones abiertas, .... Y junto a estos tenemos otros monitores, algo más avanzados, que por ejemplo revisan si una sesión POP3 se establece correctamente, usando para ello un usuario/contraseña preestablecidos; o que un una página PHP contiene cierto texto, para lo que se hacen X consultas, también predefinidas, en una base de datos.

Básicamente, esto es lo que hay; aquí nos quedamos la mayoría. Pero, ¿Es suficiente?

Sigamos con un ejemplo más concreto:

Vamos a suponer a partir de ahora que somos los responsables de los servidores IMAP de alguna de las empresas más grandes del sector del correo electrónico, y que por lo tanto tenemos millones de usuarios para los que poder acceder a su correo es, obviamente, fundamental.

Con el gráfico de conexiones establecidas en la mano, sabemos que el patrón más habitual es el siguiente:

Grafico base

Vemos que tenemos pocas conexiones abiertas durante la madrugada, y que el número va subiendo en la medida en que empieza la jornada laboral, con un pequeño descenso en las horas habituales de comida. Para este ejemplo nos quedamos con esto, aunque en condiciones normales se deberían tener en cuenta fines de semana, vacaciones, ....

La línea roja indica el umbral de alerta del monitor. Ya sabéis: el móvil suena cada vez que la línea verde supere a la roja. Aunque lo normal es que también tuviéramos un umbral de aviso amarillo y otro para cuando las conexiones fueran demasiado bajas, por ahora nos sirve esta versión simplificada.

Y llega el día en el que las conexiones establecidas contra nuestros servidores muestran lo siguiente:

Grafico con alertas

Qué fácil parece todo cuando vemos el gráfico! Lamentablemente, cuando somos responsables de unos cuantos cientos de gráficos, que por supuesto no estamos vigilando constantemente, solo vamos a tener constancia de ese pico de las 10 a.m., que además podría ser perfectamente un pequeño aumento puntual de carga inocuo para el servicio.

Por supuesto, ni nos hemos enterado del ataque por fuerza bruta de las 04:00 a.m. que probablemente haya conseguido "adivinar" decenas de contraseñas de usuarios, ya disponibles para el "spameo" generalizado; o de ese problema de media tarde, que quizá sí haya supuesto una perdida de servicio para muchos usuarios. Pero la cosa es todavía peor, porque resulta que nuestro sistema de validación de cuentas se "volvió loco" justo antes de esa bajada de tráfico y empezó a aceptar logins, independientemente de la validez de la contraseña.

¿Cuántos sistemas de monitorización habéis visto capaces de detectar estas situaciones? Llevadlo a otros entornos: ¿Cuantos sistemas de monitorización concéis capaces de detectar que una tienda online en realidad está cobrando 10 euros menos en algunos pedidos? ¿O un motor de búsqueda que da resultados erróneos periódicamente?

¿Qué hacemos entonces? ¿Tiramos todos los monitores que tenemos a la basura? Obviamenente, no. Es evidente que un servidor con una carga de CPU alta necesita atención.

Sin embargo, lo que sí debemos cambiar es el punto de vista sobre el que gira la monitorización, de tal manera que en lugar de orientarla hacia el aspecto estrictamente operacional, lo hagamos teniendo en cuenta el propio servicio que estamos vigilando, que no deja de ser, en definitiva, lo único que aporta valor. Dicho de otra forma, lo que importa no es que la máquina reviente, sino que el acceso de los clientes falle o sea más lento. Puede parecer un cambio sutil, pero no lo es.

Acercándonos otra vez a la faceta técnica, esto significa que deberíamos prestar más atención a los siguientes aspectos:

  1. La monitorización debe centrarse en las aplicaciones, y no en el hardware, la red o las máquinas. (Lo que veníamos diciendo sobre la percepción del servicio que tienen los usuarios).
  2. La monitorización puede ser importante como mecanismo para buscar mejoras y optimaciones para el servicio.
  3. Desde el punto de vista de los sistemas, esto significa que la monitorización debe interactuar mucho más con las aplicaciones.
  4. Parámetros como la latencia o el tiempo de respuesta de una aplicación deben cobrar más importancia.
  5. Detectar las anomalías debe ser uno de los objetivos a conseguir. Dicho de otra forma, si nuestro sistema gana una conexión nueva de media a la semana, y si este lunes tenemos 10, el que la semana siguiente veamos 20 debe alertarnos.
  6. No se puede monitorizar lo que no se puede medir.
  7. Por si no ha quedado claro, sólo se puede monitorizar lo que se puede medir.
  8. Revisar el estado de las aplicaciones hace que algunos de los chequeos "tradicionales" dejen de ser necesarios, con lo que se simplifica la monitorización.
  9. Los monitores tradicionales siguen siendo útiles para detectar un buen número de problemas, incluidos los relacionados con la escalabilidad de las plataformas.

Pero, ¿Cómo llevamos esto a la práctica?

En líneas generales, necesitamos trabajar mucho más contra los logs que generan los servicios. Si somos los desarrolladores de nuestras aplicaciones (una web por ejemplo), queda en nuestra mano definir y loguear la información que consideramos importante. Si, por el contrario, estamos usando una aplicación de un tercero (el servidor POP/IMAP Dovecot, por citar uno), nos resultará más difícil incluir un logueo específico, pero siempre podremos buscar la información que nos puede aportar visibilidad extra del entorno. En este caso concreto, por ejemplo, el número de intentos de conexión con credenciales inválidas o el ratio logins/logoouts son métricas que nos podrían ayudar en un momento dado, por citar dos.

En cuanto al software que podemos usar para la monitorización, tenemos decenas de buenas alternativas que podemos usar. Las hay más visuales, algunas están pensadas para entornos muy grandes, otras usan backends especializados (Cassandra por ejemplo), .... Queda a nuestra elección.

En lo que sí están de acuerdo la mayoría de aplicaciones es en la forma de detectar anomalías, sobre todo porque todas las que yo conozco se basan en este estupendo documento, que a la postre sirvió para la implementación en RRDTool. Siempre podéis diseñaros vuestro sistema, quizá usando R y su paquete forecast, pero esto está muy lejos del objetivo de este post.

En unos días describiré con más detalle una pequeña implementación de ejemplo sobre un servicio IMAP (Dovecot).

read more

Enrutamiento para dummies

jue, 27 sep 2012 by Foron

Si hay algo sobre lo que no hubiese querido escribir nunca en este blog es sobre el enrutamiento básico en Linux. Hace 10 años quizá hubiese sido más interesante, pero no ahora. Aún así, en este mundo del botón y del siguiente siguiente no tengo nada claro que la gente sepa exactamente lo que hay debajo de un "route -n", así que vamos a ello. Eso sí, para dummies. De hecho, me voy a pasar de básico, con lo que escribiré cosas que en condiciones normales merecerían una discusión. En fin.

Empezamos con el viejo comando "route -n", tan simple como siempre:

  # route -n
  Kernel IP routing table
  Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  0.0.0.0         10.213.208.1    0.0.0.0         UG    0      0        0 eth0
  10.213.208.0    0.0.0.0         255.255.240.0   U     0      0        0 eth0
  192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
  192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1

Lo normal cuando usamos la combinación route/ifconfig en la mayoría de las distribuciones, una puerta de enlace, una red para llegar a esa puerta de enlace a través de un dispositivo, y luego, en este caso, nuestras redes locales.

¿No hay nada más?

Pues sí, hay mucho más, claro. Esto no es más que una mínima porción de la tabla de enrutamiento de vuestro kernel favorito. Vamos a verlo pasando a la utilidad "ip", la pobre, que lleva tanto tiempo existiendo, pero que tan poco se usa (solo comparable al uso eterno de los aliases de IPs, pero esta es otra historia).

  # ip route ls
  default via 10.213.208.1 dev eth0
  10.213.208.0/20 dev eth0  proto kernel  scope link  src 10.213.218.162
  192.168.10.0/24 dev eth1  proto kernel  scope link  src 192.168.10.1
  192.168.11.0/24 dev eth1  proto kernel  scope link  src 192.168.11.1

¿Todo este rollo para ver lo mismo con un formato diferente?

Sí, porque estamos viendo, una vez más, solo una parte de la tabla de enrutamiento. ¡Hola "ip rule"!

  # ip rule ls
  0:      from all lookup local
  32766:  from all lookup main
  32767:  from all lookup default

Y ahora, sorpresa:

  # ip route ls table default
  _vacio_
  # ip route ls table main
  default via 10.213.208.1 dev eth0
  10.213.208.0/20 dev eth0  proto kernel  scope link  src 10.213.218.162
  192.168.10.0/24 dev eth1  proto kernel  scope link  src 192.168.10.1
  192.168.11.0/24 dev eth1  proto kernel  scope link  src 192.168.11.1
  # ip route ls table local
  broadcast 10.213.208.0 dev eth0  proto kernel  scope link  src 10.213.218.162
  local 10.213.218.162 dev eth0  proto kernel  scope host  src 10.213.218.162
  broadcast 10.213.223.255 dev eth0  proto kernel  scope link  src 10.213.218.162
  broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
  local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
  local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
  broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
  broadcast 192.168.10.0 dev eth1  proto kernel  scope link  src 192.168.10.1
  local 192.168.10.1 dev eth1  proto kernel  scope host  src 192.168.10.1
  broadcast 192.168.10.255 dev eth1  proto kernel  scope link  src 192.168.10.1
  broadcast 192.168.11.0 dev eth1  proto kernel  scope link  src 192.168.11.1
  local 192.168.11.1 dev eth1  proto kernel  scope host  src 192.168.11.1
  broadcast 192.168.11.255 dev eth1  proto kernel  scope link  src 192.168.11.1

Vaya sorpresa... Lo que vemos con un "route -n" es en realidad la tabla "main", que además, por ese 32766, parece tener menos prioridad que esa tabla "local" tan curiosa. Fácil de leer, ¿Verdad? Los broadcast los conocemos todos pero, ¿Y las rutas de tipo local? Sacado literalmente del manual (Sí, todo esto está en el manual de ip route!!!): "the destinations are assigned to this host. The packets are looped back and delivered locally". Y con esto hemos terminado, solo nos queda saber que "proto kernel" es la configuración más normal si no usamos software de enrutamiento (quagga, por ejemplo), y que "scope link" es para rutas broadcast y unicast mientras que "scope host" es para las locales.

Revisad los manuales de "ip rule" e "ip route", por favor, y entended cada entrada de estas tablas y reglas.

Ya que estamos, vamos a jugar un poco con todo esto que hemos visto, aunque seguimos en "modo sencillo" y no nos vamos a complicar demasiado. Solo unas ideas.

Nota: No hagáis caso a las IPs que uso a partir de aquí. Intentaré mantenerlas coherentes, pero me las estoy inventando sobre la marcha.

Tenemos reglas en "ip rule", tenemos tablas de enrutamiento, ... ¿Apostamos a que todo esto es modificable/configurable? ¡Por supuesto!

Vamos a vuestra distribución Debian favorita, y busquemos el fichero "/etc/iproute2/rt_tables"

  # cat /etc/iproute2/rt_tables
  #
  # reserved values
  #
  255     local
  254     main
  253     default
  0       unspec
  #
  # local
  #
  #1      inr.ruhep

  1001 proveedor1
  1002 proveedor2

No, en vuestros ficheros no van a estar las líneas "proveedor1" y "proveedor2". Las he añadido yo, alegremente. Donde estoy escribiendo este post no hay múltiples lineas de acceso a Internet, pero me voy a inventar, como ejemplo, que en mi equipo hay dos ADSL de proveedores diferentes. Uno me ha asignado la IP 192.0.2.33/24, con puerta de enlace 192.0.2.1, y el segundo 198.51.100.33/24, con gateway 198.51.100.1.

Como ya sabemos todo sobre enrutamiento, queremos mandar a los comerciales a través del primer proveedor, y a los técnicos a través del segundo. Supongamos que los comerciales están todos en la subred "172.16.0.0/24", y los técnicos en "172.16.1.0/24".

¡Juguemos con ip rule!

  # ip rule add from 172.16.0.0/24 table proveedor1
  # ip rule add from 172.16.1.0/24 table proveedor2
  # ip rule ls
  0:      from all lookup local
  32764:  from 172.16.1.0/24 lookup proveedor2
  32765:  from 172.16.0.0/24 lookup proveedor1
  32766:  from all lookup main
  32767:  from all lookup default

Efectivamente, hemos separado el tráfico en dos tablas, por ahora vacías. Es el turno de ip route:

  # ip route add 172.16.0.0/16 dev eth0 src 172.16.0.1 table proveedor1
  # ip route add 192.0.2.0/24 dev eth1 src 192.0.2.33 table proveedor1
  # ip route add default via 192.0.2.1 table proveedor1

  # ip route add 172.16.0.0/16 dev eth0 src 172.16.0.1 table proveedor2
  # ip route add 198.51.100.0/24 dev eth2 src 198.51.100.33 table proveedor2
  # ip route add default via 198.51.100.1 table proveedor2

¿Veis lo que hemos hecho? Hemos asignado dos puertas de enlace por defecto diferentes, en base al origen, por lo que todo lo que venga desde 172.16.0.0/24 irá por 192.0.2.1, y lo originado en 172.16.1.0/24 por 198.51.100.1. Por si fuera poco, el tráfico que no entre en ninguna de estas dos subredes accederá a la tabla main (from all lookup main), y con ello usará la puerta de enlace por defecto de toda la vida, esa que pensábamos que era única.

Y ya está, aquí lo dejo, aunque debo recordaros que esto no es una guía tipo copy/paste, ni remotamente.

Notas:

  • Como no podía ser de otra forma, el direccionamiento interno de este post no puede salir directamente a Internet. Hay que hacer SNAT (o el masquerade de toda la vida) en iptables. Lo normal es que conntrack haga magia y sepa dónde mandar vuestro tráfico, pero también es posible que se tenga que jugar más a fondo con ello.
  • Las entradas que añaden rutas a las tablas están simplificadas. Sería deseable completarlas, por ejemplo para evitar avisos de ICMP sobre mejores rutas si quisiésemos mandar tráfico entre redes. Lo dicho, no es más que un ejemplo.
  • En función de las configuraciones, interfaces, firewalls, ... puede ser posible que se tenga que cambiar algún parámetro de kernel, como por ejemplo, lo relacionado con rp_filter (Google es vuestro amigo). Por supuesto, ni que decir ip_forward.
  • Una vez más, esto es un mínimo ejemplo de lo mucho que se puede hacer. Las reglas, sin ir más lejos, pueden definirse por IP origen, destino, o incluso por marca de firewall, con lo que las posibilidades son enormes.
  • Os recomiendo completar lo visto en este post con todo lo que hay alrededor del enrutamiento en un kernel normal, con soporte Netfilter. Pista.
read more

Documentación útil

sáb, 25 feb 2012 by Foron

La verdad, a estas alturas todavía no conozco a demasiada gente a la que le guste documentar. Es más, cuanto más técnico es uno, menos gusta.

Cada uno tendrá sus motivos, pero en mi caso, saber que nadie lee los documentos internos de instalaciones, actualizaciones, etc, que he escrito no me termina de hacer gracia.

Veamos el entorno en el que suelen moverse este tipo de documentos:

  • Son manuales que describen la instalación de servidores y aplicaciones, y que suelen guardarse en formato doc, pdf o similares en sistemas de gestión documental.
  • Su lógica es que un nuevo empleado pueda revisar el documento y que le sirva como referencia de la infraestructura.
  • Describen la instalación, paso a paso, de un servidor, por ejemplo de correo electrónico, las aplicaciones que ejecuta, ficheros de configuración, ....
  • Pretenden estar siempre actualizadas.

¿Cuál es el problema?

Según lo veo yo, y al igual que pasa con tantos otros "deberes" del trabajo (partes de actividad, gestión de procesos, ...), rompen completamente el flujo de trabajo del empleado: Para documentar, o para rellenar un parte de actividad, uno tiene que dejar lo que está haciendo, abrir libreoffice, buscar la plantilla, escribir texto, .... viene trabajo urgente, se aparca el documento, se retoma a los dos días, no se recuerda lo que se ha escrito, se repasa, ... otra vez trabajo prioritario, se vuelve a dejar el documento, ....

Y con las actualizaciones es todavía peor. No sé yo si mucha gente actualiza sus documentos cuando cambia algo de sus servidores (algo presumible en sistemas "vivos"), pero supone volver a dejar la rutina del trabajo, abrir el documento, buscar lo que hay que cambiar, redactar las modificaciones, repasar el documento, corregirlo, ....

Los wikis, que también se usan a menudo, tampoco están exentos de estos problemas: No siempre es fácil ir al navegador, buscar un documento que se escribió hace tiempo, modificarlo, ver referencias, mantenerlo al día, ....

Y para colmo, ¿Necesita esta documentación un nuevo empleado? Debemos suponer que alguien que va a trabajar con servidores de correo electrónico sabe como se instalan y lo que significa cada opción de configuración ¿Verdad?.

Con estos antecedentes, aquí van los mandamientos de forondarena.net para el trabajo de documentación:

  1. Por supuesto, hay que documentar todo aquello que no sea interno: Manuales para clientes y proveedores, documentos específicos para grupos de soporte y atención al cliente, ....
  2. Volviendo al trabajo interno de un departamento, sólo se documenta la definición del producto, quizá en forma de plan de proyecto, con su alcance, su público objetivo, lo que se pretende conseguir con él, .... En fin, estas cosas. Se pueden añadir detalles técnicos, pero más estructurales, de infraestructura, entorno tecnológico, ....
  3. Sólo hay una forma de garantizar que una instalación va a estar siempre bien documentada: Integrando la documentación en la rutina del trabajo. Dicho de otra forma, y concretando con un ejemplo, usando Puppet o similares en las instalaciones (y actualizaciones), y aprovechando su capacidad para auto-documentarse. Si alguien toca algo a mano, Puppet lo sobrescribe. Documentación actualizada, siempre.
  4. Si por algún motivo no se puede usar un sistema de gestión centralizada, al menos debe usarse software de control de versiones, ya sea git, subversion, cvs, o el que sea.
  5. La documentación más concreta, más detallada, de ficheros de configuración y scripts, como por ejemplo el motivo por el que se bloqueó una red en la configuración de apache, o la incidencia por la que se decidió aumentar el tamaño máximo de un mensaje en Postfix, deben estar al alcance del técnico, a ser posible sin tener que mover la vista de la terminal.

Y es este último punto el que me interesa en este post.

No, escribir comentarios en los mismos ficheros de configuración no es una opción, salvo para cosas puntuales. Además, una cosa es que queramos poder acceder rápido a la documentación, y otra que no podamos, en algún momento, pasarla a otros formatos, como html, con enlaces entre documentos, o pdf.

Entonces,.... Pues sí, sorpresa, ¡man!, el de toda la vida, y algunas aplicaciones construidas a su alrededor permiten hacer estas cosas, y mucho más.

Escribiendo páginas de manual

No, no voy a hablar sobre groff, ni mandoc, ni nada similar. Vamos a simplificar esto, aunque no haya nada complicado en groff, que conste. El objetivo es escribir documentación rápido, y no caer en los mismos errores que intentamos evitar.

A partir de ahora, sólo voy a escribir un pequeño resumen de este post del excelente blog dailyjs. Muy recomendable.

Por un lado, necesitamos un formato sencillo en el que escribir la documentación, y por otro, algún tipo de aplicación con la que convertir este texto en páginas compatibles con man, html, pdf, o lo que necesitemos.

Entre las opciones para el formato, la elección es markdown (que por cierto es interpretado por Github), y en cuanto a la aplicación que permite su conversión a otros formatos, tenemos varias alternativas, como ronn, o su versión para node.js ronnjs; pero en este post de ejemplo vamos a usar mantastic.herokuapp.com, que es una aplicación de Heroku que hace todo el trabajo por nosotros.

Pasemos a un ejemplo:

Tenemos un servidor de correo Postfix, con su correspondiente main.cf. Este fichero se sincroniza a través de Puppet, y se ha ido modificando en función de bugs, mejoras, incidencias de clientes y similares a lo largo de los meses.

En markdown, podríamos escribir algo como esto (que por cierto, se explica solo):

 main.cf(5) -- Configuración principal de Postfix
 ================================================

  ## SYNOPSIS

  `main.cf` - Fichero de configuración principal de Postfix.

  ## DESCRIPTION

  El fichero `main.cf` define gran parte de los cambios sobre la instalación base que se hacen a Postfix. Por lo tanto, cualquier cambio que se realice en este fichero debe ser probado en servidores de pre producción.


  `main.cf` es gestionado por `puppet(1)`. Los cambios que se apliquen directamente sobre este fichero serán sobreescritos.


  En la siguiente lista se encuentran las modificaciones más significativas que se han ido aplicando al fichero:

  * `message_size_limit`=20000:
       Se aplicó este límite de 20000 bytes a la configuración bla bla bla.

  * `dovecot_destination_recipient_limit`=1:
       Opción más segura para controlar las entregas locales bla bla bla. El transport dovecot se define en `master.cf(5)`

  * `smtpd_client_restrictions`=check_client_access cdb:/etc/postfix/clientes.out:
       Se define el fichero `clientes.out(5)`, como parte del grupo de restricciones en fase cliente, para rechazar aquellos clientes que no cumplan las normas de uso de la plataforma.

  ## INCIDENCIAS

  [1234](http://bugtrack.example.com/?id=1234) - Cliente x con problemas de envío.
  [5678](http://bugtrack.example.com/?id=5678) - Cliente z que envía miles de mensajes spam.

  ## HISTORY

  2012-02-20, Versión inicial.

  ## AUTHOR

  2012, Forondarena.net postmaster

  ## COPYRIGHT

  Forondarena.net

  ## SEE ALSO

  `puppet(1)`, `master.cf(5)`, `clientes.out(5)`

Si guardamos este fichero como "main.cf.5.md", y lo pasamos por la aplicación de Heroku, obtendremos una página de manual perfectamente formateada:

  curl -F page=@main.cf.5.md http://mantastic.herokuapp.com > main.cf.5

Si por el contrario optáis por usar una instalación local de ronn, o de ronnjs, se podría generar, además de lo anterior, una serie de páginas html enlazadas entre sí, tipo wiki, aunque para eso quizá habría que trabajar algo más el markdown.

Conclusión

Tal y como he venido diciendo, una buena documentación tiene tres niveles:

  1. Documentación general, de alto nivel, o externa. Puede ser un doc, pdf, etc.
  2. Documentación sobre instalaciones de máquinas, actualizaciones de software, etc. Muy dinámica y difícil de mantener si no se integra completamente en el día a día del trabajo. Los sistemas de configuración centralizados son la clave.
  3. Documentación detallada sobre scripts y ficheros concretos. No conozco muchos entornos en los que se tengan realmente bien documentados todos los scripts y ficheros de configuración. Algunos son capaces de incluir comentarios inline, pero esto no siempre es suficiente, y se corre el riesgo de terminar con ficheros de configuración demasiado "densos". Sólo pueden documentarse correctamente a través de aplicaciones muy sencillas y directas.

Notas

El fichero en markdown y su correspondiente página de manual están disponibles en Github.

Una vez más, el impulso definitivo para publicar esto se debe al post de dailyjs que he referenciado anteriormente.

Dejo como ejercicio el uso de ronn o ronnjs en línea de comandos, la generación de páginas html, la gestión centralizada, o incluso montar un servidor de páginas de manual (pista: tcpserver/tcpclient, netcat, socat, ...).

read more

rsyslog y zeroMQ

dom, 06 nov 2011 by Foron

Con la evolución de los sistemas actuales, cada vez más grandes, con más elementos interconectados, con más necesidades de comunicación; con el cloud computing, las nubes, nieblas y demás parafernalia, llevamos ya tiempo viendo como las diferentes implementaciones de Advanced Message Queuing Protocol, como RabbitMQ, van ganando más y más seguidores.

Desde el punto de vista de la administración de sistemas, entornos como Nova (parte de Openstack) hacen uso de este protocolo, y de RabbitMQ más concretamente, para la comunicación entre sus múltiples componentes.

Hace unos años, y en desacuerdo con la evolución de AMQP, la gente de Imatix (ojo, es una de las empresas responsables de su implementación original), decidió apartarse de este protocolo y desarrollar una pequeña librería, zeroMQ, con la que se pudieran escribir aplicaciones con capacidades de comunicación avanzadas, pero de una manera sencilla; de tal manera que en lugar de un elemento más bien central en la infraestructura (AMQP), se tuviera un modelo más distribuido, en el que la mayoría del trabajo se delegase a los extremos (las aplicaciones), y no a ese nodo central. Usando una analogía de un documento de introducción a zeroMQ, estamos hablando de pasar de subversion (AMQP) a git (zeroMQ).

Bien, ahora que ya tengo vuestro interés (¿Verdad?), vamos a olvidarnos de la literatura y a buscar formas de aprovechar lo que zeroMQ puede ofrecernos para el trabajo diario del administrador de sistemas. Recordemos que al hablar de este tipo de tecnologías nos referimos al paso de mensajes entre procesos, a su gestión, a su enrutamiento, .... Y quien dice mensajes, cómo no, puede estar diciendo logs.

Al hablar de logs, por otro lado, hablamos de syslog, de servidores remotos a los que enviar datos, de ficheros que abrir y procesar, de plantillas para bases de datos en las que escribir los logs directamente, y quizá de sistemas más avanzados, como flume. ¿Sería posible usar lo bueno que tienen estas aplicaciones, y mejorarlas con lo que ofrece zeroMQ, sin volvernos locos en el intento?

Algo parecido debieron pensar en Aggregate Knowledge. Sencillamente, han escrito un par de plugins (de entrada y de salida) para rsyslog, de tal manera que podamos usar mucho de lo que nos ofrece zeroMQ (centrándome en el plugin de salida hablamos de sockets pub, push y rep básicamente) desde aplicaciones externas.

Dicho de otra forma, en una frase, podremos conectarnos en cualquier momento al rsyslog de un servidor, y ver lo que está logueando desde una aplicación que nosotros mismos habremos escrito, ya sea con Python, Perl, C, node.js, PHP, ... o con cualquiera de los muchos lenguajes para los que hay un "binding". De esta manera, podremos procesar datos en tiempo real o analizar lo que está pasando en una máquina, sin tener que acceder a ella y sin tener que ejecutar ningún tipo de software adicional en el servidor.

Antes de seguir, si queréis probarlo vosotros mismos, aquí os he dejado un backport de rsyslog 5.8.5 con soporte para zeromq para Debian Squeeze, y otro .deb de la misma versión de rsyslog para Debian Testing. En cualquier caso, recordad que son paquetes que se han creado en el momento en que se ha escrito este post. Por lo tanto, y más para Debian Testing, es muy posible que las versiones hayan cambiado cuando instaléis los paquetes, así que cuidado, bajo vuestra responsabilidad.

Aclarado esto, sigamos con el ejemplo.

Recordad que zeroMQ es una librería, y que como tal puede usarse en cualquier aplicación, sin límites. Accederemos a los logs de rsyslog (me estoy centrando en el plugin de salida) a través del socket adecuado, y a partir de ahí es cosa nuestra. En todo caso, hagamos lo que hagamos, probablemente podremos catalogar nuestra aplicación en uno de estos dos grandes grupos (es una simplificación, obviamente):

  1. Monitorización: A menudo sólo queremos ver lo que está pasando en un servidor. No necesitamos procesar los mensajes, nos vale con hacer un seguimiento de la actividad de una máquina. Cuando se configura rsyslog para usar sockets tipo "pub", por ejemplo, estamos creando una especie de feed de datos. Todos los clientes que se conecten a ese socket (probablemente de tipo "sub") recibirán los mismos datos, como si fuera una emisión de radio. Además, no necesitamos guardar los mensajes si no hay nadie escuchando, podemos descartarlos.
  2. Tratamiento: Los sockets tipo "push" balancean la carga automáticamente entre todos los clientes conectados (probablemente de tipo "pull"). Esto es perfecto cuando queremos procesar, por ejemplo, los logs de correo de un servidor. En un primer momento podríamos empezar con un único cliente escuchando y procesando los datos del servidor. Si en algún momento esta aplicación no pudiera con el volumen de logs, sería suficiente con arrancar una segunda instancia, de tal manera que se dividiría el trabajo entre las dos, automáticamente, y siempre que fueran lo suficientemente inteligentes, claro.

Podemos complicarnos mucho más, claro, pero lo dejaremos así por ahora. Como he dicho anteriormente, probablemente haya simplificado demasiado todo lo que puede hacerse, pero creo que estos dos escenarios describen bien el potencial de la librería.

Vamos a ver con un par de ejemplos lo sencillo que es todo esto. Empezamos con nuestro feed de logs.

  # cat /etc/rsyslog.conf
  ...
  *.* :omzeromq:bind=tcp://*:5557,pattern=pub;RSYSLOG_TraditionalFileFormat
  ...
  *.*     -/var/log/syslog
  ...

Los clientes tendrán que conectarse al puerto 5557. Además, como se muestra en este ejemplo, el que usemos zeroMQ no significa que no podamos escribirlos también en otros ficheros.

En Fedora 15, si quisieramos escribir una pequeña aplicación con Python 3.x, sería suficiente con lo siguiente:

  # yum install python3-zmq
  # cat prueba_pub_sub.py
  import zmq
  context = zmq.Context()
  socket = context.socket(zmq.SUB)
  print ("Conectando a servidores…")
  socket.connect ("tcp://servidor1.forondarena.net:5557")
  socket.connect ("tcp://servidor2.forondarena.net:5557")
  print ("Conectados a dos servidores")
  socket.setsockopt(zmq.SUBSCRIBE, b"")
  while 1:
      string = socket.recv()
      print ("Recibimos datos: ",string.decode())

Y, básicamente, esto es todo lo necesario. Es más, en este caso, nos conectamos a dos servidores, "servidor1.forondarena.net" y "servidor2.forondarena.net", con lo que recibiremos todos los mensajes que generen ambos. Con "setsockopt" estamos poniendo un filtro para los mensajes, que en este caso es una cadena vacía, así que no aplicaremos ninguno. Si abrimos 10 terminales y ejecutamos este python en cada una, veremos como se muestran los mismos mensajes en todas ellas.

Con los sockets push/pull la cosa es igual de sencilla:

  # cat /etc/rsyslog.conf
  ...
  *.* :omzeromq:bind=tcp://*:5557,pattern=push;RSYSLOG_TraditionalFileFormat
  ...
  *.*     -/var/log/syslog
  ...

La aplicación cliente tampoco tiene ningún misterio:

  import zmq
  context = zmq.Context()
  socket = context.socket(zmq.PULL)
  print ("Conectando a servidores…")
  socket.connect ("tcp://servidor1.forondarena.net:5557")
  print ("Conectados")
  while 1:
          string = socket.recv()
          print ("Recibimos datos: ",string.decode())

En este caso, nos conectamos sólo a "servidor1". La gran diferencia con el ejemplo anterior es que, si ejecutamos el script en dos terminales, veremos un mensaje en una, y el siguiente en otra (load balance). Este modelo es perfecto, por lo tanto, para los casos en los que las aplicaciones generan una única línea de log independiente por evento. En todo caso, como es nuestra aplicación la responsable del tratamiento de los mensajes, tenemos vía libre para hacer lo que queramos con los logs, ya sea insertándolos en MySQL una vez procesados, o en Hadoop, o en Cassandra, o en Redis, o en MongoDB, o en ....

En definitiva, creo que la unión de zeroMQ con rsyslog es una estupenda idea de la gente de Aggregate Knowledge. Además, el que zeroMQ pueda usarse casi con cualquier lenguaje de programación abre la ventana para que desarrollemos todo tipo de aplicaciones, ya sean en modo texto o gráficas, para consola o para interfaces web.

Notas

Este post es extremadamente superficial. AMQP, zeroMQ o rsyslog dan por sí mismos para páginas y páginas de blogs. Es más, ya las hay, y a montones. Aquí tenéis un puñado de referencias que os pueden servir para profundizar en el tema:

  • Introducción a zeroMQ. Estupenda introducción a zeroMQ. Empezad por aquí.
  • Guía de zeroMQ. Magnífica guía de zeroMQ, con ejemplos y propuestas de patrones.
  • Ejemplo1 de aplicación zeroMQ.
  • Otro ejemplo2 de uno de los patrones propuestos en la guía de zeroMQ, y unos benchmarks de Aggregate Knowledge.
  • Motivos por los que Imatix no está de acuerdo con la evolución de AMQP. Cuidado, es pelín denso.

No he querido incluir en el post los pasos para preparar los .deb de rsyslog. Si os interesa, dejad un comentario o un tweet y escribo algo al respecto.

read more