Monitorizando los registros systemd

Registros systemd: cómo monitorizarlos con Pandora FMS

Los registros systemd, sin exención, pueden ser monitorizados en esta prueba de concepto que veremos a continuación. Pero, ¿qué es systemd y cómo funciona?

De antemano os digo que no deseo crear polémica alguna, mis opiniones sobre systemd me las voy a reservar. Por allá en el año 2014 que me dediqué de manera formal a estudiar el software libre, recibí clases de instructores y profesores que «crecieron» usando un proceso de inicialización (initialization o simplemente init) muy práctico llamado sysvinit (también conocido como System V initialization, System V o SysV); eso en lo que a Debian respecta, que fue la distribución que estudiamos. Os describo brevemente qué hacía tan particular a sysvinit.

Sysvinit

Sysvinit era un programa init que, después de que el kernel Linux estuviera cargado en memoria y listo para trabajar, se encargaba de ejecutar el resto de los procesos (vamos, lo que hace todo init). Estaba directamente inspirado en System V de Unix® y, sin sorpresa alguna para nosotros, se configuraba por medio de ficheros que debían tener un orden correcto para ejecutar todo lo necesario en un servidor. Por ejemplo, debíamos cargar las interfaces de red antes de poder cargar cualquier servicio de red. Una vez todo estaba corriendo sysvinit finalizaba, liberando así recursos de memoria: sysvinit era un «ciao y adiós». Cualquier otra cosa que necesitáramos la debíamos ejecutar por nuestra orden directa. Era un proceso lento y muy ordenado, pero, ¿cuántas veces reiniciábamos un servidor con GNU/Linux® en un día, una semana o un mes? El «coste» del arranque se veía beneficiado luego en desempeño.

Otra particularidad consistía en que el proceso era secuencial: una vez que un servicio o demonio reportaba que estaba listo y en ejecución, pasaba al siguiente. Esta fue la principal crítica; cosas tan simples como la sincronización de hora con otro servidor (Network Protocol Time) detenían todo el proceso de arranque si el cable de red estaba desconectado o no había conexión a Internet, o si el servidor de hora estaba apagado o fuera de línea (o cualquier otra causa).

Aparte de todo esto, también debemos considerar el coste de ejecutar guiones BASH que llaman una y otra vez a las mismas funciones (cat, grep, etc.). A nosotros nos resulta fácil de escribir y programar, pero no lo convertimos a lenguaje de máquina y eso también hace que el sistema se retrase al arrancar.

Por esta razón en Ubuntu 6.10 desarrollaron un init llamado Upstart, pero esa es otra historia ya que otro cambio se avecinaba…

Systemd

En el mundo GNU/Linux las mayúsculas y minúsculas importan, y mucho, así que systemd se escribe tal cual (no confundir con System D, que es otra cosa). Nace en el año 2009 principalmente de la mano de Leonard Poettering (muy activo en la red social Twitter), Kay Sievers (trabajaba para Novell), Harald Hoyer (trabaja para Red Hat) y Dhaval Giani (ex-empleado de IBM).

La distribución Fedora 15 fue la primera que utilizó este novedoso init: ¿Qué hacía -qué hace- de manera diferente systemd? Expreso en mis propias palabras, con el perdón de ingenieros, licenciados y estudiosos de la informática, lo siguiente.

Como saben, la palabra «software» está plenamente asimilada en nuestro idioma castellano, pues hay conceptos modernos que son difíciles de traducir, y así de plano se convierten en «sustantivos propios». Tal es el caso de los sockets, que en inglés significa «cavidades», y que con el advenimiento de la electricidad se utilizó para denotar a los tomacorrientes: una cavidad donde insertamos una clavija a su vez conectada a un cable. Algunas veces se utiliza la palabra zócalo (en arquitectura, la base de un edificio, escultura, etc.) para denotar dónde se inserta la unidad central de procesamiento: «zócalo de procesador». Pero, para evitar confusiones, pienso que es mejor seguir usando el anglicismo socket…

En Unix® existe ese concepto de socket para denotar un punto donde una aplicación conecta con otra; incluso existen los sockets web con el mismo propósito, pero ubicados en ordenadores distintos.

Pues bien, systemd lo que hace es crear primero los sockets antes que los demonios (daemons, en inglés). Sí, tal como el chascarrillo aquel de «¿qué fue primero, el huevo o la gallina?». Una vez hecho esto, se van lanzando los daemons de la misma manera, uno por uno, y cuando un socket cuyo dueño –daemon– no haya arrancado sea consultado por otro daemon, ¡pues que se espere a que esté listo y ya!

Ya podrán imaginar entonces que systemd debe estar constantemente revisando que cada daemon haya terminado de cargar en memoria: si un daemon depende de varios daemons es probable que quede el último en la carga de trabajo del servidor.

