Analisar Logs no Red Hat Enterprise Linux - Guia Completo

Introdução

Neste laboratório, você obterá experiência prática na análise e armazenamento de logs do sistema no Red Hat Enterprise Linux 9 usando journalctl e rsyslog. Começará compreendendo a arquitetura central do registro de logs do sistema, incluindo os papéis de systemd-journald e rsyslog, e identificando os principais arquivos de log. Posteriormente, aprenderá a revisar e filtrar arquivos syslog usando comandos comuns, enviar manualmente mensagens syslog personalizadas e explorar e filtrar entradas do journal do sistema com journalctl. O laboratório também aborda a configuração do armazenamento persistente do journal do sistema e a manutenção precisa do tempo do sistema usando timedatectl e chronyd, equipando você com habilidades essenciais para análise e solução de problemas do sistema.

Entender a Arquitetura de Logs do Sistema e Arquivos Chave

Nesta etapa, você aprenderá sobre os componentes fundamentais do registro de logs do sistema no Red Hat Enterprise Linux 9, focando especificamente nos serviços systemd-journald e rsyslog, e nos principais arquivos de log que eles gerenciam. Compreender essa arquitetura é crucial para uma análise e solução de problemas do sistema eficazes.

Primeiramente, vamos explorar o serviço systemd-journald. Este serviço está no cerne do registro de eventos do sistema operacional. Ele coleta mensagens de eventos de várias fontes, incluindo o kernel do sistema, processos de inicialização inicial, saída/erro padrão de daemons e eventos syslog. O serviço systemd-journald armazena esses logs em um arquivo binário estruturado e indexado chamado journal.

Em seguida, analisaremos o serviço rsyslog. Enquanto systemd-journald coleta logs, rsyslog lê mensagens syslog do journal à medida que chegam. Ele então processa essas mensagens e as registra em arquivos de log tradicionais no diretório /var/log ou as encaminha para outros serviços com base em sua configuração. Esses arquivos rsyslog persistem em reinicializações.

Vamos examinar alguns dos arquivos de log importantes gerenciados pelo rsyslog no diretório /var/log. Você pode usar o comando ls para listar o conteúdo deste diretório.

ls /var/log

Você verá uma lista de vários arquivos de log. Com base no seu sistema, você deve ver arquivos como anaconda, audit, boot.log, chrony, cron, dnf.log, messages, secure e outros. Alguns dos mais comuns incluem:

/var/log/messages: Este arquivo contém a maioria das mensagens syslog gerais, excluindo aquelas relacionadas à autenticação, processamento de e-mail, execução de tarefas agendadas e depuração.
/var/log/secure: Este arquivo armazena mensagens syslog relacionadas a eventos de segurança e autenticação.
/var/log/maillog: Este arquivo contém mensagens syslog sobre o servidor de e-mail.
/var/log/cron: Este arquivo registra mensagens syslog sobre a execução de tarefas agendadas.
/var/log/boot.log: Este arquivo contém mensagens de console não-syslog sobre a inicialização do sistema.

Para visualizar o conteúdo desses arquivos, você pode usar comandos como cat, less ou tail. Observe que a maioria dos arquivos de log em /var/log requer privilégios de root para leitura, então você precisará usar sudo. Por exemplo, vamos visualizar as últimas linhas do arquivo /var/log/messages usando tail.

sudo tail /var/log/messages

Você também pode visualizar o conteúdo do arquivo /var/log/secure, que é importante para auditoria de segurança.

sudo tail /var/log/secure

Compreender o propósito desses arquivos o ajudará a localizar rapidamente informações relevantes ao solucionar problemas do sistema.

Revisar e Filtrar Arquivos Syslog com Comandos Comuns

Nesta etapa, você aprenderá como revisar e filtrar arquivos syslog de forma eficaz usando comandos Linux comuns. As mensagens syslog são categorizadas por facility (qual subsistema produz a mensagem) e priority (a severidade da mensagem). Compreender essas categorias é crucial para uma análise de log eficiente.

