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):
- 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.
- 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.
- Ejemplo de aplicación zeroMQ.
- Otro ejemplo 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.
). Como podéis suponer, el correo que llegue a esta dirección se guardará físicamente en (esta parte de la configuración de Postfix/Dovecot os la dejo a vosotros):
.