Recordemos que el trabajo de systemd es cargar todos y cada uno de los daemons, pero, ¿qué sucede si alguno de ellos va mal? Systemd debe ser capaz de finalizarlo y reiniciarlo, y allí es cuando vienen los problemas: ¿Ese daemon se lanzó a sí mismo? ¿Lanzó otra instancia? Eso es un gran problema para systemd porque no está al tanto de saber si el daemon creció, se desarrolló y bifurcó y está siendo ejecutado perfectamente bien.

La solución a esto se había presentado un año antes y no, no tenía nada que ver con systemd: era control groups (luego abreviado cgroups).

Systemd-components (Image courtesy Wikimedia Commons, CC BY-SA 3.0)

Como pueden ver, cgroups, autofs y kdbus están firmes y cementados en el kernel de Linux. De verdad que quisiera hablaros de todo el gráfico… solo hago la salvedad de que esta imagen puede no estar actualizada a la arquitectura del corazón de los *nix.

Volviendo a cgroups, este elemento fue creado para poder dar albergue a los «contenedores» (containers), como una manera de poder controlar los recursos (memoria, uso del procesador, etc.) de los procesos. Esto dio como resultado, en su representación más famosa, a Docker y sus «orquestadores» más famosos: Kubernetes y Podman (máquinas virtuales más eficientes y que corren de manera coordinada en racimos).

De esta manera (y lo he descrito a muy grandes rasgos) systemd puede controlar de manera absoluta todo lo que acontece bajo su mandato y, como todo poder ciega, el siguiente paso (el «régimen dictatorial») de systemd estaría por comenzar.

Alfa y omega

La crítica más fuerte hacia systemd es que se convirtió en el primero y el último, el alfa y el omega en el mundo del kernel Linux. Ya sabéis el refrán aquel de «no pongáis todos los huevos en una sola canasta»: systemd es el primero que inicia con el identificador de proceso uno (Process IDentifier 1 o PID 1) y de allí el resto de procesos, los cuales en su debido momento finalizan todos y por último systemd apaga el ordenador.

Durante todo el tiempo que está encendido el ordenador, systemd está encargado de mantener funcionando todos los servicios y vigilando sus desempeños: para todos ellos ya tiene su socket listo para iniciar procesos si recibe alguna solicitud. Por ejemplo, el bluetooth es algo que en un servidor difícilmente usaremos; por ello estará el socket hecho pero hasta que de verdad conectemos un dispositivo no iniciará programa alguno (a pesar de este esquema, los detractores de systemd indican que esto también consume algo de memoria y ciclos de CPU).

Para Pandora FMS, en su modo de Alta Disponibilidad en Racimo (Pandora FMS HA), systemd es sumamente importante: es el encargado de que el servicio pandora_ha funcione constantemente para monitorizar el racimo de servidores (reiniciando Pandora FMS HA, de ser necesario).

Algunas de las más importantes distribuciones Linux, aparte de Fedora (y el mundo Red Hat), utilizan systemd:

• Debian.
• Ubuntu (y sus «sabores»).
• openSUSE.
• Mageia.
• Gentoo.
• Arch Linux.

Sin embargo debo hacer notar (aunque aquí siempre hablo en tiempo pasado acerca de sysvinit) que existe al momento de escribir estas líneas una distribución basada en Debian que todavía lo utiliza (y además openrc, otro init de manera opcional): Devuan. Por increíble que parezca, un servidor Devuan lo podemos instalar fuera de línea en un disco compacto de 670 megabytes. Si queremos, podemos descargar alguna interfaz gráfica como Xfce o MATE en sendos discos (hay más interfaces gráficas disponibles).

Unidades en systemd

Entrando en los rasgos generales de systemd, este utiliza las denominadas unidades (units) para iniciar y supervisar el sistema:

1. service: aparte de encargarse de todos los daemons, también soporta la compatibilidad de guiones de SysV, dado el caso de algún programa que utilice esa tecnología.
2. socket: sobre la que ya hablé anteriormente.
3. device: para el manejo y control de dispositivos.
4. mount: esta unidad encapsula un punto de montaje en la jerarquía del sistema de archivos. Systemd monitoriza todos los puntos de montaje como llegan y van, y también puede ser usado para montar o desmontar puntos de montaje, valga la redundancia.
5. automount: este tipo de unidad encapsula un punto de montaje automático en la jerarquía del sistema de archivos.
6. target: este tipo de unidad se utiliza para la agrupación lógica de las unidades; en lugar de hacer algo por sí mismo, simplemente hace referencia a otras unidades, que por lo tanto pueden ser controladas conjuntamente.
7. snapshot: parecida a la unidad target, las instantáneas (snapshots) no hacen nada por sí mismas y su único propósito es hacer referencia a otras unidades. Son útiles para guardar estados o puntos de control para restaurar en caso de emergencia o a solicitud del usuario.

Recomiendo la lectura del artículo dedicado a desmitificar a systemd, publicado a propósito de la significativa cantidad de opositores al mismo.