Primeiro, vamos revisar o conceito de Facilities e Priorities do Syslog.

Syslog Facilities: Indicam a origem da mensagem de log. Exemplos incluem kern (mensagens do kernel), user (mensagens em nível de usuário), mail (mensagens do sistema de e-mail), daemon (mensagens de daemons do sistema), auth (mensagens de autenticação e segurança) e cron (mensagens do daemon de clock).

Syslog Priorities: Definem a severidade da mensagem, variando de emerg (sistema inutilizável) a debug (mensagem em nível de depuração). A ordem de severidade, da mais alta para a mais baixa, é: emerg, alert, crit, err, warning, notice, info, debug.

Arquivos de log podem crescer muito, tornando difícil encontrar informações específicas. Portanto, a filtragem é essencial. Você pode usar comandos como grep, awk e sed para filtrar o conteúdo do arquivo de log.

Vamos começar visualizando todo o conteúdo de /var/log/messages usando less. Este comando permite que você role pelo arquivo. Pressione q para sair do less. Lembre-se de usar sudo, pois os arquivos de log exigem privilégios de root para leitura.

sudo less /var/log/messages

Agora, vamos tentar filtrar mensagens. Suponha que você esteja interessado em mensagens relacionadas à autenticação. Essas mensagens são normalmente encontradas em /var/log/secure. Use grep para pesquisar linhas contendo a palavra "authentication" em /var/log/secure. Lembre-se de usar sudo para acessar o arquivo de log.

sudo grep "authentication" /var/log/secure

Você pode não ver nenhuma saída se não houver mensagens de autenticação recentes. Vamos tentar um termo de pesquisa mais comum, como "sshd", que se relaciona ao daemon SSH.

sudo grep "sshd" /var/log/secure

Você deve ver a saída mostrando as atividades do daemon SSH, tentativas de autenticação ou outros eventos relacionados à segurança. A saída exata dependerá da atividade atual do sistema e pode 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...

As mensagens de log também contêm timestamps. Você pode filtrar mensagens por data e hora. Por exemplo, para ver mensagens de uma data específica, você pode combinar grep com a data. Vamos tentar encontrar mensagens da data de hoje em /var/log/messages. Use o formato de data atual que aparece em seus logs do sistema.

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

Rotação de Arquivos de Log:
Para evitar que os arquivos de log consumam muito espaço em disco, os sistemas usam logrotate. Este utilitário rotaciona os arquivos de log, renomeando os antigos (por exemplo, /var/log/messages torna-se /var/log/messages-20220320) e criando novos, vazios. Após um certo período (normalmente quatro semanas), os arquivos de log rotacionados mais antigos são descartados. Um trabalho agendado executa logrotate diariamente para gerenciar este processo.

Você pode observar os arquivos de log rotacionados listando o conteúdo de /var/log novamente. Você pode ver arquivos com extensões de data ou extensões .gz (se eles foram compactados).

ls -l /var/log/messages*

Exemplo de saída:

-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...

Isso mostra como o logrotate gerencia arquivos de log mais antigos.

Finalmente, vamos analisar a anatomia de uma entrada syslog. Uma mensagem de log típica em /var/log/secure se parece com isto:

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: O timestamp da entrada de log.
host: O host que enviou a mensagem de log.
sshd[1433]: O nome do programa ou processo (sshd) e seu PID (1433) que enviou a mensagem de log.
Failed password for …: O conteúdo real da mensagem.

Compreender este formato ajuda você a analisar e interpretar as entradas de log de forma mais eficaz.

Enviar Mensagens Syslog Personalizadas Manualmente

Nesta etapa, você aprenderá como enviar mensagens syslog personalizadas manualmente usando o comando logger. Esta é uma técnica útil para testar configurações do serviço rsyslog ou para injetar mensagens personalizadas nos logs do sistema para fins de depuração ou monitoramento.

