Ver y manipular registros de Systemd con Journalctl

El registro del sistema y de procesos son solo dos de las ventajas más cruciales de systemd. Cuando los registros están dispersos por todo el sistema, abarcan múltiples aplicaciones y son manejados por diferentes procesos y demonios, pueden ser difíciles de interpretar. Systemd proporciona una solución centralizada para administrar todos los registros de procesos del kernel y del espacio de usuario en un medio de compilación conocido como journal. Puede obtener más información sobre systemd en nuestro tutorial sobre cómo administrar servicios y unidades de systemd con systemctl. Todos los mensajes generados por servicios, initrd, kernels, etc. en un journal son manejados por el demonio journal. El propósito de esta guía es ilustrar cómo acceder y manipular los datos del journal utilizando journalctl.

Premisa básica

Independientemente de dónde se origine un mensaje, uno de los objetivos principales de systemd es permitir que su gestión se centralice. Dado que el proceso systemd se encarga de muchos de los procesos de arranque y de gran parte de la gestión de servicios, la forma en que se recopilan y se accede a los registros debería estandarizarse. Al recopilar datos de cualquier fuente disponible en una sola herramienta integral, journald los almacena en un formato binario. Esto permite que los datos estén fácilmente disponibles para una manipulación dinámica y sencilla.

Este enfoque tiene varias ventajas clave. Al tener un lugar central para recopilar todos los datos, los administradores pueden filtrar y mostrar solo los datos que necesitan. Por ejemplo, se pueden ver los datos de arranque de hace tres arranques del sistema. También podría significar el registro secuencial de entradas de servicios relacionados y rastrear de manera más efectiva un problema de comunicación entre ellos.

Gracias al almacenamiento binario, los datos se pueden mostrar en una variedad de formatos de salida según las necesidades del usuario en cada momento. Por ejemplo, un registro diario se puede ver en un formato syslog estándar. Pero si necesita analizar la tendencia de las interrupciones del servicio en forma de gráfico, la entrada se puede exportar como un JSON objeto, lo que lo hace compatible con un servicio de gráficos. Cuando necesite cambiar de formato según las demandas de la situación, no se requiere ninguna conversión ya que los datos son binarios y no se escriben en el disco en texto plano.

Dependiendo de las necesidades de cada uno, se puede implementar el journal de systemd con un syslog existente o puede reemplazar su funcionalidad. Systemd incluso puede complementar los mecanismos de registro existentes. Por ejemplo, múltiples servicios en un solo sistema pueden tener sus datos recopilados entrelazados en un solo sistema con el journal de systemd.

Configuración de la hora del sistema

Systemd, por defecto, mostrará los resultados en la hora local, un beneficio del registro binario del journal en la forma en que se pueden ver los registros. Alternativamente, se pueden ver en UTC. Por lo tanto, es importante asegurarse de que la zona horaria esté configurada correctamente antes de comenzar con el registro del journal. Para hacer esto, systemd está equipado con una herramienta llamada timedatectl. Comenzamos viendo qué zonas horarias están disponibles para usar mostrando una lista con las opciones de list-timezones:

Después de encontrar la zona horaria correspondiente a la ubicación de su servidor, la zona horaria se puede configurar usando la opción set-timezone:

Para probar y verificar que la zona horaria se muestra correctamente ahora, puede usar el comando timedatectl ya sea solo o agregando 'status:'

La primera línea muestra la hora local. Esta línea debe contener la hora correcta para su región local.

Visualización general de registros

El comando journalctl le permitirá ver los registros que ha recopilado el demonio journald. Cuando utiliza journalctl, cada entrada del journal del sistema se mostrará en la pantalla, con las entradas más antiguas listadas hacia la parte superior. Sin embargo, la lista completa de datos tendrá decenas de miles de líneas de longitud.

