Syslog: la piedra angular de los registros del sistema

Este artículo es una pequeña revisión de syslog, un estándar (RFC 3164 y RFC 5424) de registro de mensajes (logs en terminología informática) ampliamente difundido en sistemas *nix. La pretensión es que, tras su lectura, obligue a plantear si es necesario diseñar un sistema de logs para nuestra aplicación o sería mejor integrarlo con el syslog del sistema, lo que muchos administradores del sistema nos agradecerán.

Antes de empezar ¿qué es un registro de mensajes/eventos? No es más que un lugar en el que almacenar lo que ha sucedido con un doble objetivo: detectar/solucionar problemas en el sistema y auditar las acciones acometidas. Lo más habitual es un fichero (o tabla en una BBDD), ya sea local o remoto, en el que cada línea almacena información que permita responder a las preguntas: ¿Cuándo? ¿Quién? ¿Dónde? ¿Qué?

De la definición anterior ya se vislumbran dos agentes: el mensaje producido y el almacenamiento. El estándar separa claramente estos conceptos: la generación de mensajes (desde sistemas operativos Unix, Linux, Solaris, Windows o MacOs hasta dispositivos de comunicación como routers) de su proceso/almacenamiento (fichero local o remoto, BBDD…) y posterior análisis.

Esta separación aporta una serie de beneficios. Por un lado, proporciona simplicidad para el desarrollador que genera los eventos con un determinado formato y no tiene que preocuparse por detalles de almacenamiento o registro remoto. Por el otro otorga una gran versatibilidad al administrador ya que los receptores proporcionan filtros, envío remoto (que permite recopilar todos los mensajes en una única ubicación), almacenamiento en múltiples soportes…

Esquema syslog en red

Esquema ideal de registro remoto de eventos usando el protocolo Syslog (Imagen: Maldito Nerd)

Por ello, bajo la denominación ‘syslog‘ se engloban varios componentes diferenciados: la biblioteca que usan las aplicaciones productoras de eventos, la aplicación/demonio que se encarga de almacenarlos y el protocolo de comunicación que emplean para intercambiar dichos mensajes. Rasquemos la superficie de cada uno de ellos.


Protocolo syslog

El protocolo define un único tipo de mensaje con tres campos que se transmite mediante el puerto UDP 514. Esto permite concentrar los registros de múltiples máquinas en un único punto simplificando la labor de gestión al administrador siendo habitual que múltiples dispositivos lo soporten.

El formato del mensaje se compone de:

  1. La cabecera contiene la prioridad, fecha y hora del mensaje, máquina, proceso (nombre e identificador) que lo ha generado y la versión del protocolo utilizado.
  2. Una serie de pares clave-valor con metadatos.
  3. El texto del mensaje.

La prioridad indicada en la cabecera realmente codifica dos valores (calculados mediante la fórmula 8 \ times facility + priority):

Recurso (facility):
Tipo de elemento que ha generado el mensaje. En el RFC 3164 se recopilan los valores generalmente utilizados en las distintas distribuciones en el momento de su redacción:

Valor Descripción
0 Mensajes del kernel
1 Mensajes del nivel de usuario
2 Sistema de correo
3 Demonios de sistema
4 Seguridad/Autorización
5 Mensajes generados internamente por syslogd
6 Subsistema de impresión
7 Subsistema de noticias sobre la red
8 Subsistema UUCP
9 Demonio de reloj
10 Seguridad/Autorización
11 Demonio de FTP
12 Subsistema de NTP
13 Inspección del registro
14 Alerta sobre el registro
15 Demonio de reloj
16 Uso local 0
17 Uso local 1
18 Uso local 2
19 Uso local 3
20 Uso local 4
21 Uso local 5
22 Uso local 6
23 Uso local 7
Severidad (priority/level):
Indica la gravedad del mensaje según una escala de ocho valores:

Valor Denominación Descripción
0 Emergencia EMERG Sistema inutilizable
1 Alerta ALERT Requiere intervención inmediata
2 Crítico CRIT Condición crítica
3 Error ERR Condición de error
4 Peligro WARN Condición de peligro
5 Aviso NOTICE Funcionamiento normal pero con condiciones reseñables
6 Información INFO Mensajes informativos
7 Depuración DEBUG Mensajes de depuración de bajo nivel