O comando logger envia mensagens para o serviço rsyslog. Por padrão, ele envia a mensagem com a facility user e a priority notice (user.notice), a menos que especificado de outra forma com a opção -p.

Vamos começar enviando uma mensagem de teste simples para o local de log padrão, que normalmente é /var/log/messages.

logger "This is a test message from labex."

Após executar o comando, você pode verificar se a mensagem foi registrada verificando o arquivo /var/log/messages. Use tail para visualizar as últimas linhas do arquivo. Lembre-se de usar sudo para acessar o arquivo de log.

sudo tail /var/log/messages

Você deve ver sua mensagem personalizada no final da saída, semelhante a esta:

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

Agora, vamos tentar enviar uma mensagem com uma facility e priority específicas. Recorde da etapa anterior que as mensagens syslog são categorizadas por facility e priority. Por exemplo, local7.notice significa que a mensagem será registrada com a facility local7 e a priority notice. A facility local7 é frequentemente usada para aplicações personalizadas ou mensagens de inicialização, e normalmente é direcionada para /var/log/boot.log pela configuração do rsyslog.

Para enviar uma mensagem para o serviço rsyslog para ser registrada no arquivo de log /var/log/boot.log, execute o seguinte comando logger:

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

Agora, verifique se esta mensagem foi escrita em /var/log/boot.log. Use sudo para acessar o arquivo de log.

sudo tail /var/log/boot.log

Você deve ver sua mensagem personalizada na saída:

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

Isso demonstra como você pode controlar onde suas mensagens personalizadas são registradas, especificando a facility e a priority. Essa capacidade é muito útil para testar configurações do rsyslog e para injetar eventos específicos em seus logs do sistema.

Explorar e Filtrar Entradas do Journal do Sistema com journalctl

Nesta etapa, você aprenderá como explorar e filtrar entradas do journal do sistema usando o comando journalctl. Como você aprendeu, o serviço systemd-journald armazena dados de log em um arquivo binário estruturado e indexado chamado journal. O comando journalctl é sua principal ferramenta para interagir com este journal.

Vamos começar visualizando todas as mensagens no journal. Quando você executa journalctl sem nenhuma opção, ele exibe todas as entradas de log disponíveis, começando pelas mais antigas. Como você está logado como labex com privilégios sudo, você terá acesso total ao journal.

journalctl

Você verá uma grande quantidade de saída. Pressione q para sair do visualizador journalctl. Observe que journalctl destaca mensagens de log importantes: mensagens com priority notice ou warning estão em negrito, enquanto mensagens com priority error ou superior estão em texto vermelho.

Agora, vamos explorar algumas opções comuns do journalctl para filtrar e visualizar entradas específicas.

1. Visualizar as últimas N entradas de log (opção -n):
Por padrão, journalctl -n mostra as últimas 10 entradas de log. Você pode especificar um número diferente, por exemplo, as últimas 5 entradas:

journalctl -n 5

Você deve ver as 5 entradas de log mais recentes.

2. Acompanhar novas entradas do journal (opção -f):
Semelhante ao comando tail -f, a opção journalctl -f exibe as últimas 10 linhas do journal do sistema e continua a exibir novas entradas do journal à medida que são anexadas. Isso é muito útil para monitoramento em tempo real.

journalctl -f

Para sair desta saída contínua, pressione Ctrl+C.

3. Filtrar por priority (opção -p):
Você pode filtrar a saída pelo nível de priority das entradas do journal. A opção journalctl -p mostra entradas em um nível de priority especificado (por nome ou por número) ou superior. Os níveis de priority, em ordem crescente, são debug, info, notice, warning, err, crit, alert e emerg.

Vamos listar as entradas do journal com a priority err ou superior:

journalctl -p err

Você pode ver mensagens de erro relacionadas a vários componentes do sistema.

