Analizar Registros en Red Hat Enterprise Linux

Introducción

En este laboratorio, obtendrá experiencia práctica con el análisis y almacenamiento de registros del sistema en Red Hat Enterprise Linux 9 utilizando journalctl y rsyslog. Comenzará comprendiendo la arquitectura central del registro del sistema, incluyendo los roles de systemd-journald y rsyslog, e identificando los archivos de registro clave. Posteriormente, aprenderá a revisar y filtrar archivos syslog utilizando comandos comunes, a enviar manualmente mensajes syslog personalizados, y a explorar y filtrar entradas del journal del sistema con journalctl. El laboratorio también cubre la configuración del almacenamiento persistente del journal del sistema y el mantenimiento de la hora precisa del sistema utilizando timedatectl y chronyd, equipándolo con habilidades esenciales para el análisis y la resolución de problemas del sistema.

Comprender la Arquitectura de Registros del Sistema y Archivos Clave

En este paso, aprenderá sobre los componentes fundamentales del registro del sistema en Red Hat Enterprise Linux 9, centrándose específicamente en los servicios systemd-journald y rsyslog, y los archivos de registro clave que gestionan. Comprender esta arquitectura es crucial para el análisis y la resolución de problemas del sistema de manera efectiva.

Primero, exploremos el servicio systemd-journald. Este servicio es el núcleo del registro de eventos del sistema operativo. Recopila mensajes de eventos de diversas fuentes, incluyendo el kernel del sistema, los procesos de inicio temprano, la salida estándar/error de los demonios y los eventos syslog. El servicio systemd-journald almacena estos registros en un archivo binario estructurado e indexado llamado el journal (diario).

A continuación, veremos el servicio rsyslog. Mientras que systemd-journald recopila los registros, rsyslog lee los mensajes syslog del journal a medida que llegan. Luego procesa estos mensajes y los registra en archivos de registro tradicionales en el directorio /var/log o los reenvía a otros servicios según su configuración. Estos archivos rsyslog persisten a través de los reinicios.

Examinemos algunos de los archivos de registro importantes gestionados por rsyslog en el directorio /var/log. Puede usar el comando ls para listar el contenido de este directorio.

ls /var/log

Verá una lista de varios archivos de registro. Según su sistema, debería ver archivos como anaconda, audit, boot.log, chrony, cron, dnf.log, messages, secure y otros. Algunos de los más comunes incluyen:

• /var/log/messages: Este archivo contiene la mayoría de los mensajes syslog generales, excluyendo aquellos relacionados con la autenticación, el procesamiento de correo electrónico, la ejecución de trabajos programados y la depuración.
• /var/log/secure: Este archivo almacena mensajes syslog relacionados con eventos de seguridad y autenticación.
• /var/log/maillog: Este archivo contiene mensajes syslog sobre el servidor de correo.
• /var/log/cron: Este archivo registra mensajes syslog sobre la ejecución de trabajos programados.
• /var/log/boot.log: Este archivo contiene mensajes de consola no syslog sobre el inicio del sistema.

Para ver el contenido de estos archivos, puede usar comandos como cat, less o tail. Tenga en cuenta que la mayoría de los archivos de registro en /var/log requieren privilegios de root para leerlos, por lo que necesitará usar sudo. Por ejemplo, veamos las últimas líneas del archivo /var/log/messages usando tail.

sudo tail /var/log/messages

También puede ver el contenido del archivo /var/log/secure, que es importante para la auditoría de seguridad.

sudo tail /var/log/secure

Comprender el propósito de estos archivos le ayudará a localizar rápidamente la información relevante al solucionar problemas del sistema.

Revisar y Filtrar Archivos Syslog con Comandos Comunes

En este paso, aprenderá a revisar y filtrar eficazmente los archivos syslog utilizando comandos comunes de Linux. Los mensajes syslog se categorizan por facility (qué subsistema produce el mensaje) y priority (la severidad del mensaje). Comprender estas categorías es crucial para un análisis de registro eficiente.

Primero, revisemos el concepto de Facilidades y Prioridades Syslog.

