Cómo utilizar Journalctl para visualizar y manipular registros de Systemd

Introducción

Algunas de las ventajas más atractivas de systemdson las relacionadas con el registro de procesos y sistemas. Cuando se utilizan otras herramientas, los registros suelen estar dispersos por todo el sistema, gestionados por diferentes daemons y procesos, y pueden ser bastante difíciles de interpretar cuando abarcan varias aplicaciones. systemdintenta abordar estos problemas proporcionando una solución de gestión centralizada para registrar todos los procesos del núcleo y del espacio de usuario. El sistema que recopila y gestiona estos registros se conoce como diario .

El diario se implementa con el journalddemonio, que maneja todos los mensajes producidos por el núcleo, initrd, servicios, etc. En esta guía, analizaremos cómo utilizar la journalctlutilidad, que se puede utilizar para acceder y manipular los datos contenidos en el diario.

Idea general

Uno de los impulsos detrás del systemddiario es centralizar la gestión de registros independientemente de dónde se originen los mensajes. Dado que gran parte del proceso de arranque y la gestión de servicios se gestionan mediante el systemdproceso, tiene sentido estandarizar la forma en que se recopilan y se accede a los registros. El journalddemonio recopila datos de todas las fuentes disponibles y los almacena en un formato binario para una manipulación fácil y dinámica.

Esto nos brinda una serie de ventajas significativas. Al interactuar con los datos mediante una única utilidad, los administradores pueden mostrar dinámicamente los datos de registro según sus necesidades. Esto puede ser tan simple como ver los datos de arranque de tres arranques anteriores o combinar las entradas de registro de forma secuencial de dos servicios relacionados para depurar un problema de comunicación.

El almacenamiento de los datos de registro en formato binario también significa que los datos se pueden mostrar en formatos de salida arbitrarios según lo que necesite en ese momento. Por ejemplo, para la gestión diaria de registros, puede estar acostumbrado a ver los registros en el syslogformato estándar, pero si decide graficar las interrupciones del servicio más adelante, puede generar cada entrada como un objeto JSON para que su servicio de gráficos pueda utilizarla. Dado que los datos no se escriben en el disco en texto sin formato, no es necesario realizar ninguna conversión cuando necesite un formato diferente a pedido.

El systemddiario se puede utilizar con una syslogimplementación existente o puede reemplazar la syslogfuncionalidad, según sus necesidades. Si bien el systemddiario cubrirá la mayoría de las necesidades de registro de los administradores, también puede complementar los mecanismos de registro existentes. Por ejemplo, puede tener un syslogservidor centralizado que utilice para recopilar datos de varios servidores, pero también puede desear intercalar los registros de varios servicios en un solo sistema con el systemddiario. Puede hacer ambas cosas combinando estas tecnologías.

Configuración de la hora del sistema

Una de las ventajas de utilizar un diario binario para el registro es la posibilidad de ver los registros en UTC o en hora local a voluntad. De forma predeterminada, systemdlos resultados se mostrarán en hora local.

Por este motivo, antes de comenzar a trabajar con el diario, nos aseguraremos de que la zona horaria esté configurada correctamente. La systemdsuite incluye una herramienta llamada timedatectlque puede ayudar con esto.

Primero, vea qué zonas horarias están disponibles con la list-timezonesopción:

timedatectl list-timezones

Esto mostrará una lista de las zonas horarias disponibles en su sistema. Cuando encuentre la que coincida con la ubicación de su servidor, puede configurarla utilizando la set-timezoneopción:

sudo timedatectl set-timezone zone

Para asegurarse de que su máquina esté usando la hora correcta ahora, use el timedatectlcomando solo o con la statusopción. La pantalla será la misma:

timedatectl status

Output               Local time: Fri 2021-07-09 14:44:30 EDT           Universal time: Fri 2021-07-09 18:44:30 UTC                 RTC time: Fri 2021-07-09 18:44:31                Time zone: America/New_York (EDT, -0400)System clock synchronized: yes              NTP service: active          RTC in local TZ: no