Quienes hayan utilizado el registro syslog estándar encontrarán el formato familiar, pero es importante tener en cuenta que esta recopilación de datos se incluye desde muchas fuentes, a diferencia del método syslog. Los registros incluirán el proceso de inicio temprano, el initrd y el kernel, así como los errores estándar de la aplicación.

Ahora que la hora local está configurada, todas las entradas comenzarán con marcas de tiempo en hora local, y esto está disponible para cada registro almacenado actualmente en el sistema, mostrándose toda la lógica mediante el uso de esta nueva información. Sin embargo, no está limitado a la hora local. Usando la bandera –utc, también puede mostrar las marcas de tiempo en UTC como bien:

Filtrado del diario por tiempo

Tener tantos datos disponibles es fantástico, pero examinarlos y ser capaz de absorberlos, por no hablar de procesarlos mentalmente, puede ser una tarea abrumadora. Con esto en mente, llegamos a la parte más importante de la función journalctl: el filtrado.

Visualización de registros del arranque actual

Si está buscando los datos en el diario del último reinicio, podría usar la función journalctl con una bandera -b. Esto mostrará toda la información de registro pertinente del reinicio más reciente de su sistema. Este comando le permitirá encontrar y administrar la información más pertinente para el entorno de trabajo actual:

Si el usuario decide no evaluar cada entrada individual, journalctl mostrará más de un día de arranques que se visualizarán en journalctl con cómodos separadores ‘Reboot’. Esto ayuda a separar lógicamente la información de diferentes sesiones de arranque para su revisión:

Información de arranques anteriores

Aunque mostrar la información del arranque actual suele ser lo más útil, hay situaciones en las que la información de arranques anteriores resultará de ayuda. Journal guarda información de múltiples arranques anteriores, por lo que journalctl puede mostrar fácilmente la información de cualquier período de tiempo.

Ciertas distribuciones desactivan el guardado de la información de arranques anteriores, mientras que otras lo tienen activado por defecto. La activación de la información de arranque persistente se puede lograr creando un directorio para el almacenamiento del diario escribiendo lo siguiente:

Alternativamente, puede editar el archivo de configuración del diario de la siguiente manera:

Establecer la opción Storage= en “persistent” bajo la sección [Journal] habilitará el registro persistente:

Una vez habilitado esto, journalctl pone a disposición ciertos comandos que le ayudan a designar estos arranques como unidades de división. Para ver los arranques que se han registrado en journald, puede usar la opción –list-boots a través de journalctl:

Como se ilustra, cada arranque se enumerará en su propia línea, reflejando la primera columna los arranques anteriores en orden desde el más antiguo al más reciente. Si se necesita una referencia más absoluta, la segunda columna contiene la identificación del arranque. Después de eso, se enumeran dos especificaciones de tiempo. La información de la primera o de la segunda columna se puede utilizar para mostrar la información del diario del arranque específico. Por ejemplo, puede usar la bandera -b con el puntero de arranque relativo -1 para ver la información del penúltimo reinicio:

De manera similar, el ID de arranque de la segunda columna también se puede utilizar de esta forma:

Ventanas de tiempo

Ver los arranques por ID es una opción, pero a menudo es más útil poder hacer referencia a arranques anteriores mediante una ventana de tiempo en el pasado que no necesariamente coincida con arranques específicos. Por ejemplo, esto es relevante en una situación en la que se trabaja con servidores de larga duración que no se reinician con frecuencia. El filtrado de límites de tiempo se puede realizar con límites de tiempo arbitrarios. Esto mostrará únicamente información sobre los reinicios que se encuentren dentro de una ventana de tiempo particular. Los parámetros de esta ventana se designan con las opciones –since y –until. Hay varios formatos disponibles para las opciones de tiempo. El formato de valor de tiempo absoluto es el siguiente:

Por lo tanto, si desea ver todos los arranques desde el 10 de enero de 2015 a las 5:15 PM, escriba el siguiente comando:

