La letra efe en Pandora FMS es por flexibilidad y los registros systemd, sin exención, pueden ser monitorizados en esta prueba de concepto que traigo hoy por acá, ¿pero qué es systemd, cómo funciona, qué hace? ¡Acompañadme!
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.
Lo que yo expreso aquí no es la posición oficial de Pandora FMS ni el parecer ni la opinión de su equipo de desarrollo. Consultad la hoja de ruta oficial en este enlace.
https://pandorafms.com/es/roadmap/
sysvinit
sysvinit era un programa init que, después que el kernel Linux estaba 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 de 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 está corriendo, sysvinit finalizaba liberando así recursos de memoria: sysvinit era un «ciao y adiós». Cualquier otra cosa que necesitáramos, pues lo debíamos ejecutar por nuestra orden directa. Era un proceso lento y muy ordenado pero ¿cuántas veces reiniciamos 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 el servidor de hora estaba apagado o fuera de línea (o cualquier otra causa).
Aparte de todo esto, también debemos considerar el costo de ejecutar guiones BASH que llaman una y otra vez las mismas funciones (cat, grep, etc.): para 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 @pid_eins ), Kay Sievers ( trabajaba para Novell), Harald Hoyer (trababa para Red Hat) y Dhaval Giani ( exempleado 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 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étera) para denotar donde se inserta la unidad central de procesamiento: «zócalo de procesador». Pero, para evitar confusiones, pienso que es mejor seguir usando al 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 pues es probable que quede de ú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: control groups (luego abreviado cgroups).
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 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, 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 allí. 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:
- service: aparte de encargarse de todos los daemons, también soporta la compatibilidad de guiones de SysV, dado el caso algún programa utilice esa tecnología.
- socket: sobre los que ya hablé anteriormente.
- device: para el manejo y control de dispositivos.
- 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.
- automount: este tipo de unidad encapsula un punto de montaje automático en la jerarquía del sistema de archivos.
- 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.
- 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 PFMS
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 tales 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, práctico 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étera, 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: SyslogServer PFMS. La ventaja principal del SyslogServer PFMS 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 bien sea configurar a 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: buscad en la documentación de ambos programas para instrucciones precisas.
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 acá para systemd-machined.service. Recordad siempre que contamos con el SyslogServer PFMS y ElastiSearch para poder manejar la ingente cantidad de datos y/o información que recibiremos, atento(a)s con el tránsito de red que aumentará también.
Registros systemd y Agentes Software PFMS
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.
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 PFMS son pequeños programas instalados que extraen métricas con mínimo impacto sobre nuestros equipos y también podemos visualizar los registros systemd respectivos con la orden systemd analyze blame:
Con ni siquiera un tercio de segundo un Agente Software PFMS (como veis en el ejemplo de arriba) podemos 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 PFMS.
En este excelente artículo hay ejemplos sobre cómo usar BASH y desarrollar módulos para Agentes Software PFMS a ser ejecutados en un pequeño ordenador de placa modelo Raspberry, espero es sea de vuestro agrado.
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 resultado(s) al Agente Software PFMS.
| Título | Enlace |
|---|---|
| Here We Go Again, Another Linux Init: Intro to systemd | https://web.archive.org/web/20140323103616/http://www.linux.com:80/learn/tutorials/524577-here-we-go-again-another-linux-init-intro-to-systemd |
| systemd System and Service Manager | https://www.freedesktop.org/wiki/Software/systemd/ |
| Manage System Startup and Boot Processes on Linux with Upstart | https://web.archive.org/web/20150208032025/http://www.linux.com/learn/tutorials/404619-manage-system-startup-and-boot-processes-on-linux-with-upstart |
| Rethinking PID 1 | http://0pointer.de/blog/projects/systemd.html |
| Coding Style | https://github.com/systemd/systemd/blob/master/docs/CODING_STYLE.md |
| Journal File Format | https://systemd.io/JOURNAL_FILE_FORMAT/ |
| systemd v38 released Compatibility with classic syslog implementations is provided, via a socket /run/systemd/journal/syslog, to which all messages are forwarded, regardless whether they came in via /dev/log, the journal native protocol or any other source. To make your syslog implementaiton work with this make sure that it binds to that socket instead of /dev/log which is now systemd-journal property. | https://lwn.net/Articles/474968/ |
| systemd/Journal en Arch Linux | https://wiki.archlinux.org/index.php/Systemd/Journal |
| Use journalctl to View Your System's Logs | https://www.linode.com/docs/guides/how-to-use-journalctl/ |
| Linux logging guide: Understanding syslog, rsyslog, syslog-ng, journalctl | https://mytrashcode.com/linux-logging-guide |
| Docker Journald logging driver | https://docs.docker.com/config/containers/logging/journald/ |
| systemd-nspawn | https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html |
| systemd-machined | https://www.freedesktop.org/software/systemd/man/systemd-machined.service.html |
| syslog-ng and systemd journal | https://wiki.archlinux.org/index.php/Syslog-ng#syslog-ng_and_systemd_journal |
| Journalctl cheat sheet with 10+ commands to filter systemd logs | https://www.golinuxcloud.com/view-logs-using-journalctl-filter-journald/ |
| How to tail log entries through the systemd journal using Python | https://www.g-loaded.eu/2016/11/26/how-to-tail-log-entries-through-the-systemd-journal-using-python/ |
| Título | Enlace |
Antes de despedirnos, recuerda que Pandora FMS es un software de monitorización flexible, capaz de monitorizar dispositivos, infraestructuras, aplicaciones, servicios y procesos de negocio.
¿Quieres conocer mejor qué es lo que Pandora FMS puede ofrecerte? Descúbrelo entrando aquí: https://pandorafms.com/es
Si cuentas con más de 100 dispositivos para monitorizar puedes contactar con nosotros a través del siguiente formulario: https://pandorafms.com/es/contactar/
Además, recuerda que si tus necesidades de monitorización son más limitadas tienes a tu disposición la versión OpenSource de Pandora FMS. Encuentra más información aquí: https://pandorafms.org/es/
No dudes en enviar tus consultas. ¡El equipazo de Pandora FMS estará encantado de atenderte!