La primera línea debe mostrar la hora correcta.

Visualización básica de registros

Para ver los registros que el journalddemonio ha recopilado, utilice el journalctlcomando.

Cuando se utiliza solo, cada entrada del diario que se encuentra en el sistema se mostrará en un buscapersonas (normalmente less) para que pueda navegar. Las entradas más antiguas aparecerán en la parte superior:

journalctl

Output-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_enFeb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules. . .

Probablemente tendrá que desplazarse por páginas y páginas de datos, que pueden tener decenas o cientos de miles de líneas si systemdhan estado en su sistema durante mucho tiempo. Esto demuestra la cantidad de datos disponibles en la base de datos del diario.

El formato resultará familiar para quienes estén acostumbrados al syslogregistro estándar. Sin embargo, en realidad recopila datos de más fuentes de las que syslogpueden recopilar las implementaciones tradicionales. Incluye registros del proceso de arranque inicial, el núcleo, el initrd y los errores estándar y de salida de la aplicación. Todos ellos están disponibles en el diario.

Es posible que notes que todas las marcas de tiempo que se muestran son la hora local. Esto está disponible para cada entrada de registro ahora que tenemos la hora local configurada correctamente en nuestro sistema. Todos los registros se muestran con esta nueva información.

Si desea mostrar las marcas de tiempo en UTC, puede utilizar la --utcbandera:

journalctl --utc

Filtrado de diario por tiempo

Si bien tener acceso a una colección tan grande de datos es definitivamente útil, una cantidad tan grande de información puede resultar difícil o imposible de inspeccionar y procesar manualmente. Por eso, una de las características más importantes de journalctlson sus opciones de filtrado.

Visualización de registros del arranque actual

La más básica de ellas, que puedes usar a diario, es la -bbandera. Esta te mostrará todas las entradas del diario que se han recopilado desde el último reinicio.

journalctl -b

Esto le ayudará a identificar y gestionar la información que es pertinente a su entorno actual.

En los casos en los que no estés usando esta función y estés mostrando más de un día de arranque, verás que journalctlse ha insertado una línea que se ve así cada vez que el sistema deja de funcionar:

Output. . .-- Reboot --. . .

Esto se puede utilizar para ayudarle a separar lógicamente la información en sesiones de arranque.

Botas pasadas

Si bien es posible que desees mostrar la información del arranque actual, seguramente habrá ocasiones en las que también te resultará útil ver los arranques anteriores. El diario puede guardar información de muchos arranques anteriores, por lo que journalctlse puede configurar para que muestre información fácilmente.

Algunas distribuciones permiten guardar la información de arranque anterior de forma predeterminada, mientras que otras deshabilitan esta función. Para habilitar la información de arranque persistente, puede crear el directorio para almacenar el diario escribiendo:

sudo mkdir -p /var/log/journal

O puede editar el archivo de configuración del diario:

sudo nano /etc/systemd/journald.conf

En la [Journal]sección, configure la Storage=opción “persistente” para habilitar el registro persistente:

/etc/systemd/journald.conf

. . .[Journal]Storage=persistent

Cuando se activa la opción de guardar los booteos anteriores en el servidor, journalctlse proporcionan algunos comandos para ayudarlo a trabajar con booteos como unidad de división. Para ver los booteos que journaldconoce, use la --list-bootsopción con journalctl:

journalctl --list-boots

Output-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC

Esto mostrará una línea para cada inicio. La primera columna es el desplazamiento para el inicio que se puede usar para hacer referencia fácilmente al inicio con journalctl. Si necesita una referencia absoluta, el ID de inicio se encuentra en la segunda columna. Puede saber la hora a la que se refiere la sesión de inicio con las dos especificaciones de hora que se enumeran hacia el final.

Para mostrar información de estas botas, puede utilizar la información de la primera o de la segunda columna.