4. Filtrar por unidade systemd (opção -u):
Você pode mostrar mensagens para uma systemd unit especificada usando a opção journalctl -u e o nome da unidade. Por exemplo, para visualizar logs especificamente para o serviço sshd:

journalctl -u sshd.service

Isso exibirá todas as entradas de log relacionadas ao daemon SSH.

5. Filtrar por intervalo de tempo (opções --since e --until):
Ao procurar eventos específicos, você pode limitar a saída a um período de tempo específico. As opções --since e --until aceitam um argumento de tempo no formato "YYYY-MM-DD hh:mm:ss". Aspas duplas são necessárias se houver espaços no argumento. Você também pode usar termos relativos como yesterday, today, tomorrow ou durações de tempo como "-1 hour".

Vamos visualizar todas as entradas do journal desde o início de hoje:

journalctl --since today

Agora, vamos visualizar as entradas da última hora:

journalctl --since "-1 hour"

6. Visualizar saída verbose (opção -o verbose):
Para ver detalhes adicionais sobre cada entrada de log, incluindo campos internos do journal, você pode usar a opção -o verbose. Isso pode ser útil para solução de problemas avançada.

journalctl -n 1 -o verbose

Isso mostrará a última entrada de log com todos os seus detalhes verbose. Observe campos como _COMM (nome do comando), _EXE (caminho para o executável), _PID (ID do processo), _UID (ID do usuário) e _SYSTEMD_UNIT (unidade systemd). Esses campos podem ser usados para filtragem mais precisa.

Por exemplo, para encontrar entradas de um processo sshd específico com um PID conhecido (você pode obter um PID de uma saída anterior de journalctl -u sshd.service):

journalctl _SYSTEMD_UNIT=sshd.service _PID=<PID_NUMBER>

Substitua <PID_NUMBER> por um PID real que você observou nas entradas sshd. Por exemplo, se você viu sshd[1433], você usaria _PID=1433.

journalctl _SYSTEMD_UNIT=sshd.service _PID=1433

Este comando demonstra como você pode combinar vários filtros para restringir sua pesquisa no journal.

Configurar Armazenamento Persistente do Journal do Sistema

Nesta etapa, você aprenderá como configurar o journal do sistema para persistir entre as reinicializações. Por padrão, o Red Hat Enterprise Linux 9 armazena o journal do sistema no diretório /run/log, que é um sistema de arquivos temporário. Isso significa que todas as entradas do journal são limpas após uma reinicialização do sistema. Para reter dados de log históricos, você precisa configurar o serviço systemd-journald para armazenamento persistente.

A configuração para systemd-journald está localizada no arquivo /etc/systemd/journald.conf. O parâmetro Storage dentro deste arquivo determina se os journals são armazenados de forma volátil ou persistentemente.

O parâmetro Storage pode ser definido com um dos seguintes valores:

persistent: Armazena os journals no diretório /var/log/journal, que persiste entre as reinicializações. Se este diretório não existir, systemd-journald o criará.
volatile: Armazena os journals no diretório temporário /run/log/journal. Os dados em /run não persistem entre as reinicializações. Este é o comportamento padrão se Storage não for explicitamente definido e /var/log/journal não existir.
auto: Se o diretório /var/log/journal existir, systemd-journald usa armazenamento persistente; caso contrário, ele usa armazenamento volátil. Este é o padrão se você não definir o parâmetro Storage.
none: Nenhum armazenamento é usado. Todos os logs são descartados, embora ainda possam ser encaminhados.

Vamos modificar o arquivo /etc/systemd/journald.conf para habilitar o armazenamento persistente do journal. Você usará sudo nano para editar este arquivo.

sudo nano /etc/systemd/journald.conf

