Introducción
En este laboratorio, obtendrá experiencia práctica en 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 mediante comandos comunes, enviar manualmente mensajes syslog personalizados y explorar y filtrar entradas del diario del sistema con journalctl. El laboratorio también cubre la configuración del almacenamiento persistente del diario del sistema y el mantenimiento de una hora precisa mediante timedatectl y chronyd, dotándole de habilidades esenciales para el análisis y la resolución de problemas del sistema.
Comprender la arquitectura de registros del sistema y los 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, así como en los archivos de registro clave que gestionan. Comprender esta arquitectura es crucial para un análisis y una resolución de problemas eficaces.
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 arranque inicial, la salida/error estándar de los demonios y los eventos de syslog. El servicio systemd-journald almacena estos registros en un archivo binario estructurado e indexado llamado journal.
A continuación, veremos el servicio rsyslog. Mientras que systemd-journald recopila registros, rsyslog lee los mensajes syslog del diario 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 de rsyslog persisten tras 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. Dependiendo de su sistema, debería ver archivos como anaconda, audit, boot.log, chrony, cron, dnf.log, messages, secure, entre otros. Algunos de los más comunes incluyen:
/var/log/messages: Este archivo contiene la mayoría de los mensajes generales de syslog, 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 de syslog relacionados con eventos de seguridad y autenticación./var/log/maillog: Este archivo contiene mensajes de syslog sobre el servidor de correo./var/log/cron: Este archivo registra mensajes de syslog sobre la ejecución de trabajos programados./var/log/boot.log: Este archivo contiene mensajes de consola que no son de 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 ser leídos, por lo que deberá 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 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 de Syslog se clasifican por facility (qué subsistema produce el mensaje) y priority (la gravedad del mensaje). Comprender estas categorías es crucial para un análisis de registros eficiente.
Primero, revisemos el concepto de instalaciones (Facilities) y prioridades (Priorities) de Syslog.
Instalaciones de Syslog (Facilities): Indican el origen 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 de Syslog (Priorities): Definen la gravedad del mensaje, desde emerg (sistema inutilizable) hasta debug (mensaje de nivel de depuración). El orden de gravedad de mayor a menor es: emerg, alert, crit, err, warning, notice, info, debug.
Los archivos de registro pueden crecer mucho, lo que dificulta encontrar información específica. Por lo tanto, el filtrado es esencial. Puede usar comandos como grep, awk y sed para filtrar el contenido de los archivos 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 ser leídos.
sudo less /var/log/messages
Ahora, intentemos filtrar mensajes. Supongamos que le interesan los mensajes relacionados con la autenticación. Estos mensajes se encuentran normalmente 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 una salida que muestre las actividades del demonio SSH, 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 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:
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 (normalmente 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 listando nuevamente el contenido de /var/log. Es posible que vea archivos con extensiones de fecha o extensiones .gz (si han sido comprimidos).
ls -l /var/log/messages*
Salida de ejemplo:
-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 antiguos.
Finalmente, analicemos la anatomía de una entrada de 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 de 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 de 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 instalación 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 instalación y prioridad específicas. Recuerde del paso anterior que los mensajes de syslog se clasifican por instalación y prioridad. Por ejemplo, local7.notice significa que el mensaje se registrará con la instalación local7 y la prioridad notice. La instalación local7 se utiliza a menudo para aplicaciones personalizadas o mensajes de arranque, y normalmente es dirigida a /var/log/boot.log por la configuración de rsyslog.
Para enviar un mensaje al servicio rsyslog para que se registre en el archivo /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 instalación y la prioridad. Esta capacidad es muy útil para probar configuraciones de rsyslog y para inyectar eventos específicos en los registros de su sistema.
Explorar y filtrar entradas del diario del sistema con journalctl
En este paso, aprenderá a explorar y filtrar entradas del diario del sistema utilizando el comando journalctl. Como aprendió, el servicio systemd-journald almacena datos de registro en un archivo binario estructurado e indexado llamado journal. El comando journalctl es su herramienta principal para interactuar con este diario.
Comencemos viendo todos los mensajes en el diario. Cuando ejecuta journalctl sin ninguna opción, muestra todas las entradas de registro disponibles, comenzando desde la más antigua. Como ha iniciado sesión como labex con privilegios de sudo, tendrá acceso completo al diario.
journalctl
Verá una gran cantidad de salida. Presione q para salir del visor journalctl. Tenga en cuenta 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 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 diario (opción -f):
Similar al comando tail -f, la opción journalctl -f muestra las últimas 10 líneas del diario del sistema y continúa mostrando nuevas entradas a medida que se añaden. Esto es muy útil para el monitoreo 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 diario. La opción journalctl -p muestra entradas en 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 diario con prioridad err o superior:
journalctl -p err
Es posible que vea mensajes de error relacionados con varios componentes del sistema.
4. Filtrar por unidad de systemd (opción -u):
Puede mostrar mensajes para una unidad de 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):
Al buscar eventos específicos, puede limitar la salida a un marco de tiempo específico. Ambas opciones, --since y --until, aceptan un argumento de tiempo en 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, today, tomorrow o duraciones de tiempo como "-1 hour".
Veamos todas las entradas del diario 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 diario, puede usar la opción -o verbose. Esto puede ser útil para una resolució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 de usuario) y _SYSTEMD_UNIT (unidad de systemd). Estos campos se pueden utilizar 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ó en 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 reducir su búsqueda en el diario.
Configurar el almacenamiento persistente del diario del sistema
En este paso, aprenderá a configurar el diario del sistema para que persista tras los reinicios. Por defecto, Red Hat Enterprise Linux 9 almacena el diario del sistema en el directorio /run/log, que es un sistema de archivos temporal. Esto significa que todas las entradas del diario se borran después de reiniciar el sistema. Para conservar los datos históricos de registro, debe configurar el servicio systemd-journald para el almacenamiento persistente.
La configuración para systemd-journald se encuentra en el archivo /etc/systemd/journald.conf. El parámetro Storage dentro de este archivo determina si los diarios se almacenan de manera volátil o persistente.
El parámetro Storage se puede establecer en uno de los siguientes valores:
persistent: Almacena los diarios en el directorio/var/log/journal, que persiste tras los reinicios. Si este directorio no existe,systemd-journaldlo creará.volatile: Almacena los diarios en el directorio temporal/run/log/journal. Los datos en/runno persisten tras los reinicios. Este es el comportamiento predeterminado siStorageno se establece explícitamente y/var/log/journalno existe.auto: Si el directorio/var/log/journalexiste,systemd-journaldutiliza almacenamiento persistente; de lo contrario, utiliza almacenamiento volátil. Este es el valor predeterminado si no establece el parámetroStorage.none: No se utiliza almacenamiento. Todos los registros se descartan, aunque aún pueden ser reenviados.
Modifiquemos el archivo /etc/systemd/journald.conf para habilitar el almacenamiento persistente del diario. Usará sudo nano para editar este archivo.
sudo nano /etc/systemd/journald.conf
Dentro del editor nano, busque la sección [Journal]. Quite el comentario de la línea Storage (elimine el # al principio) y establezca su valor en persistent.
Su archivo debería verse similar a esto (solo se muestran 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 cual haría systemd-journald al reiniciar en un entorno no contenedorizado.
Primero, creemos el directorio si no existe y establezcamos los permisos adecuados.
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 comprobar si el directorio /var/log/journal contiene subdirectorios con nombres hexadecimales y archivos .journal. Estos archivos almacenan las entradas del diario 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 diarios persistentes, el sistema no conserva todos los datos para siempre. El diario tiene un mecanismo de rotación de registros incorporado. Puede configurar límites de tamaño y períodos de retención en el archivo /etc/systemd/journald.conf utilizando parámetros como SystemMaxUse, SystemKeepFree, SystemMaxFileSize y MaxRetentionSec.
Finalmente, cuando los diarios persistentes están habilitados, la salida de journalctl incluye entradas del arranque actual del sistema, así como de arranques anteriores. Para limitar la salida a un arranque específico del sistema, utilice la opción journalctl -b.
Para listar todos los eventos de arranque del sistema reconocidos:
journalctl --list-boots
Verá una lista de IDs de arranque y sus rangos de tiempo correspondientes. El arranque actual suele ser 0. Los arranques anteriores son números negativos (-1, -2, etc.).
Para ver las entradas solo del arranque actual del sistema:
journalctl -b
Para ver las entradas del arranque anterior (por ejemplo, el anterior al actual, generalmente -1):
journalctl -b -1
Esto concluye la configuración del almacenamiento persistente del diario.
Mantener una hora precisa del sistema con timedatectl y chronyd
En este paso, aprenderá a mantener una hora precisa del sistema utilizando el comando timedatectl y comprenderá el papel del servicio chronyd. Mantener la hora precisa es crucial para el registro, la seguridad y muchos servicios de red.
1. Uso de timedatectl para gestionar la hora y las zonas horarias del sistema:
El comando timedatectl proporciona una visión general de la configuración actual del sistema relacionada con la hora, incluyendo la hora local, la hora universal (UTC), la hora RTC, la zona horaria y el estado de sincronización NTP.
Comprobemos la configuración horaria actual 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 según la base de datos de zonas horarias de la Internet Assigned Numbers Authority (IANA), generalmente por continente/océano y luego por la ciudad más grande.
Para cambiar la zona horaria del sistema, utilice la opción set-timezone. Por ejemplo, cambiemos la zona horaria a America/Phoenix. Necesita privilegios de sudo para esto.
sudo timedatectl set-timezone America/Phoenix
Ahora, verifique el cambio:
timedatectl
Debería ver la zona horaria actualizada a America/Phoenix.
Antes de cambiar manualmente la hora del sistema, debe deshabilitar temporalmente la sincronización NTP. La opción set-ntp habilita o deshabilita la sincronización NTP para el ajuste automático de la hora. Acepta true o false como argumento. Deshabilitemos 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.
Ahora puede configurar 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
2. Comprender y configurar el servicio chronyd:
El servicio chronyd es un demonio que mantiene preciso el Reloj de Tiempo Real (RTC) del sistema sincronizándolo con 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. Se recomienda la opción iburst 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 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.
Volvamos a habilitar 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á sincronizado actualmente.
.-- 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 registros 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 diario, mientras que rsyslog procesa estos mensajes y los escribe en 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 entradas del diario del sistema utilizando journalctl, comprendiendo sus capacidades para acceder a eventos detallados del sistema. Luego configuramos el almacenamiento persistente del diario del sistema para garantizar la retención de datos de registro tras los reinicios. Finalmente, cubrimos el mantenimiento de una hora precisa del sistema utilizando timedatectl y chronyd, reconociendo su importancia para obtener marcas de tiempo precisas en los registros y la integridad general del sistema. Este laboratorio proporcionó habilidades esenciales para un análisis y una resolución de problemas eficaces del sistema a través de una gestión sólida de registros.