Si se omite alguno de los componentes, existen valores predeterminados integrados. Además, si se omite una fecha, se utiliza por defecto la fecha actual. Si el componente de la hora está ausente, la medianoche es el valor predeterminado (00:00:00). Si omite los segundos del componente de la hora, se establecerán de forma predeterminada en el punto inicial de ese minuto (00):

El journal puede entender atajos relacionados con el tiempo como “today”, “tomorrow”, “yesterday” y “now”. Palabras como “ago”, en conjunción con los calificativos antepuestos “-” y “+”, se pueden utilizar para construir un comando de tipo frase:

Si se le notificó de una interrupción del servicio que comenzó a las 9:00 y desea verificar los registros del journal hasta hace una hora, puede hacerlo con lo siguiente:

Como es evidente, definir una ventana de tiempo flexible para ver las entradas deseadas es muy sencillo.

Filtrar por interés del mensaje

Además de filtrar el journal por restricciones de tiempo, los datos también se pueden filtrar según el componente de servicio de interés. Systemd proporciona varios métodos para hacer esto.

Por unidad

Podría decirse que el parámetro de filtrado más útil es por la unidad de interés. Para filtrar por unidad, se puede aprovechar la opción -u. Por ejemplo, si desea ver todos los registros pertenecientes a la unidad Nginx, escriba el siguiente comando:

Siendo realistas, querrá combinar esto con un filtro de tiempo para mostrar las líneas de interés. Si desea verificar el servicio anterior y cómo ha funcionado hoy, puede hacer lo siguiente:

Esto es especialmente útil cuando se utiliza la capacidad del journal para compilar registros de múltiples unidades, especialmente aquellas que colaboran entre sí. Si el proceso Nginx está conectado a una unidad PHP-FPN para el procesamiento de contenido dinámico, las entradas se pueden fusionar en orden cronológico especificando ambas unidades:

Esto puede ayudar enormemente a notar la interacción de los programas y facilitar la depuración de sistemas en lugar de procesos individuales.

Por ID de grupo, proceso o usuario

Muchos servicios inician una multitud de subprocesos (procesos hijos) para realizar un trabajo específico. Si el ID de un proceso en particular está disponible, también se puede filtrar especificando el campo _PID. Si el PID de interés es 8088, se puede hacer lo siguiente:

Es posible que también desee ver las entradas registradas de un grupo o usuario en particular. Esto se puede lograr utilizando los filtros _GID y _UID. Si un servidor web se ejecuta bajo el usuario www-data, lo siguiente puede encontrar el ID necesario:

Con ese ID, puede ver los resultados filtrados del journal:

Systemd pone a disposición muchos campos para fines de filtrado. Algunos campos son aplicados por journald basándose en la información recopilada del sistema en el momento del registro, mientras que otros se pasan desde el proceso que se está registrando actualmente.

Un precalificador de _PID indica que la información se ha recopilado del sistema en el momento del registro. El journal registra e indexa el PID automáticamente durante el proceso de registro para que la capacidad de filtrado esté disponible más tarde. Para conocer los campos de journal disponibles, puede escribir:

Discutiremos algunos de estos más adelante en esta guía, pero por ahora, abordaremos algunas otras opciones útiles relacionadas con estos campos. Si desea ver todos los valores disponibles para un campo de journal en particular, puede usar la opción -F. Si desea ver lo que tiene el journal de systemd para los ID de grupo, se puede hacer lo siguiente:

Esto puede ayudar a construir filtros al proporcionar una lista completa de los valores que ha almacenado el campo de ID de grupo del journal.

Por ruta de componente

El filtrado también se puede realizar proporcionando una ubicación de ruta. Si la ruta es a un ejecutable, se mostrarán las entradas en journalctl si involucran a ese ejecutable. Si el ejecutable de interés es ‘bash’, puede escribir:

Aunque a veces no es posible hacerlo, si la unidad del ejecutable está disponible, puede generar un método de filtrado más claro e informativo.

Mostrar mensajes del kernel