Facilidades Syslog (Syslog Facilities): Estas indican la fuente del mensaje de registro. Ejemplos incluyen kern (mensajes del kernel), user (mensajes a nivel de usuario), mail (mensajes del sistema de correo), daemon (mensajes de demonios del sistema), auth (mensajes de autenticación y seguridad) y cron (mensajes del demonio de reloj).

Prioridades Syslog (Syslog Priorities): Estas definen la severidad del mensaje, que va desde emerg (sistema inutilizable) hasta debug (mensaje a nivel de depuración). El orden de severidad de mayor a menor es: emerg, alert, crit, err, warning, notice, info, debug.

Los archivos de registro pueden crecer mucho, lo que dificulta la búsqueda de información específica. Por lo tanto, el filtrado es esencial. Puede usar comandos como grep, awk y sed para filtrar el contenido del archivo de registro.

Comencemos viendo todo el contenido de /var/log/messages usando less. Este comando le permite desplazarse por el archivo. Presione q para salir de less. Recuerde usar sudo ya que los archivos de registro requieren privilegios de root para leerlos.

sudo less /var/log/messages

Ahora, intentemos filtrar mensajes. Suponga que está interesado en mensajes relacionados con la autenticación. Estos mensajes se encuentran típicamente en /var/log/secure. Use grep para buscar líneas que contengan la palabra "authentication" en /var/log/secure. Recuerde usar sudo para acceder al archivo de registro.

sudo grep "authentication" /var/log/secure

Es posible que no vea ninguna salida si no hay mensajes de autenticación recientes. Intentemos un término de búsqueda más común, como "sshd", que se relaciona con el demonio SSH.

sudo grep "sshd" /var/log/secure

Debería ver la salida que muestra las actividades del demonio SSH, los intentos de autenticación u otros eventos relacionados con la seguridad. La salida exacta dependerá de la actividad actual del sistema y puede incluir entradas como:

Dec 16 10:15:30 host sshd[1234]: Accepted publickey for labex from 172.25.0.10 port 12345 ssh2
Dec 16 10:15:30 host sshd[1234]: pam_unix(sshd:session): session opened for user labex(uid=1000) by (uid=0)
...output omitted...

Los mensajes de registro también contienen marcas de tiempo. Puede filtrar mensajes por fecha y hora. Por ejemplo, para ver los mensajes de una fecha específica, puede combinar grep con la fecha. Intentemos encontrar mensajes de la fecha de hoy en /var/log/messages. Use el formato de fecha actual que aparece en los registros de su sistema.

sudo grep "$(date '+%b %d')" /var/log/messages

Rotación de Archivos de Registro (Log File Rotation):
Para evitar que los archivos de registro consuman demasiado espacio en disco, los sistemas utilizan logrotate. Esta utilidad rota los archivos de registro, renombrando los antiguos (por ejemplo, /var/log/messages se convierte en /var/log/messages-20220320) y creando otros nuevos y vacíos. Después de un cierto período (típicamente cuatro semanas), los archivos de registro rotados más antiguos se descartan. Un trabajo programado ejecuta logrotate diariamente para gestionar este proceso.

Puede observar los archivos de registro rotados al listar el contenido de /var/log nuevamente. Es posible que vea archivos con extensiones de fecha o extensiones .gz (si se han comprimido).

ls -l /var/log/messages*

Ejemplo de salida:

-rw-------. 1 root root 123456 Mar 20 23:59 /var/log/messages
-rw-------. 1 root root  78901 Mar 13 23:59 /var/log/messages-20220320
-rw-------. 1 root root  54321 Mar 06 23:59 /var/log/messages-20220313.gz
...output omitted...

Esto muestra cómo logrotate gestiona los archivos de registro más antiguos.

Finalmente, analicemos la anatomía de una entrada syslog. Un mensaje de registro típico en /var/log/secure se ve así:

Dec 16 10:11:48 host sshd[1433]: Failed password for student from 172.25.0.10 port 59344 ssh2

• Dec 16 10:11:48: La marca de tiempo de la entrada del registro.
• host: El host que envió el mensaje de registro.
• sshd[1433]: El nombre del programa o proceso (sshd) y su PID (1433) que envió el mensaje de registro.
• Failed password for …: El contenido real del mensaje.

Comprender este formato le ayuda a analizar e interpretar las entradas del registro de manera más efectiva.