Por ejemplo, para ver el diario del arranque anterior, utilice el -1puntero relativo con la -bbandera:

journalctl -b -1

También puedes usar el ID de arranque para recuperar los datos de un arranque:

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

Ventanas de tiempo

Si bien ver las entradas de registro por arranque es increíblemente útil, a menudo es posible que desee solicitar ventanas de tiempo que no se alinean bien con los arranques del sistema. Esto puede ser especialmente cierto cuando se trabaja con servidores de larga duración con un tiempo de actividad significativo.

Puede filtrar por límites de tiempo arbitrarios utilizando las opciones --sincey --until, que restringen las entradas mostradas a aquellas posteriores o anteriores a la hora dada, respectivamente.

Los valores de tiempo pueden presentarse en distintos formatos. Para valores de tiempo absolutos, debe utilizar el siguiente formato:

YYYY-MM-DD HH:MM:SS

Por ejemplo, podemos ver todas las entradas desde el 10 de enero de 2015 a las 5:15 p. m. escribiendo:

journalctl --since "2015-01-10 17:15:00"

Si se omiten los componentes del formato anterior, se aplicarán algunos valores predeterminados. Por ejemplo, si se omite la fecha, se asumirá la fecha actual. Si falta el componente de hora, se sustituirá por “00:00:00” (medianoche). También se puede omitir el campo de segundos para que el valor predeterminado sea “00”:

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

El diario también entiende algunos valores relativos y atajos con nombre. Por ejemplo, puedes usar las palabras “ayer”, “hoy”, “mañana” o “ahora”. Puedes usar horas relativas anteponiendo “-” o “+” a un valor numérico o usando palabras como “hace” en la construcción de una oración.

Para obtener los datos de ayer, puedes escribir:

journalctl --since yesterday

Si recibió informes de una interrupción del servicio que comenzó a las 9:00 a. m. y continuó hasta hace una hora, podría escribir:

journalctl --since 09:00 --until "1 hour ago"

Como puede ver, es relativamente sencillo definir ventanas de tiempo flexibles para filtrar las entradas que desea ver.

Filtrar por interés del mensaje

Anteriormente, aprendimos algunas formas de filtrar los datos del diario mediante restricciones de tiempo. En esta sección, analizaremos cómo filtrar en función del servicio o componente que le interese. El systemddiario ofrece diversas formas de hacerlo.

Por unidad

Quizás la forma más útil de filtrar es por la unidad que nos interesa. Podemos utilizar la -uopción para filtrar de esta manera.

Por ejemplo, para ver todos los registros de una unidad Nginx en nuestro sistema, podemos escribir:

journalctl -u nginx.service

Por lo general, probablemente también quieras filtrar por hora para mostrar las líneas que te interesan. Por ejemplo, para comprobar cómo está funcionando el servicio hoy, puedes escribir:

journalctl -u nginx.service --since today

Este tipo de enfoque resulta extremadamente útil cuando se aprovecha la capacidad del diario de intercalar registros de varias unidades. Por ejemplo, si el proceso Nginx está conectado a una unidad PHP-FPM para procesar contenido dinámico, puede fusionar las entradas de ambos en orden cronológico especificando ambas unidades:

journalctl -u nginx.service -u php-fpm.service --since today

Esto puede hacer que sea mucho más fácil detectar las interacciones entre diferentes programas y sistemas de depuración en lugar de procesos individuales.

Por ID de proceso, usuario o grupo

Algunos servicios generan una variedad de procesos secundarios para realizar el trabajo. Si ha descubierto el PID exacto del proceso que le interesa, también puede filtrarlo por ese valor.

Para ello podemos filtrar especificando el _PIDcampo. Por ejemplo, si el PID que nos interesa es 8088, podemos escribir:

journalctl _PID=8088

