Blog

Journal: El registro de logs de Systemd

La verdad, llevo mucho tiempo sin escribir y tengo muchas ganas de volver a darle a las teclas sin parar . En abril escribí un post sobre los logs y prometí profundizar en rsyslog, syslog-ng y journal. Ya es hora de empezar 😉

Hoy os voy hablar de Journal, dado que, la mayor parte de las distribuciones GNU/Linux están ya migradas a Systemd. La versión de CentOS y RedHat 7, ya vienen con él y, Debian en la próxima estable. Ubuntu le seguirá los pasos a esta última.

Systemd tiene su propio sistema de registros “logs”, journal, por lo tanto no necesitamos el demonio syslog. Una característica es que ya no se utilizarán archivos en texto plano, es por ello que, para leer el registro, utilizaremos journalctl.

journalctl [OPTIONS...] [MATCHES...]

Pero, antes de continuar vamos a explicar un poco cómo se configura.

Configurando Journal

Disponemos del fichero de configuración /etc/systemd/journald.conf,  con las siguientes opciones:

Storage

Aquí indicamos cómo queremos que se almacene el registro. Los posibles valores son:

  • Volatile: En este caso, el registro se almacena en /run/systemd/journal y es volátil (perdemos los registros en cada reinicio del equipo).
  • Persistent: Justo lo contrario al valor anterior: Se almacena en disco, en /var/log/journal.
  • Auto: Es similar a persistent, con la difirencia que, si no existe /var/log/journal, no se va a crear y se utilizará /run/systemd/journal, es decir, los logs serán volátiles. En el caso de Arch, ésta es la opición predeterminada y, aunque al instalar o reinstalar el paquete systemd, se crea el /var/log/journal, si lo borramos, los logs serán volátiles hasta la siguiente actualización.
  • None: No se almacenan los logs. Es útil cuando queremos redirigirlos a consola, un buffer o alguna implementación de syslog.

Compress

Por defecto está habilitado y comprimirá los datos recogidos.

Seal

Está habilitado por defecto y nos va a permitir proteger los archivos los archivos de regsitro de alteraciones inadvertidas. Es decir, nos puede ser útil para poder afirmar que el registro no ha sido modificado, cosa que no podíamos afirmar con el clásico sistema de logs en texto plano. Para hacer esto, debemos crear las claves con jornalctl –setup-keys

SplitMode

Nos va a permitir especifiar cómo queremos que se dividan los resgistros por usuario:

  • Uid: Cada usuario tendrá sus propios archivos de registro (por defecto).
  • Login: Cada usuario que inicie sesión tendrá su propio archivo de registro. Los logs de los usuarios que no disponen de sesión interactiva, se registrarán en el log del sistema.
  • None: Sólo existe un archivo, no se va a reailizar ninguna división.

RateLimitInterval, RateLimitBurst

Nos permitien limitar el número de mensajes que vamos a permitir almacenar por cada servicio, en un período de tiempo. Si se sobrepasan los mensajes por período de tiempo, se pierden y se genera un post con el número de mensajes perdidos. Los valores son de 1000 mensajes en 30 segundos. Se puede desactivar la limitación, estableciendo los valores a 0.

SystemMaxUse, SystemKeepFree, SystemMaxFileSize, RuntimeMaxUse, RuntimeKeepFree, RuntimeMaxFileSize

Estas opciones nos van a permitir limatar el tamaño el tamaño en disco (para el almacenamiento persistente) o en RAM (para el alamacenamiento volátil). Las opciones con prefijo System hacen referencia al disco y, con prefijo Runtime, a la RAM. Nos permiten “rotar” los archivos, para no tener archivos con un crecimiento sin límites.

MaxFileSec

Nos permite establecer una periocidad para la rotación de archivos, además de la vista anteriormente.

MaxRetentionSec

Nos permite establecer el tiempo máximo que vamos a gruardar las entradas antiguas.

SyncIntervalSec

Es el tiempo de espera antes de sincronizar los archivos de registro en el disco. Después de la sincronización, los archivos de registro se colocan en el estado OFFLINE. Esta configuración sólo se aplica a los niveles ERR, WARNING, NOTICE, INFO, DEBUG y está establecida a cinco minutos por defecto.

ForwardToSyslog,  ForwardToKMsg, ForwardToConsole, ForwardToWall

Nos permiten redirigir los logs. Por defecto, Syslog y Wall están habilitados. Por supuesto, si no disponemos de ningún daemon syslog corriendo en nuestro sistema, no tendrá ningún efecto. La opción ForwardToConsole nos permite dirigir los mensajes a una consola y, ForwardToWall, a todos los usuarios que tengan sesión iniciada en el sistema.