Enviar Mensajes Syslog Personalizados Manualmente

En este paso, aprenderá a enviar mensajes syslog personalizados manualmente utilizando el comando logger. Esta es una técnica útil para probar las configuraciones del servicio rsyslog o para inyectar mensajes personalizados en los registros del sistema con fines de depuración o monitoreo.

El comando logger envía mensajes al servicio rsyslog. Por defecto, envía el mensaje con la facilidad user y la prioridad notice (user.notice), a menos que se especifique lo contrario con la opción -p.

Comencemos enviando un mensaje de prueba simple a la ubicación de registro predeterminada, que suele ser /var/log/messages.

logger "This is a test message from labex."

Después de ejecutar el comando, puede verificar que el mensaje se registró comprobando el archivo /var/log/messages. Use tail para ver las últimas líneas del archivo. Recuerde usar sudo para acceder al archivo de registro.

sudo tail /var/log/messages

Debería ver su mensaje personalizado al final de la salida, similar a esto:

...
Dec 16 10:30:00 host labex: This is a test message from labex.

Ahora, intentemos enviar un mensaje con una facilidad y prioridad específicas. Recuerde del paso anterior que los mensajes syslog se categorizan por facilidad y prioridad. Por ejemplo, local7.notice significa que el mensaje se registrará con la facilidad local7 y la prioridad notice. La facilidad local7 se usa a menudo para aplicaciones personalizadas o mensajes de inicio, y normalmente se dirige a /var/log/boot.log mediante la configuración de rsyslog.

Para enviar un mensaje al servicio rsyslog para que se registre en el archivo de registro /var/log/boot.log, ejecute el siguiente comando logger:

logger -p local7.notice "Log entry created by labex for boot.log"

Ahora, verifique que este mensaje se haya escrito en /var/log/boot.log. Use sudo para acceder al archivo de registro.

sudo tail /var/log/boot.log

Debería ver su mensaje personalizado en la salida:

...
Dec 16 10:31:00 host labex: Log entry created by labex for boot.log

Esto demuestra cómo puede controlar dónde se registran sus mensajes personalizados especificando la facilidad y la prioridad. Esta capacidad es muy útil para probar las configuraciones de rsyslog y para inyectar eventos específicos en los registros de su sistema.

Explorar y Filtrar Entradas del Journal del Sistema con journalctl

En este paso, aprenderá a explorar y filtrar las entradas del journal del sistema utilizando el comando journalctl. Como aprendió, el servicio systemd-journald almacena los datos de registro en un archivo binario estructurado e indexado llamado el journal. El comando journalctl es su herramienta principal para interactuar con este journal.

Comencemos viendo todos los mensajes en el journal. Cuando ejecuta journalctl sin ninguna opción, muestra todas las entradas de registro disponibles, comenzando por la más antigua. Dado que ha iniciado sesión como labex con privilegios sudo, tendrá acceso completo al journal.

journalctl

Verá una gran cantidad de salida. Presione q para salir del visor journalctl. Observe que journalctl resalta los mensajes de registro importantes: los mensajes con prioridad notice o warning están en negrita, mientras que los mensajes con prioridad error o superior están en texto rojo.

Ahora, exploremos algunas opciones comunes de journalctl para filtrar y ver entradas específicas.

1. Ver las últimas N entradas de registro (opción -n):
Por defecto, journalctl -n muestra las últimas 10 entradas de registro. Puede especificar un número diferente, por ejemplo, las últimas 5 entradas:

journalctl -n 5

Debería ver las 5 entradas de registro más recientes.

2. Seguir nuevas entradas del journal (opción -f):
Similar al comando tail -f, la opción journalctl -f muestra las últimas 10 líneas del journal del sistema y continúa mostrando nuevas entradas del journal a medida que se añaden. Esto es muy útil para la monitorización en tiempo real.

journalctl -f

Para salir de esta salida continua, presione Ctrl+C.

3. Filtrar por prioridad (opción -p):
Puede filtrar la salida por el nivel de prioridad de las entradas del journal. La opción journalctl -p muestra las entradas con un nivel de prioridad especificado (por nombre o por número) o superior. Los niveles de prioridad, en orden ascendente, son debug, info, notice, warning, err, crit, alert y emerg.