En otras ocasiones, es posible que desee mostrar todas las entradas registradas de un usuario o grupo específico. Esto se puede hacer con los filtros _UIDo _GID. Por ejemplo, si su servidor web se ejecuta bajo el www-datausuario, puede encontrar el ID del usuario escribiendo:

id -u www-data

Output33

Posteriormente, puedes utilizar el ID que se devolvió para filtrar los resultados del diario:

journalctl _UID=33 --since today

El systemddiario tiene muchos campos que se pueden utilizar para filtrar. Algunos de ellos se transfieren desde el proceso que se está registrando y otros se aplican utilizando journaldla información que recopila del sistema en el momento del registro.

El guión bajo inicial indica que el _PIDcampo es del último tipo. El diario registra e indexa automáticamente el PID del proceso que se está registrando para su posterior filtrado. Puede obtener información sobre todos los campos de diario disponibles escribiendo:

man systemd.journal-fields

En esta guía, analizaremos algunos de ellos. Sin embargo, por ahora, repasaremos otra opción útil relacionada con el filtrado por estos campos. La -Fopción se puede utilizar para mostrar todos los valores disponibles para un campo de diario determinado.

Por ejemplo, para ver para qué ID de grupo systemdtiene entradas el diario, puede escribir:

journalctl -F _GID

Output32991021338184100012487

Esto le mostrará todos los valores que el diario ha almacenado para el campo de ID de grupo. Esto puede ayudarle a crear sus filtros.

Por ruta de componente

También podemos filtrar proporcionando una ubicación de ruta.

Si la ruta lleva a un ejecutable, journalctlse mostrarán todas las entradas que incluyan el ejecutable en cuestión. Por ejemplo, para buscar las entradas que incluyan el bashejecutable, puede escribir:

journalctl /usr/bin/bash

Por lo general, si hay una unidad disponible para el ejecutable, ese método es más limpio y brinda mejor información (entradas de procesos secundarios asociados, etc.). Sin embargo, a veces esto no es posible.

Visualización de mensajes del kernel

Los mensajes del kernel, aquellos que normalmente se encuentran en dmesgla salida, también se pueden recuperar del diario.

Para mostrar solo estos mensajes, podemos agregar los indicadores -ko --dmesga nuestro comando:

journalctl -k

De forma predeterminada, se mostrarán los mensajes del kernel del arranque actual. Puede especificar un arranque alternativo utilizando los indicadores de selección de arranque normales que se analizaron anteriormente. Por ejemplo, para obtener los mensajes de los cinco arranques anteriores, puede escribir:

journalctl -k -b -5

Por prioridad

Un filtro que suele interesar a los administradores de sistemas es la prioridad de los mensajes. Si bien suele ser útil registrar la información en un nivel muy detallado, cuando se analiza realmente la información disponible, los registros de baja prioridad pueden resultar confusos y distraer.

Puede journalctlutilizar la opción para mostrar solo los mensajes de una prioridad determinada o superior -p. Esto le permite filtrar los mensajes de menor prioridad.

Por ejemplo, para mostrar solo las entradas registradas en el nivel de error o superior, puede escribir:

journalctl -p err -b

Esto le mostrará todos los mensajes marcados como error, crítico, alerta o emergencia. El diario implementa los syslogniveles de mensajes estándar. Puede utilizar el nombre de prioridad o su valor numérico correspondiente. En orden de mayor a menor prioridad, estos son:

• 0 : emergencia
• 1 : alerta
• 2 : crítica
• 3 : err
• 4 : advertencia
• 5 : aviso
• 6 : información
• 7 : depuración

Los números o nombres anteriores se pueden usar indistintamente con la -popción. Al seleccionar una prioridad, se mostrarán los mensajes marcados en el nivel especificado y los que estén por encima de él.

Modificación de la visualización del diario

Arriba, demostramos la selección de entradas mediante filtrado. Sin embargo, existen otras formas de modificar el resultado. Podemos ajustar la journalctlvisualización para que se ajuste a distintas necesidades.