Los mensajes del kernel, que normalmente se encuentran en la salida de dmesg, también se pueden recuperar del journal. Para que solo se muestren estos mensajes, utilizamos las opciones -k o -dmesg como parte de nuestro comando:

Los mensajes del arranque actual se mostrarán de forma predeterminada, pero se pueden especificar arranques anteriores mediante la utilización de la opción de selección mencionada anteriormente. Si busca mensajes de hace cinco arranques, al escribir esto obtendrá los resultados necesarios:

Por prioridad

Los administradores de sistemas a menudo prefieren filtrar por prioridad. Los registros de baja prioridad, aunque a menudo son útiles de ver, pueden ser confusos y contener muchas distracciones, lo que los hace menos digeribles durante el análisis. El uso de la opción -p en journalctl mostrará solo los mensajes de una prioridad específica, filtrando cualquier otra prioridad. Si desea mostrar entradas del nivel de error o superior, ingrese lo siguiente:

Ese comando devolverá todos los mensajes indicados como errores, alerta, emergencia o críticos, utilizando el journal los niveles estándar de mensería de syslog. Los niveles de prioridad se definen de acuerdo con un valor numérico, clasificados de mayor a menor:

• 0: emerg
• 1: alert
• 2: crit
• 3: err
• 4: warning
• 5: notice
• 6: info
• 7: debug

Cualquiera de los anteriores se puede utilizar indistintamente con la opción -p. Al seleccionar cualquiera de las prioridades como se describió anteriormente, se filtrarán todas las prioridades de ese nivel y superiores.

Modificar la visualización en el Journal

Además de usar el filtrado para la selección de entradas, tenemos otros métodos para modificar la salida, adaptando la visualización de journalctl a nuestras necesidades.

Truncar/Expandir salida

Podemos ajustar la vista de nuestra salida configurando si journalctl reduce o expande los datos. El comportamiento predeterminado de journalctl es mostrar la entrada completa, dejando que las entradas más largas continúen hacia la derecha de la pantalla. Puede ver las entradas en su totalidad desplazándose con la tecla de flecha derecha. Es posible que un usuario desee truncar la salida en su lugar, indicando con puntos suspensivos las líneas que de otro modo se saldrían de la pantalla. Para esto, se puede usar la opción –no-full:

Alternativamente, también puede permitir que la visualización muestre todo, independientemente de la longitud o la inclusión de caracteres no imprimibles, utilizando la opción -a:

Salida a la salida estándar

Journalctl muestra la salida en un paginador de forma predeterminada, pero si desea manipular los datos con herramientas de edición de texto, es probable que necesite que la salida se genere en una opción de salida estándar. Puede lograr esto con la opción –no-pager:

Dependiendo de las necesidades del usuario, esto se puede redirigir a un archivo en el disco o a una utilidad de procesamiento.

Formatos de salida

Los datos siempre son más fáciles de analizar cuando se presentan en un formato más consumible. El diario proporciona múltiples opciones de visualización utilizando el calificador -o seguido de un formato denotado específicamente.

Si desea enviar las entradas del diario a un formato JSON, puede hacerlo de la siguiente manera:

Esta estrategia es particularmente útil con las utilidades de análisis. El formato json-pretty puede ser mejor para mostrar las estructuras de datos antes de pasarlas al consumidor JSON:

Hay varios formatos que puede utilizar para la visualización:

• cat: Muestra solo el campo del mensaje en sí.
• export: Un formato binario adecuado para transferir o realizar copias de seguridad.
• json: JSON estándar con una entrada por línea.
• json-pretty: JSON formateado para una mejor legibilidad humana
• json-sse: Salida formateada en JSON envuelta para que sea compatible con eventos enviados por el servidor
• short: La salida predeterminada de estilo syslog
• short-iso: El formato predeterminado aumentado para mostrar marcas de tiempo de reloj de pared ISO 8601.
• short-monotonic: El formato predeterminado con marcas de tiempo monotónicas.
• short-precise: El formato predeterminado con precisión de microsegundos
• verbose: Muestra todos los campos del diario disponibles para la entrada, incluidos aquellos que suelen estar ocultos internamente.

