Introdução
Neste laboratório, você ganhará experiência prática na análise e armazenamento de logs do sistema no Red Hat Enterprise Linux 9 usando journalctl e rsyslog. Você começará compreendendo a arquitetura central de registro do sistema, incluindo as funções do systemd-journald e do 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 diário do sistema com o journalctl. O laboratório também aborda a configuração do armazenamento persistente do diário do sistema e a manutenção da hora precisa do sistema usando timedatectl e chronyd, equipando você com habilidades essenciais para análise e solução de problemas do sistema.
Compreender a Arquitetura de Logs do Sistema e Arquivos Principais
Nesta etapa, você aprenderá sobre os componentes fundamentais do registro 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 eficazes do sistema.
Primeiro, vamos explorar o serviço systemd-journald. Este serviço está no centro 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 precoce, 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, veremos o serviço rsyslog. Enquanto o systemd-journald coleta logs, o rsyslog lê mensagens syslog do diário à medida que chegam. Ele então processa essas mensagens e as grava 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 do rsyslog persistem após 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ê deverá 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 relacionadas ao 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 ajudará você 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 comuns do Linux. 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 de 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 relógio).
Syslog Priorities: Definem a severidade da mensagem, variando de emerg (sistema inutilizável) a debug (mensagem de nível de depuração). A ordem de severidade da mais alta para a mais baixa é: emerg, alert, crit, err, warning, notice, info, debug.
Os 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 percorrer o arquivo. Pressione q para sair do less. Lembre-se de usar sudo, já que 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 geralmente são encontradas em /var/log/secure. Use grep para pesquisar linhas que contenham 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 refere ao daemon SSH.
sudo grep "sshd" /var/log/secure
Você deverá ver uma saída mostrando 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 carimbos de data/hora (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 nos logs do seu 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 o 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 arquivos vazios. Após um determinado período (geralmente quatro semanas), os arquivos de log rotacionados mais antigos são descartados. Uma tarefa agendada executa o logrotate diariamente para gerenciar esse processo.
Você pode observar 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 tiverem sido 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 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 carimbo de data/hora 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 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 prioridade 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 geralmente é /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ê deverá ver sua mensagem personalizada no final da saída, semelhante a isto:
...
Dec 16 10:30:00 host labex: This is a test message from labex.
Agora, vamos tentar enviar uma mensagem com uma facility e prioridade específicas. Lembre-se da etapa anterior que as mensagens syslog são categorizadas por facility e prioridade. Por exemplo, local7.notice significa que a mensagem será registrada com a facility local7 e prioridade notice. A facility local7 é frequentemente usada para aplicativos personalizados ou mensagens de inicialização, e geralmente é direcionada para /var/log/boot.log pela configuração do rsyslog.
Para enviar uma mensagem ao serviço rsyslog para ser gravada 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 gravada em /var/log/boot.log. Use sudo para acessar o arquivo de log.
sudo tail /var/log/boot.log
Você deverá 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 prioridade. Essa capacidade é muito útil para testar configurações do rsyslog e para injetar eventos específicos nos logs do seu sistema.
Explorar e Filtrar Entradas do Diário do Sistema com journalctl
Nesta etapa, você aprenderá como explorar e filtrar entradas do diário do sistema usando o comando journalctl. Como você aprendeu, o serviço systemd-journald armazena dados de registro em um arquivo binário estruturado e indexado chamado journal. O comando journalctl é sua ferramenta principal para interagir com este diário.
Vamos começar visualizando todas as mensagens no diário. Quando você executa journalctl sem nenhuma opção, ele exibe todas as entradas de log disponíveis, começando da mais antiga. Como você está logado como labex com privilégios sudo, você terá acesso total ao diário.
journalctl
Você verá uma grande quantidade de saída. Pressione q para sair do visualizador journalctl. Observe que o journalctl destaca mensagens de log importantes: mensagens com prioridade notice ou warning estão em negrito, enquanto mensagens com prioridade error ou superior estão em 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ê deverá ver as 5 entradas de log mais recentes.
2. Seguir novas entradas do diário (opção -f):
Semelhante ao comando tail -f, a opção journalctl -f exibe as últimas 10 linhas do diário do sistema e continua a exibir novas entradas de diário à 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 prioridade (opção -p):
Você pode filtrar a saída pelo nível de prioridade das entradas do diário. A opção journalctl -p mostra entradas em um nível de prioridade especificado (por nome ou por número) ou superior. Os níveis de prioridade, em ordem crescente, são debug, info, notice, warning, err, crit, alert e emerg.
Vamos listar as entradas do diário com prioridade 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 unidade systemd 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. Ambas 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 diário 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 detalhada (opção -o verbose):
Para ver detalhes adicionais sobre cada entrada de log, incluindo campos internos do diário, 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 detalhados. 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 uma 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 do journalctl -u sshd.service):
journalctl _SYSTEMD_UNIT=sshd.service _PID=<PID_NUMBER>
Substitua <PID_NUMBER> por um PID real que você observou nas entradas do 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 diário.
Configurar o Armazenamento Persistente do Diário do Sistema
Nesta etapa, você aprenderá como configurar o diário do sistema para persistir após reinicializações. Por padrão, o Red Hat Enterprise Linux 9 armazena o diário do sistema no diretório /run/log, que é um sistema de arquivos temporário. Isso significa que todas as entradas do diário são limpas após uma reinicialização do sistema. Para reter dados históricos de log, 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 diários são armazenados de forma volátil ou persistente.
O parâmetro Storage pode ser definido com um dos seguintes valores:
persistent: Armazena diários no diretório/var/log/journal, que persiste após reinicializações. Se este diretório não existir, osystemd-journaldo criará.volatile: Armazena diários no diretório temporário/run/log/journal. Os dados em/runnão persistem após reinicializações. Este é o comportamento padrão seStoragenão for definido explicitamente e/var/log/journalnão existir.auto: Se o diretório/var/log/journalexistir, osystemd-journaldusa armazenamento persistente; caso contrário, ele usa armazenamento volátil. Este é o padrão se você não definir o parâmetroStorage.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 diário. 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 ficar semelhante a isto (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, o 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 o systemd-journald faria ao reiniciar 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 diário estruturadas e indexadas.
ls -l /var/log/journal
Você deverá ver um subdiretório com um nome hexadecimal longo (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ê deverá ver arquivos como system.journal e possivelmente user-1000.journal.
Mesmo com diários persistentes, o sistema não mantém todos os dados para sempre. O diário 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 diários persistentes estão habilitados, a saída do journalctl inclui entradas da inicialização atual do sistema, bem como de inicializações anteriores. 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 entradas apenas da inicialização atual do sistema:
journalctl -b
Para visualizar entradas da inicialização anterior (por exemplo, a anterior à atual, geralmente -1):
journalctl -b -1
Isso conclui a configuração do armazenamento persistente do diário.
Manter a Hora Precisa do Sistema com timedatectl e chronyd
Nesta etapa, você aprenderá como manter a hora precisa do sistema usando o comando timedatectl e entenderá a função do serviço chronyd. A manutenção precisa da hora é crucial para logs, segurança e muitos serviços de rede.
1. Usando timedatectl para gerenciar a hora e os fusos horários do sistema:
O comando timedatectl fornece uma visão geral das configurações atuais do sistema relacionadas à hora, incluindo a hora local, hora universal (UTC), hora RTC, fuso horário e status de sincronização NTP.
Vamos verificar as configurações de hora atuais do seu sistema:
timedatectl
Você deverá 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 fusos horários da Internet Assigned Numbers Authority (IANA), geralmente por continente/oceano e depois pela 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ê deverá ver o fuso horário atualizado para America/Phoenix.
Antes de alterar manualmente a hora do sistema, você deve desativar temporariamente a sincronização NTP. A opção set-ntp ativa ou desativa a sincronização NTP para ajuste automático da hora. Ela aceita true ou false como argumento. Vamos desativar a sincronização NTP por um momento (nós a reativaremos mais tarde).
sudo timedatectl set-ntp false
Verifique o status do serviço NTP:
timedatectl
Você deverá ver NTP service: inactive.
Agora você 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
2. Entendendo e configurando o serviço chronyd:
O serviço chronyd é um daemon que mantém o Relógio de 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 realiza 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 a partir de um servidor stratum 1.
Como o 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ê deverá 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 (Estado da fonte) indica a fonte com a qual o chronyd está sincronizado atualmente.
.-- 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 sua hora com um servidor NTP.
Resumo
Neste laboratório, obtivemos uma compreensão abrangente da arquitetura de logs do sistema no Red Hat Enterprise Linux 9, focando na interação entre systemd-journald e rsyslog. Aprendemos que o systemd-journald coleta e armazena logs binários estruturados e indexados no diário, enquanto o rsyslog processa essas mensagens e as grava 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, nos aprofundamos na exploração e filtragem de entradas do diário do sistema usando journalctl, compreendendo suas capacidades para acessar eventos detalhados do sistema. Em seguida, configuramos o armazenamento persistente do diário do sistema para garantir a retenção de dados de log após reinicializações. Finalmente, abordamos a manutenção da hora precisa do sistema usando timedatectl e chronyd, reconhecendo sua importância para carimbos de data/hora precisos nos logs e para a integridade geral do sistema. Este laboratório forneceu habilidades essenciais para uma análise e solução de problemas eficazes do sistema por meio de um gerenciamento de logs robusto.