Truncar o expandir la salida

Podemos ajustar la forma en que journalctlse muestran los datos diciéndole que reduzca o amplíe la salida.

De forma predeterminada, journalctlse mostrará la entrada completa en el buscapersonas, lo que permitirá que las entradas se muestren a la derecha de la pantalla. Se puede acceder a esta información presionando la tecla de flecha derecha.

Si prefieres truncar la salida, insertando puntos suspensivos donde se ha eliminado información, puedes usar la --no-fullopción:

journalctl --no-full

Output. . .Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot

También puedes hacer lo contrario y decirle journalctlque muestre toda su información, independientemente de si incluye caracteres no imprimibles. Podemos hacer esto con la -abandera:

journalctl -a

Salida a salida estándar

De forma predeterminada, journalctlmuestra la salida en un buscapersonas para facilitar su uso. Sin embargo, si planea procesar los datos con herramientas de manipulación de texto, probablemente desee poder enviarlos a la salida estándar.

Puedes hacer esto con la --no-pageropción:

journalctl --no-pager

Esto se puede enviar inmediatamente a una utilidad de procesamiento o redirigir a un archivo en el disco, según sus necesidades.

Formatos de salida

Si está procesando entradas de diario, como se mencionó anteriormente, lo más probable es que le resulte más fácil analizar los datos si están en un formato más fácil de usar. Afortunadamente, el diario se puede mostrar en una variedad de formatos según sea necesario. Puede hacerlo utilizando la -oopción con un especificador de formato.

Por ejemplo, puede generar las entradas del diario en JSON escribiendo:

journalctl -b -u nginx -o json

Output{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }. . .

Esto es útil para analizar con utilidades. Puede utilizar el json-prettyformato para comprender mejor la estructura de datos antes de pasársela al consumidor JSON:

journalctl -b -u nginx -o json-pretty

Output{"__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635","__REALTIME_TIMESTAMP" : "1422990364739502","__MONOTONIC_TIMESTAMP" : "27200938","_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d","PRIORITY" : "6","_UID" : "0","_GID" : "0","_CAP_EFFECTIVE" : "3fffffffff","_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee","_HOSTNAME" : "desktop","SYSLOG_FACILITY" : "3","CODE_FILE" : "src/core/unit.c","CODE_LINE" : "1402","CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading","SYSLOG_IDENTIFIER" : "systemd","MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5","_TRANSPORT" : "journal","_PID" : "1","_COMM" : "systemd","_EXE" : "/usr/lib/systemd/systemd","_CMDLINE" : "/usr/lib/systemd/systemd","_SYSTEMD_CGROUP" : "/","UNIT" : "nginx.service","MESSAGE" : "Starting A high performance web server and a reverse proxy server...","_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"}. . .

Se pueden utilizar los siguientes formatos para la visualización:

• cat : muestra solo el campo del mensaje en sí.
• exportar : Un formato binario adecuado para transferir o realizar copias de seguridad.
• json : JSON estándar con una entrada por línea.
• json-pretty : formato JSON para una mejor legibilidad humana
• json-sse : salida con formato JSON envuelta para que sea compatible con el evento enviado por el servidor
• corto : La syslogsalida de estilo predeterminada
• short-iso : El formato predeterminado ampliado para mostrar las marcas de tiempo del reloj de pared ISO 8601.
• short-monotonic : el formato predeterminado con marcas de tiempo monótonas.
• short-precise : El formato predeterminado con precisión de microsegundos
• verbose : muestra todos los campos de diario disponibles para la entrada, incluidos aquellos que normalmente están ocultos internamente.

Estas opciones le permiten mostrar las entradas del diario en el formato que mejor se adapte a sus necesidades actuales.

Monitoreo activo de procesos

El journalctlcomando imita el que utilizan muchos administradores tailpara supervisar la actividad activa o reciente. Esta función está integrada en journalctl, lo que le permite acceder a estas funciones sin tener que recurrir a otra herramienta.