Listemos las entradas del journal con la prioridad err o superior:

journalctl -p err

Es posible que vea mensajes de error relacionados con varios componentes del sistema.

4. Filtrar por unidad systemd (opción -u):
Puede mostrar mensajes para una unidad systemd especificada utilizando la opción journalctl -u y el nombre de la unidad. Por ejemplo, para ver los registros específicamente para el servicio sshd:

journalctl -u sshd.service

Esto mostrará todas las entradas de registro relacionadas con el demonio SSH.

5. Filtrar por rango de tiempo (opciones --since y --until):
Cuando busca eventos específicos, puede limitar la salida a un marco de tiempo específico. Ambas opciones --since y --until toman un argumento de tiempo en el formato "YYYY-MM-DD hh:mm:ss". Se requieren comillas dobles si hay espacios en el argumento. También puede usar términos relativos como yesterday (ayer), today (hoy), tomorrow (mañana), o duraciones de tiempo como "-1 hour" (hace una hora).

Veamos todas las entradas del journal desde el comienzo de hoy:

journalctl --since today

Ahora, veamos las entradas de la última hora:

journalctl --since "-1 hour"

6. Ver salida detallada (opción -o verbose):
Para ver detalles adicionales sobre cada entrada de registro, incluidos los campos internos del journal, puede usar la opción -o verbose. Esto puede ser útil para la solución de problemas avanzada.

journalctl -n 1 -o verbose

Esto mostrará la última entrada de registro con todos sus detalles detallados. Observe campos como _COMM (nombre del comando), _EXE (ruta al ejecutable), _PID (ID del proceso), _UID (ID del usuario) y _SYSTEMD_UNIT (unidad systemd). Estos campos se pueden usar para un filtrado más preciso.

Por ejemplo, para encontrar entradas de un proceso sshd específico con un PID conocido (puede obtener un PID de una salida anterior de journalctl -u sshd.service):

journalctl _SYSTEMD_UNIT=sshd.service _PID=<PID_NUMBER>

Reemplace <PID_NUMBER> con un PID real que observó de las entradas de sshd. Por ejemplo, si vio sshd[1433], usaría _PID=1433.

journalctl _SYSTEMD_UNIT=sshd.service _PID=1433

Este comando demuestra cómo puede combinar múltiples filtros para acotar su búsqueda en el journal.

Configurar Almacenamiento Persistente del Journal del Sistema

En este paso, aprenderá a configurar el journal del sistema para que persista a través de los reinicios. Por defecto, Red Hat Enterprise Linux 9 almacena el journal del sistema en el directorio /run/log, que es un sistema de archivos temporal. Esto significa que todas las entradas del journal se borran después de un reinicio del sistema. Para conservar los datos históricos de registro, debe configurar el servicio systemd-journald para el almacenamiento persistente.

La configuración de systemd-journald se encuentra en el archivo /etc/systemd/journald.conf. El parámetro Storage dentro de este archivo determina si los journals se almacenan de forma volátil o persistente.

El parámetro Storage se puede establecer en uno de los siguientes valores:

• persistent: Almacena los journals en el directorio /var/log/journal, que persiste a través de los reinicios. Si este directorio no existe, systemd-journald lo creará.
• volatile: Almacena los journals en el directorio temporal /run/log/journal. Los datos en /run no persisten a través de los reinicios. Este es el comportamiento predeterminado si Storage no se establece explícitamente y /var/log/journal no existe.
• auto: Si el directorio /var/log/journal existe, systemd-journald utiliza el almacenamiento persistente; de lo contrario, utiliza el almacenamiento volátil. Este es el valor predeterminado si no establece el parámetro Storage.
• none: No se utiliza almacenamiento. Todos los registros se descartan, aunque aún se pueden reenviar.

Modifiquemos el archivo /etc/systemd/journald.conf para habilitar el almacenamiento persistente del journal. Usará sudo nano para editar este archivo.

sudo nano /etc/systemd/journald.conf