Las opciones anteriores permiten que el diario se muestre en su formato preferido.

Monitoreo de procesos activos

El diario permite acceder a funciones de monitoreo de actividad activa o reciente sin tener que involucrar otra herramienta. Puede hacer esto con el comando journalctl con una función 'tail'.

• Visualización de registros recientes

Mostrar la opción -n (que funciona igual que el comando tail -n), permitirá la visualización de una cierta cantidad de registros:

La cantidad de entradas que desea que se muestren se puede especificar con un número particular después del calificador -n:

• Seguimiento de los registros

También puede seguir los registros activamente a medida que se escriben en el sistema con la bandera -f. Esto también funciona de la misma manera que el comando tail -f:

Mantenimiento del diario

Los registros ocupan espacio. Vale la pena explorar esto, potencialmente para borrar algunos de los registros más antiguos para liberar espacio.

Búsqueda del uso actual del disco

La bandera –disk-usage puede ayudar a identificar cuánto espacio está ocupando actualmente el registro en el disco:

Eliminación de registros antiguos

Con la versión 218 de systemd (y versiones posteriores) puede reducir el diario de dos maneras diferentes. Una es la opción –vacuum-size. Esto puede reducir el diario indicando su tamaño. En otras palabras, las entradas más antiguas se purgarán del registro hasta que el espacio ocupado esté en el parámetro solicitado:

La opción –vacuum-time puede reducir la ocupación de espacio del diario indicando un tiempo de corte, cualquier entrada más allá de la cual será eliminada, mientras que las creadas después del tiempo especificado se conservarán. Si desea conservar las entradas de solo el último año calendario, puede usar:

Limitar la expansión del diario

También puede limitar la cantidad de espacio que ocupará el diario. Esto se logra editando el archivo /etc/systemd.journald.conf. El crecimiento del diario se puede limitar utilizando cualquiera de los siguientes métodos:

• SystemMaxUse=: Denota el espacio máximo en disco que el diario tiene permitido usar en el almacenamiento persistente.
• SystemKeepFree=: Denota cuánto espacio debe dejarse libre cuando se agregan las entidades del diario en el almacenamiento persistente.
• SystemMaxFileSize=: Especifica qué tan grandes se permite que crezcan los archivos de diario hasta la rotación en el almacenamiento persistente.
• RuntimeMaxUse=: Especifica cuánto espacio de disco se permite utilizar en el almacenamiento volátil (dentro del sistema de archivos /run).
• RuntimeKeepFree=: Al escribir datos en el almacenamiento volátil, esta función denota la cantidad de espacio que debe dedicarse a otros usos (dentro del sistema de archivos /run).
• RuntimeMaxFileSize=: Denota cuánto espacio puede ocupar un diario de registro individual en el almacenamiento volátil (dentro del sistema de archivos /run) antes de que deba ser prorrateado.

Todas estas opciones pueden ayudar a controlar el consumo de almacenamiento por parte del diario. Un dato importante a tener en cuenta es que las opciones SystemMaxFileSize y RuntimeMaxFileSize se dirigirán a los archivos archivados para alcanzar los límites establecidos. Este es un hecho importante a tener en cuenta al interpretar los recuentos de archivos después de las operaciones de vaciado.

Conclusión

Es evidente que el diario de systemd es una herramienta increíblemente útil de aprovechar, y la mayoría de sus beneficios provienen de la naturaleza centralizada de los logs’ y del extenso volumen de metadatos registrados. Las amplias características del diario se pueden aprovechar mediante la utilización del comando journalctl, lo que promueve un método más sencillo para realizar la depuración relacional de los componentes de la aplicación, así como un análisis exhaustivo del sistema.

¡Feliz computación!