Para simplificar la generación de los mensajes según el protocolo, existe una librería de sistema que proporciona tres funciones básicas de uso: openlog, syslog y closelog. La mayoría de los lenguajes incorporan una API más o menos sofisticada sobre dicha biblioteca.

Receptores

En cuanto a los demonios de proceso y almacenamiento existen varias implementaciones. La funcionalidad básica de todas ellas se resume en: recibir los mensajes (locales o remotos) y escribirlos en algún soporte en base a un conjunto de reglas (por ejemplo, los de prioridad “warning” al fichero /var/log/warnings) especificadas por el administrador.

sysklogd:

Es la opción clásica. Bajo esta denominación realmente se esconden dos demonios separados: syslogd para mensajes de sistema y klogd para los mensajes del kernel.

La última versión publicada (1.5) data de 2007 con poca actividad desde entonces (tanto en el código como en las listas de correo).

syslog-ng “new generation”:

Es una alternativa al sysklogd aparecida a finales de la década de 1990. Sus mayores innovaciones pasan por añadir filtros más potentes (por ejemplo, filtrando por contenido) y la posibilidad de utilizar como transporte TCP, lo que lo hace teóricamente más fiable.

Actualmente está soportado por una empresa quién ha realizado un fork no libre en el que se realizan las principales innovaciones quedando la versión libre algo relegada a segundo plano.

rsyslog:

Es el último contendiente en sumarse a la partida, aparece en 2004, con el ánimo de impulsar la innovación frente al estancamiento de sysklogd y la versión libre de syslog-ng.

Además de las mejoras introducidas por syslog-ng, incorpora múltiples ideas innovadoras:

  • Modularidad en la configuración, que además es casi compatible con la original de sysklogd
  • Nuevo protocolo RELP, que mejora la fiabilidad sobre TCP evitando duplicados en caso de error
  • Escritura en disco local o remoto, volcado a BBDD nativo o envío de e-mail… con gestión automática de colas (en memoria o disco) en caso de ralentización o error de comunicación y planificación horaria.

También incorpora algunas pequeñas mejoras como marcas de tiempo con mayor precisión, soporte nativo de cifrado, repetidores intermedios…

El tándem syslogd/klogd ha sido la primera elección de las distribuciones. Poco a poco, las distintas distribuciones incorporaron syslog-ng como paquete opcional en el sistema pero pocas de ellas (SuSE 9 es la excepción) lo eligieron como opción por omisión.

En los últimos lanzamientos se ha producido una migración a rsyslog en prácticamente todas las distribuciones. Este salto se debe a varios factores determinantes (Ubuntu WhitePaper: Centralised logging with rsyslog incluye las razones de la migración en su página 10, amén de ser una buena guía de cómo diseñar un sistema de logs centralizados):

  • rsyslog incluye muchos avances respecto al clásico sysklogd y bastantes mejoras respecto a la estancada versión libre de syslog-ng que lo hacen más flexible, fiable y escalable.
  • La configuración es prácticamente compatible con los ficheros de configuración de sysklogd, al contrario que syslog-ng cuya configuración difiere radicalmente. Esto simplifica en gran medida la migración y, gracias a su sistema de inclusión modular, permite utilizar casi sin alterar configuraciones previas existentes.
  • El desarrollo tiene en cuenta dos factores importantes: fiabilidad y rendimiento, cualidades cada vez más críticas sobre todo en grandes configuraciones clúster o grid.

Conclusiones

Syslog se asienta sobre tres conceptos básicos: el dispositivo/aplicación generadora de eventos, el protocolo de comunicación y la aplicación/demonio que filtra dichos eventos y los escribe en un soporte según los deseos del administrador. Gracias a este diseño es posible recopilar información de múltiples fuentes, ya sean aplicaciones locales o de múltiples máquinas e, incluso, dispositivos conectados a la red.

Recopilar esta información, aunque importante, no es realmente útil: lo útil es poder analizarla. Desde análisis básicos realizados en consola (less /var/log/messages, grep -i buscar /var/log/messages | ccze -C…) hasta aplicaciones web que simplifican la navegación por los logs (php-syslog-ng, LogAnalyzer…).

Tras este pequeño y fugaz repaso espero que al menos quede un pequeño susurro en la memoria de la existencia de esta pequeña utilidad, habitualmente oculta en las bases de los sistemas operativos.