Dentro del editor nano, encuentre la sección [Journal]. Descomente la línea Storage (elimine el # al principio) y establezca su valor en persistent.

Su archivo debería verse similar a esto (mostrando solo las líneas relevantes):

[Journal]
Storage=persistent
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#Audit=no
#FlushIntervalSec=
#SyncIntervalSec=
#ReadKMsg=yes
#Audit=yes

Después de realizar el cambio, guarde el archivo presionando Ctrl+X, luego Y para confirmar el guardado y Enter para confirmar el nombre del archivo.

Para que los cambios surtan efecto, debe reiniciar el servicio systemd-journald. Dado que este entorno es un contenedor Docker, systemctl no está disponible. En su lugar, simularemos el efecto de reiniciar el servicio asegurándonos de que el directorio /var/log/journal se cree y tenga los permisos correctos, lo que systemd-journald haría al reiniciarse en un entorno no contenedorizado.

Primero, creemos el directorio si no existe y establezcamos los permisos apropiados.

sudo mkdir -p /var/log/journal
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

Ahora, para verificar que el almacenamiento persistente está configurado y activo, puede verificar si el directorio /var/log/journal contiene subdirectorios con nombres hexadecimales y archivos .journal. Estos archivos almacenan las entradas del journal estructuradas e indexadas.

ls -l /var/log/journal

Debería ver un subdirectorio con un nombre hexadecimal largo (por ejemplo, 4ec03abd2f7b40118b1b357f479b3112). Dentro de este directorio, encontrará archivos .journal.

ls -l /var/log/journal/ <YOUR_HEX_ID> /

Reemplace <YOUR_HEX_ID> con el ID hexadecimal real que encontró en la salida del comando ls anterior. Por ejemplo:

ls -l /var/log/journal/4ec03abd2f7b40118b1b357f479b3112/

Debería ver archivos como system.journal y posiblemente user-1000.journal.

Incluso con journals persistentes, el sistema no conserva todos los datos para siempre. El journal tiene un mecanismo de rotación de registros incorporado. Puede configurar los límites de tamaño y los períodos de retención en el archivo /etc/systemd/journald.conf utilizando parámetros como SystemMaxUse, SystemKeepFree, SystemMaxFileSize y MaxRetentionSec.

Finalmente, cuando los journals persistentes están habilitados, la salida de journalctl incluye entradas del inicio del sistema actual, así como de los inicios del sistema anteriores. Para limitar la salida a un inicio del sistema específico, use la opción journalctl -b.

Para listar todos los eventos de inicio del sistema reconocidos:

journalctl --list-boots

Verá una lista de ID de inicio y sus rangos de tiempo correspondientes. El inicio actual suele ser 0. Los inicios anteriores son números negativos (-1, -2, etc.).

Para ver las entradas solo del inicio del sistema actual:

journalctl -b

Para ver las entradas del inicio anterior (por ejemplo, el anterior al actual, generalmente -1):

journalctl -b -1

Esto concluye la configuración del almacenamiento persistente del journal.

Mantener la Hora del Sistema Precisa con timedatectl y chronyd

En este paso, aprenderá a mantener la hora del sistema precisa utilizando el comando timedatectl y comprenderá el papel del servicio chronyd. El mantenimiento preciso de la hora es crucial para el registro, la seguridad y muchos servicios de red.

1. Usar timedatectl para gestionar la hora del sistema y las zonas horarias:

El comando timedatectl proporciona una descripción general de la configuración actual del sistema relacionada con la hora, incluida la hora local, la hora universal (UTC), la hora RTC, la zona horaria y el estado de sincronización NTP.

Comprobemos la configuración actual de la hora de su sistema:

timedatectl

Debería ver una salida similar a esta (la hora y la fecha exactas reflejarán la hora actual de su sistema):

               Local time: Sun 2025-06-15 21:46:11 EDT
           Universal time: Mon 2025-06-16 01:46:11 UTC
                 RTC time: Mon 2025-06-16 01:46:10
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Puede listar todas las zonas horarias disponibles utilizando la opción list-timezones:

timedatectl list-timezones | less

Presione q para salir de less. Las zonas horarias se nombran en función de la base de datos de zonas horarias de la Autoridad de Números Asignados de Internet (IANA), normalmente por continente/océano y luego la ciudad más grande.

Para cambiar la zona horaria del sistema, utiliza la opción set-timezone. Por ejemplo, cambiemos la zona horaria a America/Phoenix. Necesita privilegios sudo para esto.

sudo timedatectl set-timezone America/Phoenix

Ahora, verifique el cambio:

timedatectl

Debería ver la zona horaria actualizada a America/Phoenix.

También puede establecer manualmente la hora actual del sistema utilizando la opción set-time. El formato es "YYYY-MM-DD hh:mm:ss", pero puede omitir la fecha o la hora. Establezcamos la hora en 09:00:00 (para la fecha actual).

sudo timedatectl set-time 09:00:00

Verifique el cambio de hora:

timedatectl

Finalmente, la opción set-ntp habilita o deshabilita la sincronización NTP para el ajuste automático de la hora. Toma true o false como argumento. Desactivemos la sincronización NTP por un momento (la volveremos a habilitar más tarde).

sudo timedatectl set-ntp false

Verifique el estado del servicio NTP:

timedatectl

Debería ver NTP service: inactive.

2. Comprender y configurar el servicio chronyd:

El servicio chronyd es un demonio que mantiene el Reloj en Tiempo Real (RTC) del sistema preciso sincronizándolo con los servidores del Protocolo de Tiempo de Red (NTP). Es el cliente NTP predeterminado en Red Hat Enterprise Linux.

El archivo de configuración para chronyd es /etc/chrony.conf. Por defecto, utiliza servidores NTP públicos. En un escenario del mundo real, podría configurarlo para usar servidores NTP internos.

Veamos el archivo chrony.conf predeterminado.

cat /etc/chrony.conf

Verá líneas que comienzan con server o pool, que definen las fuentes NTP. La opción iburst es recomendada ya que toma cuatro mediciones rápidamente para una sincronización inicial más precisa.

El stratum de una fuente de tiempo NTP indica su calidad. Un stratum 0 es un reloj de referencia, stratum 1 está conectado directamente a un reloj de referencia, y stratum 2 se sincroniza desde un servidor de stratum 1.

Dado que systemctl no está disponible en este entorno de contenedor, no podemos reiniciar directamente chronyd para aplicar los cambios de configuración. Sin embargo, podemos simular el cambio de configuración modificando el archivo.

Rehabilitaremos la sincronización NTP usando timedatectl.

sudo timedatectl set-ntp true

Verifique el estado del servicio NTP nuevamente:

timedatectl

Debería ver NTP service: active.

El comando chronyc actúa como cliente del servicio chronyd. Puede usarlo para monitorear el estado de sincronización. El comando chronyc sources muestra las fuentes de tiempo actuales y su estado de sincronización.

chronyc sources -v

La salida mostrará detalles sobre las fuentes NTP. El asterisco * en el campo S (Estado de la fuente) indica la fuente con la que chronyd está actualmente sincronizado.

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 100.100.61.88                 1   5   377    16  +1824us[+2180us] +/-   85ms
...output omitted...

Esta salida confirma que su sistema está sincronizando activamente su hora con un servidor NTP.

Resumen

En este laboratorio, obtuvimos una comprensión integral de la arquitectura de registro del sistema en Red Hat Enterprise Linux 9, centrándonos en la interacción entre systemd-journald y rsyslog. Aprendimos que systemd-journald recopila y almacena registros binarios estructurados e indexados en el journal, mientras que rsyslog procesa estos mensajes y los escribe en los archivos de registro tradicionales en /var/log. Exploramos archivos de registro clave como /var/log/messages, /var/log/secure y otros, y practicamos la revisión y el filtrado de archivos syslog utilizando comandos comunes. También aprendimos a enviar manualmente mensajes syslog personalizados.

Además, profundizamos en la exploración y el filtrado de las entradas del journal del sistema utilizando journalctl, comprendiendo sus capacidades para acceder a eventos detallados del sistema. Luego configuramos el almacenamiento persistente del journal del sistema para garantizar la retención de datos de registro a través de los reinicios. Finalmente, cubrimos el mantenimiento preciso de la hora del sistema utilizando timedatectl y chronyd, reconociendo su importancia para las marcas de tiempo precisas de los registros y la integridad general del sistema. Este laboratorio proporcionó habilidades esenciales para el análisis y la solución de problemas del sistema efectivos a través de una gestión de registros robusta.