Registros systemd y Pandora FMS

Si alguna vez queremos contribuir a desarrollar el código de systemd, podemos comenzar por leer las normas de codificación (estilo de escritura de la programación) en su sitio oficial en GitHub. Allí encontrarán deliciosos detalles tales como que para indentar debemos usar ocho espacios (aunque hay excepciones), o cosas mucho más importantes como cuáles funciones específicas del lenguaje C debemos utilizar.

En nuestro caso deseamos conocer los registros systemd y ello está especificado en el Formato Binario del Fichero del Diario (Journal File Format) de systemd. Allí está explicado, en profundidad, todo el proceso de registros de eventos, mensajes, errores, advertencias, etc., no solo de systemd sino de todo lo que ejecuta systemd.

Ahora bien, seamos prácticos ante todo, los registros systemd son hechos en formato binario y listos para ser enviados por Internet a cualquier otra máquina que hayamos designado para recogerlos… eso nos recuerda a syslog (concretamente syslog-ng, la nueva generación de syslog que agregó el envío por red de los registros). De manera predeterminada los registros systemd vienen para ser guardados en «/var/log/journal» y podemos ver el tamaño que ocupan con la instrucción sudo journalctl –disk-usage.

Aunque podemos activar la característica de que registre con mayor detalle, así como establecer límites de consumo de espacio en disco o tiempo a guardar, etc., para los que monitorizamos con Pandora FMS podemos hacer uso de la monitorización de registros (logs).

A partir de la versión 7.0 NG 712, Pandora FMS incorpora ElasticSearch para almacenar la información de logs, y partir de la actualización 717 de Pandora FMS 7.0 NG aparece un nuevo componente: el SyslogServer de Pandora FMS. La ventaja principal del SyslogServer de Pandora FMS consiste en complementar la unificación de logs. Este componente permite a Pandora FMS analizar el syslog de la máquina donde está ubicado, analizando su contenido y almacenando las referencias en nuestro servidor de ElasticSearch.

Teniendo así esta poderosa herramienta de monitorización podremos configurar syslog-ng para que lea directamente los registros systemd. O mejor aún, configurar el fichero journald.conf para que reenvíe los mensajes a syslog-ng. De antemano os digo que quedan muchos detalles adicionales, pero este artículo no pretende ser un manual o wiki: en la documentación de ambos programas podréis encontrar instrucciones precisas.

Configurando los registros systemd hacia syslog en journald conf

Registros systemd y virtualización en contenedores

Adicionalmente podemos monitorizar los contenedores y/o Docker (uno de ellos o ambos a la vez), porque generalmente en dichas máquinas virtuales no agregan systemd en aras de ahorrar memoria y ciclos de procesador. De nuevo los detalles precisos los podéis leer en este enlace para Docker y aquí para systemd-machined.service. Recordad siempre que contamos con el SyslogServer de Pandora FMS y ElasticSearch para poder manejar la ingente cantidad de datos y/o información que recibiremos, y atentos con el tránsito de red que aumentará también.

Registros systemd y Agentes Software de Pandora FMS

Ya para finalizar, podemos consultar los registros systemd con el comando journalctl y filtrar información con BASH y sus comandos GNU. Digamos que queremos ver los últimos inicios y apagados de nuestro equipo.

sudo journalctl –list-boots

Podremos filtrar por fecha con los parámetros –since no solamente pasando una fecha, sino también empleando comandos entrecomillados: si queremos ver los registros desde el día de ayer usaríamos –since «yesterday»; o seleccionar por unidades con –unit service, por ejemplo.

Los Agentes Software de Pandora FMS son pequeños programas instalados que extraen métricas con mínimo impacto sobre nuestros equipos. También podemos visualizar los registros systemd respectivos con la orden systemd analyze blame:

systemd-analyze blame

Con ni siquiera un tercio de segundo un Agente Software de Pandora FMS (como veis en el ejemplo de arriba) puede sacar datos importantes. Con journalctl podemos exportar nuestras consultas en formato JSON a fin de ser analizadas por otro software y extraer de manera rápida datos y campos precisos (esto se conoce como un program parser) para responder a un complemento (plugin) que hallamos desarrollado para los Agentes Software de Pandora FMS.

También el popular lenguaje de programación Python tiene librerías que podemos invocar con:

from systemd import journal

Y así acceder de manera directa a los registros systemd sin utilizar journalctl y entregar el o los resultados al Agente Software de Pandora FMS.

Antes de despedirnos, recuerda que puedes conocer mejor lo que Pandora FMS puede ofrecerte entrando aquí.

Si tienes que monitorizar más de 100 dispositivos también puedes disfrutar de una DEMO GRATUITA de 30 días de Pandora FMS Enterprise. Consíguela aquí.

No dudes en enviar tus consultas. ¡El equipo de Pandora FMS estará encantado de atenderte!