MaxLevelStore, MaxLevelSyslog, MaxLevelKMsg, MaxLevelConsole, MaxLevelWall

Estas opciones nos permiten controlar el tipo de mensaje, por nivel, que se van a redirigir.

TTYPath

La ruta donde queremos que se envíen los mensajes, cuando tenemos ForwardToConsole=yes. El valor predeterminado es /dev/console.

Los valores por defecto, son referentes a ArchLinux. En otras distribuiciones es posible que varíen.

Accediendo a la información

Una vez vista la configuración del journal, pasemos a ver cómo acceder a la información. Hasta ahora, estábamos acostumbrados a utilizar comandos como cat, grep, etc. para leer los logs. Esto es porque estaban en texto plano. Ahora, eso se ha acabado, y deberemos utilizar un comando específico, que nos irá devolviendo los datos. Este comando es journalctl. Para poder invocarlo con nuestro usuario, éste debe pertenecer al grupo log, en el caso de Arch. En todo caso, siempre podemos invocarlo con sudo, si nuestro usuario tiene privilegios de administrador (que pertenece al grupo wheel en el caso de Arch)

Si lo invocamos tal cual, sin argumentos, nos mostrará todos los logs del sistema, ordenados por fecha. Esto, en principio no es nada útil.

Algo que podíamos hacer con el sistema anterior, era un tail -f /var/log/messages. Esto nos permitía ver en tiempo real los mensajes que se iban generando. Algo similar podemos hacer con journalctl:

journalctl -f

Si queremos ver los mensajes del actual inicio del sistema, utilizaremos la opción -b:

journalctl -b

Para añadir un filtro y ver sólo los errores generados en este inicio:

journalctl -b -p err

La opción -p nos permite filtrar los mensajes por su prioridad: “emerg”,  “alert”,  “crit”, “err”, “warning”, “notice”, “info”, “debug”.

Muchas veces es necesario revisar los logs generados por un binario concreto. Esto podemos especificarlo de la siguiente manera:

journalctl /usr/bin/<nombre binario>

Si necesitamos ver los mensajes generados por dos binarios o más, los separamos con un espacio y, el filtro, funciona como un “y” lógico. Si lo que queremos es un “o” lógico (los mensajes generados por uno u otro, o los dos), utilizamos el signo “+”. Veamos un ejemplo, con unidades de servicio:

journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097 + _SYSTEMD_UNIT=dbus.service

En este ejemplo, hemos especifiaco que se muestren los mensajes producidos por la unidadad de servicio avahi-daemon, con pid 28097 y, además, también se muestren los producidos por la unidad dbus. En el caso de omitir el ” + “, solo se mostrarían los mensajes en que estuvieran emplicados los tres elementos.

Otra opción es, en lugar de especificar la unidad de servicio con _SYSTEMD_UNIT, utilizar el parámetro -u, que nos pertime filtrar por un patrón específico. Por ejemplo, queremos todos los mensajes generados por todas la unidades que incluyan avahi:

journalctl -u=avahi

Si necesitamos ver qué ha pasado con un dispositivo específico, bastará especificarlo al invocar el comando:

journalctl /dev/sda

Otra posibilidad es añadir un filtro para especificar un intervalo de tiempo. Esto se hace con los parámetros –since y –until. Podemos utilizar “yesterday”, “today”, “tomorrow”, o, bien, un formato de fecha/hora, siguiendo el siguiente formato: “2014-06-30 23:15:16”. Si omitios la parte de la hora, se tomará “00:00:00”. Si omitimos los segundos, se toman “:00”. En el caso de omitir el día, se tomará el día actual.

Para ver todos los campos que podríamos utilizar, os recomiendo visitar http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html, donde encontraréis todas las opciones disponibles.

Cómo podéis ver, además de añadir seguridad a los logs, al no estar en texto plano, con las opciones de filtrado se facilita mucho el trabajo de depuración, lo que nos vendrá genial para poder saber qué ocurre en nuestro sistema.

Esto es sólo una introducción, journal dispone de múltiples opciones y podríamos realizar filtrados mucho más complejos, además de enviar también los logs a daemons, como rsyslog. Por otra parte, disponemos de servicios, como es systemd-journal-gateway, que nos van a permitir accerder remotamente y, si se desea, con cifrado, a los eventos producidos en un determinado equipo.

Systemd ya ha llegado y va a cambiar bastante la vida de los sysadmin, para bien o para mal, así que, toca ir acostumbrándonos a este tipo cambios que, a mi parecer, son muy buenos.

¡Espero que os haya gustado! 😉

Un saludo!!

Mª José Montes – mjose@highsec.es – @MMontesDiaz

Leave a Reply

*

    No Twitter Messages