Dentro do editor nano, encontre a seção [Journal]. Descomente a linha Storage (remova o # no início) e defina seu valor como persistent.

Seu arquivo deve ser semelhante a este (mostrando apenas as linhas 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

Após fazer a alteração, salve o arquivo pressionando Ctrl+X, depois Y para confirmar o salvamento e Enter para confirmar o nome do arquivo.

Para que as alterações entrem em vigor, você precisa reiniciar o serviço systemd-journald. Como este ambiente é um contêiner Docker, systemctl não está disponível. Em vez disso, simularemos o efeito de reiniciar o serviço, garantindo que o diretório /var/log/journal seja criado e tenha as permissões corretas, o que systemd-journald faria após a reinicialização em um ambiente não conteinerizado.

Primeiro, vamos criar o diretório se ele não existir e definir as permissões apropriadas.

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

Agora, para verificar se o armazenamento persistente está configurado e ativo, você pode verificar se o diretório /var/log/journal contém subdiretórios com nomes hexadecimais e arquivos .journal. Esses arquivos armazenam as entradas do journal estruturadas e indexadas.

ls -l /var/log/journal

Você deve ver um subdiretório com um longo nome hexadecimal (por exemplo, 4ec03abd2f7b40118b1b357f479b3112). Dentro deste diretório, você encontrará arquivos .journal.

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

Substitua <YOUR_HEX_ID> pelo ID hexadecimal real que você encontrou na saída do comando ls anterior. Por exemplo:

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

Você deve ver arquivos como system.journal e possivelmente user-1000.journal.

Mesmo com journals persistentes, o sistema não mantém todos os dados para sempre. O journal possui um mecanismo de rotação de log integrado. Você pode configurar limites de tamanho e períodos de retenção no arquivo /etc/systemd/journald.conf usando parâmetros como SystemMaxUse, SystemKeepFree, SystemMaxFileSize e MaxRetentionSec.

Finalmente, quando os journals persistentes estão habilitados, a saída de journalctl inclui entradas da inicialização atual do sistema, bem como inicializações anteriores do sistema. Para limitar a saída a uma inicialização específica do sistema, use a opção journalctl -b.

Para listar todos os eventos de inicialização do sistema reconhecidos:

journalctl --list-boots

Você verá uma lista de IDs de inicialização e seus intervalos de tempo correspondentes. A inicialização atual geralmente é 0. As inicializações anteriores são números negativos (-1, -2, etc.).

Para visualizar as entradas apenas da inicialização atual do sistema:

journalctl -b

Para visualizar as entradas da inicialização anterior (por exemplo, a anterior à atual, geralmente -1):

journalctl -b -1

Isso conclui a configuração do armazenamento persistente do journal.

Manter a Hora do Sistema Precisa com timedatectl e chronyd

Nesta etapa, você aprenderá como manter o tempo do sistema preciso usando o comando timedatectl e entenderá o papel do serviço chronyd. A manutenção precisa do tempo é crucial para logging, segurança e muitos serviços de rede.

1. Usando timedatectl para gerenciar o tempo do sistema e fusos horários:

O comando timedatectl fornece uma visão geral das configurações atuais do sistema relacionadas ao tempo, incluindo a hora local, hora universal (UTC), hora RTC, fuso horário e status de sincronização NTP.

Vamos verificar as configurações atuais de tempo do seu sistema:

timedatectl

Você deve ver uma saída semelhante a esta (a hora e a data exatas refletirão a hora atual do seu 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

Você pode listar todos os fusos horários disponíveis usando a opção list-timezones:

timedatectl list-timezones | less

Pressione q para sair do less. Os fusos horários são nomeados com base no banco de dados de fuso horário da Internet Assigned Numbers Authority (IANA), normalmente por continente/oceano e, em seguida, a maior cidade.

Para alterar o fuso horário do sistema, você usa a opção set-timezone. Por exemplo, vamos alterar o fuso horário para America/Phoenix. Você precisa de privilégios sudo para isso.

sudo timedatectl set-timezone America/Phoenix

Agora, verifique a alteração:

timedatectl

Você deve ver o fuso horário atualizado para America/Phoenix.

Você também pode definir manualmente a hora atual do sistema usando a opção set-time. O formato é "YYYY-MM-DD hh:mm:ss", mas você pode omitir a data ou a hora. Vamos definir a hora para 09:00:00 (para a data atual).

sudo timedatectl set-time 09:00:00

Verifique a alteração da hora:

timedatectl

Finalmente, a opção set-ntp habilita ou desabilita a sincronização NTP para ajuste automático do tempo. Ele aceita true ou false como um argumento. Vamos desabilitar a sincronização NTP por um momento (vamos reativá-la mais tarde).

sudo timedatectl set-ntp false

Verifique o status do serviço NTP:

timedatectl

Você deve ver NTP service: inactive.

2. Entendendo e configurando o serviço chronyd:

O serviço chronyd é um daemon que mantém o Relógio em Tempo Real (RTC) do sistema preciso, sincronizando-o com servidores do Protocolo de Tempo de Rede (NTP). É o cliente NTP padrão no Red Hat Enterprise Linux.

O arquivo de configuração para chronyd é /etc/chrony.conf. Por padrão, ele usa servidores NTP públicos. Em um cenário do mundo real, você pode configurá-lo para usar servidores NTP internos.

Vamos visualizar o arquivo chrony.conf padrão.

cat /etc/chrony.conf

Você verá linhas começando com server ou pool, que definem as fontes NTP. A opção iburst é recomendada, pois leva quatro medições rapidamente para uma sincronização inicial mais precisa.

O stratum de uma fonte de tempo NTP indica sua qualidade. Um stratum 0 é um relógio de referência, stratum 1 está diretamente conectado a um relógio de referência e stratum 2 sincroniza de um servidor stratum 1.

Como systemctl não está disponível neste ambiente de contêiner, não podemos reiniciar diretamente o chronyd para aplicar as alterações de configuração. No entanto, podemos simular a alteração de configuração modificando o arquivo.

Vamos reativar a sincronização NTP usando timedatectl.

sudo timedatectl set-ntp true

Verifique o status do serviço NTP novamente:

timedatectl

Você deve ver NTP service: active.

O comando chronyc atua como um cliente para o serviço chronyd. Você pode usá-lo para monitorar o status da sincronização. O comando chronyc sources mostra as fontes de tempo atuais e seu status de sincronização.

chronyc sources -v

A saída mostrará detalhes sobre as fontes NTP. O asterisco * no campo S (Source state) indica a fonte com a qual chronyd está atualmente 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 saída confirma que seu sistema está sincronizando ativamente seu tempo com um servidor NTP.

Resumo

Neste laboratório, obtivemos uma compreensão abrangente da arquitetura de log do sistema no Red Hat Enterprise Linux 9, com foco na interação entre systemd-journald e rsyslog. Aprendemos que o systemd-journald coleta e armazena logs binários estruturados e indexados no journal, enquanto o rsyslog processa essas mensagens e as escreve em arquivos de log tradicionais em /var/log. Exploramos arquivos de log importantes como /var/log/messages, /var/log/secure e outros, e praticamos a revisão e filtragem de arquivos syslog usando comandos comuns. Também aprendemos como enviar manualmente mensagens syslog personalizadas.

Além disso, aprofundamos a exploração e filtragem de entradas do journal do sistema usando journalctl, compreendendo suas capacidades para acessar eventos detalhados do sistema. Em seguida, configuramos o armazenamento persistente do journal do sistema para garantir a retenção de dados de log entre as reinicializações. Por fim, abordamos a manutenção precisa do tempo do sistema usando timedatectl e chronyd, reconhecendo sua importância para timestamps de log precisos e integridade geral do sistema. Este laboratório forneceu habilidades essenciais para análise e solução de problemas eficazes do sistema por meio de um gerenciamento de log robusto.