6. Journald

Logs del sistema con Systemd y «el journal»

Fichero de configuración: /etc/systemd/journald.conf

journalctl: comando para examinar el log del journal, básicamente muestra lo mismo que /var/log/messages con ciertas mejoras:
# El log se muestra con el visualizador favorito, típicamente less
# La salida incluye todos los logs accesibles, incluso aquellos que han sido rotados
# Los logs con prioridad notice o warning son mostrados en negrita
# Los logs con prioridad error o superior aparecen en rojo

Systemd es una renovación del software de linux que asegura las operaciones básicas de un equipo.
En un modo estricto, systemd se encarga de iniciar y seguir servicios y gestionar recursos.
Además, systemd contiene un acercamiento al sistema de logs que es marcadamente diferente del tradicional syslogd, «el journal», y los componentes de software necesario para implementarlo.

Mientras que en el acercamiento tradicional el demonio syslog acepta los mensajes en el puerto 514/UDP o el socket /dev/log, en systemd los servicios en segundo plano pueden simplemente escribir mensajes de log a su canal stderr y systemd se las arreglará para pasarlo al servicio de logs.
Con systemd los ficheros de log no son ficheros de texto, donde cada mensaje es enviado posiblemente a varios archivos, si no que los mensajes son escritos a una base de datos binaria que puede ser consultada de acuerdo a diferentes criterios.

-O- Por ejemplo, es fácil mostrar todos los mensajes guardados por un servicio específico durante un período de tiempo concreto. Esto era complicado de realizar con el sistema tradicional.

-O- Para ser justos, deberíamos apuntar que las implementaciones modernas de syslog como rsyslog o syslog-NG son, en principio, capaces de escribir mensajes de log a una base de datos. Sin embargo, será responsabilidad del administrador hacer una estructura adecuada de la base de datos, para configurar los servicios adecuadamente y para desarrollar software que permita acceder convenientemente a los mensajes de log. Systemd incluye todo esto de forma implícita.

-O- El journal no está limitado a mensajes de log textuales. Es, por ejemplo, perfectamente posible almacenar volcados de fallos de programas en el journal (mientras no sean de tamaños desproporcionadamente grandes).

Los logs de systemd pueden ser leídos con los métodos tradicionales. Si se desea, los mensajes de log que llegan a /dev/log o el puerto 514/UDP pueden ser registrados, y puede pasar los mensajes al demonio tradicional syslog.
Si se quiere mostrar los logs recientes de un serivicio se puede utilizar, por ejemplo, systemctl status servicio, que devolverá el estado y las últimas líneas de log.
Si se quiere mostrar más líneas, systemctl status -l servicio

#systemctl status ssh
. ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: active (running) since Mo 2015-07-27 13:37:22 CEST; 8h ago
Main PID: 428 (sshd)
CGroup: /system.slice/ssh.service
..428 /usr/sbin/sshd -D

Jul 27 13:37:23 blue sshd[428]: Server listening on 0.0.0.0 port 22.
Jul 27 13:37:23 blue sshd[428]: Server listening on :: port 22.
Jul 27 13:56:50 blue sshd[912]: Accepted password for hugo from ...sh2
Jul 27 13:56:50 blue sshd[912]: pam_unix(sshd:session): session ...=0)
Hint: Some lines were ellipsized, use -l to show in full.

 

Systemd y Journald
El Journal es una parte integrada de systemd. En el caso más simple, systemd utiliza una cantidad limitada de memoria en un anillo de buffer en /run/log/journal para almacenar un cierto número de mensajes de log en RAM. Para obtener ventajas de todas las funciones del Journal, debes asegurarte que los mensajes de log son guardados en disco permanentemente. Se realiza simplemente creando el directorio para el almacenamiento:

# mkdir -p /var/log/journal
# systemctl --signal=USR1 kill systemd-journald

-O- El componente de systemd que se encarga del Journal es systemd-journald, o journald para sus amigos.

Al igual que logrotate, systemd rota el Journal para hacer sitio a nuevos mensajes. Para hacerlo, el espacio disponible es subdividido en un número de ficheros, para que el más antiguo pueda ser descartado si es necesario. Esta rotación es transparente para el usuario, ya que journald la gestiona cuando es necesario y journalctl siempre evalua el Journal completo, sin importar en cuántos archivos consista.

 

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg

· Storage: puede tomar los valores:
volatile: los mensajes se guardan solamente en RAM (/run/log/journal)
incluso si existe /var/log/journal
persistent: los logs son almancenado en el disco preferiblemente.
Durante las primeras instancias de arranque, si no se puede escribir en
disco, se utiliza /run/log/journal
auto: parecido a persistente, pero la existencia de /var/log/journal
determina si se escribirá un log persistente
none: no se almacenan mensajes de log en el journal, de todas formas, se
pueden pasar los mensajes a syslog

· Compress: especifica si los ficheros de log, al menos los que exceden
cierto tamaño, serán comprimidas transparentemente. El valor por defecto
es sí.

· Seal: permite asegurar que los ficheros persistentes de Journal son
protegidos contra manipulaciones externas mediante una firma
criptográfica. Solamente se necesitará una clave, el manual explica cómo.

· RateLimitInterval / RateLimitBurst: se supone que hacen más difícil
inundar el log con mensajes. Si un servicio produce más del
RateLimitBurst durante un período de tiempo dado por RateLimitInterval,
los mensajes que restan durante dicho período son ignorados, el log
contendrá un número que dice los mensajes ignorados. Por defecto el
límite es más de 1000 mensajes en 30 segundos. Poner a cero cualquiera
de los parámetros elimina la restricción

· SystemMaxFilesize y RuntimeMaxFileSize: gobiernan la subdivisión de ficheros. Especifican qué tamaño puede alcanzar cada ficero, por defecto 1/8 del tamaño disponible para el Journal, por lo que siempre habrá, por defecto, un histórico de 7 archivos mas el actual.

· MaxFileSec: asegura una rotación del log en función de un tiempo determinado. Valor por defecho 1 mes, 0 significa ilimitado.

· MaxRetentionSec: define cuánto tiempo son guardados los ficheros de log antiguos. El valor por defecto es 0, es decir, está deshabilitado.

· ForwardToSyslog: configura el envío de mensajes al sistema tradicional

· SyncIntervalSec: especifica qué tan a menudo se escribe el Journal al disco. Será guardado inmediatamente después que un mensaje de prioridad crit o superior sea logueado. Mientras no llegue este tipo de mensaje, journald esperará el tiempo especificado, por defecto, 5 minutos.

· SystemMaxUse y RuntimeMaxUse: describen ćuanto espacio puede ocupar el Journal en /var/log/journal y /run/log/journal, respectivamente. Valor por defecto, 10%.

· SystemKeepFree y RuntimeKeepFree: determinan cuanto espacio debe ser reservado en los fihceros definidos. Valor por defecto, 15%.
Systemd-journald toma los valores …MaxUse y …KeepFree y los confina a lo mínimo dictado por los dos.
Los valores Runtime… son usados cuando el sistema está arrancando o no se usa un Journal persistente. Los valores System… se aplican al Journal persistente si el sistema ha arrancado. Cuando se determinal el espacio usado por Journal, solamente se tienen en cuenta los ficheros con terminación .journal.
Se pueden especificar tamapos en unidades binarias, K, M, G, T, P y E (tibibytes, petabibytes y exbibytes no serán muy usados hoy en día, pero quién sabe).