Visualización de registros recientes

Para mostrar una cantidad determinada de registros, puede utilizar la -nopción , que funciona exactamente como tail -n.

De forma predeterminada, se mostrarán las 10 entradas más recientes:

journalctl -n

Puede especificar la cantidad de entradas que desea ver con un número después de -n:

journalctl -n 20

Siguiendo registros

Para seguir activamente los registros a medida que se escriben, puede utilizar la -fbandera. Nuevamente, esto funciona como podría esperar si tiene experiencia con el uso de tail -f:

journalctl -f

Para salir de este comando, escriba CTRL+C.

Mantenimiento de la revista

Quizás te preguntes cuál es el costo de almacenar todos los datos que hemos visto hasta ahora. Además, puede que te interese limpiar algunos registros antiguos y liberar espacio.

Cómo encontrar el uso actual del disco

Puede averiguar la cantidad de espacio que el diario ocupa actualmente en el disco utilizando el --disk-usageindicador:

journalctl --disk-usage

OutputArchived and active journals take up 8.0M in the file system.

Eliminar registros antiguos

Si desea reducir el tamaño de su diario, puede hacerlo de dos maneras diferentes (disponibles con systemdla versión 218 y posteriores).

Si utiliza esta --vacuum-sizeopción, puede reducir el tamaño de su diario indicando un tamaño. Esto eliminará las entradas antiguas hasta que el espacio total del diario ocupado en el disco alcance el tamaño solicitado:

sudo journalctl --vacuum-size=1G

Otra forma de reducir el tamaño del diario es proporcionar una hora límite con la --vacuum-timeopción. Cualquier entrada posterior a esa hora se eliminará. Esto le permite conservar las entradas que se hayan creado después de una hora específica.

Por ejemplo, para conservar las entradas del último año, puede escribir:

sudo journalctl --vacuum-time=1years

Limitación de la expansión de la revista

Puede configurar su servidor para establecer límites en cuanto al espacio que puede ocupar el diario. Esto se puede hacer editando el /etc/systemd/journald.confarchivo.

Los siguientes elementos se pueden utilizar para limitar el crecimiento de la revista:

• SystemMaxUse=:Especifica el espacio máximo en disco que puede utilizar el diario en el almacenamiento persistente.
• SystemKeepFree=:Especifica la cantidad de espacio que el diario debe dejar libre al agregar entradas de diario al almacenamiento persistente.
• SystemMaxFileSize=:Controla el tamaño que pueden alcanzar los archivos de diario individuales en el almacenamiento persistente antes de rotarlos.
• RuntimeMaxUse=:Especifica el espacio de disco máximo que se puede utilizar en el almacenamiento volátil (dentro del /runsistema de archivos).
• RuntimeKeepFree=:Especifica la cantidad de espacio que se reservará para otros usos al escribir datos en un almacenamiento volátil (dentro del /runsistema de archivos).
• RuntimeMaxFileSize=:Especifica la cantidad de espacio que un archivo de diario individual puede ocupar en el almacenamiento volátil (dentro del /runsistema de archivos) antes de rotarse.

Al configurar estos valores, puede controlar cómo journaldse consume y se conserva el espacio en su servidor. Tenga en cuenta que SystemMaxFileSizey RuntimeMaxFileSizeapuntará a que los archivos archivados alcancen los límites establecidos. Es importante recordar esto al interpretar los recuentos de archivos después de una operación de limpieza.

Conclusión

Como puede ver, el systemddiario es increíblemente útil para recopilar y administrar los datos de su sistema y de su aplicación. La mayor parte de la flexibilidad proviene de los metadatos extensos que se registran automáticamente y de la naturaleza centralizada del registro. El journalctlcomando facilita el aprovechamiento de las características avanzadas del diario y la realización de análisis exhaustivos y depuración relacional de diferentes componentes de la aplicación.