Logs do Sistema: syslog, journald e logger

2026-05-30 Tempo de leitura: Cerca de 14 min Dificuldade: Intermediário

O Que Você Vai Conquistar

• Escrever regras de roteamento rsyslog no formato "facility.priority"
• Distinguir as listas de facilities e priorities
• Usar as opções-chave do journalctl (-u / -b / -f / -p / --since)
• Alternar o systemd-journald de armazenamento volátil para persistente
• Registrar mensagens arbitrárias no syslog com logger
• Explicar como o logrotate impede que logs cresacm sem limite

Este é o núcleo do objetivo 108.2 do LPIC-1 "Gerenciar os logs do sistema". Abrange os dois sistemas, rsyslog e systemd-journald, mais journalctl / logger / logrotate que operam sobre eles.

Qual Sistema de Logging Usar?

Na maioria das distribuições modernas, o systemd-journald recebe os logs primeiro e, quando necessário, os encaminha ao rsyslog para que também sejam escritos em logs de texto tradicionais como /var/log/messages. Essa configuração em duas etapas é comum.

O journald mantém metadados estruturados (nome da unidade, PID, boot ID etc.) e permite filtragem flexível com journalctl. O rsyslog é texto puro e é forte para encaminhamento a hosts remotos e retenção de longo prazo. O exame pergunta sobre ambos.

Como Escrever Regras de Roteamento rsyslog?

O roteamento rsyslog é escrito como um par de "seletor (facility.priority) mais ação (destino)". Você coloca em /etc/rsyslog.conf ou em arquivos sob /etc/rsyslog.d/.

O formato é assim:

mail.info                       /var/log/mail.log
authpriv.*                      /var/log/secure
*.emerg                         :omusrmsg:*
cron.*                          /var/log/cron

O lado esquerdo é o seletor e o lado direito é o destino. mail.info significa "a facility mail com priority info e acima". Especificar uma única priority como info corresponde a aquela severidade e tudo mais severo, o que é um ponto frequente no exame. O * em authpriv.* significa todas as priorities, e *.emerg significa emerg de todas as facilities.

Facilities e Priorities

Um seletor combina uma facility (a categoria que produziu a mensagem) e uma priority (severidade).

Principais valores de facility:

Priorities (severidade, da mais baixa):

*.info corresponde a info e acima (info / notice / warning / err / crit / alert / emerg). Para limitar a uma única priority, adicione =, como em mail.=info.

Encaminhamento de Logs para Host Remoto

O rsyslog pode encaminhar logs para outro host. No lado do remetente, escreva o seletor e o destino de encaminhamento no arquivo de configuração.

*.*     @192.168.1.10:514
*.*     @@192.168.1.10:514

Um único @ encaminha via UDP, e um duplo @@ encaminha via TCP. Isso é usado para agregar logs em um servidor de log central. O lado receptor deve habilitar a recepção na porta relevante.

Quais São as Opções-Chave do journalctl?

journalctl é o comando que busca e exibe os logs coletados pelo systemd-journald. Executado sem argumentos, mostra todos os logs do mais antigo ao mais recente.

Opções de filtragem representativas:

journalctl -u sshd.service
journalctl -b
journalctl -f
journalctl -p err
journalctl --since "2026-05-30 09:00:00" --until "2026-05-30 12:00:00"

Exemplo de execução:

journalctl -u sshd --since today -p warning

May 30 09:14:22 host sshd[1421]: Failed password for invalid user test from 203.0.113.5 port 55012 ssh2
May 30 10:02:51 host sshd[1588]: error: maximum authentication attempts exceeded for root

A priority -p aceita as mesmas palavras que o rsyslog (emerg até debug) ou números (0 até 7). -p err coleta err e acima juntos.

Como Tornar os Logs do journald Persistentes?

A localização de armazenamento do systemd-journald é controlada por Storage= em /etc/systemd/journald.conf. Por padrão (auto), armazena persistentemente em /var/log/journal/ se esse diretório existir, e armazena de forma volátil em /run/log/journal/ (um tmpfs em memória) caso contrário.

[Journal]
Storage=persistent

Passos para tornar os logs persistentes:

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
journalctl --disk-usage

Archived and active journals take up 112.4M in the file system.

Configurar Storage=persistent, ou criar /var/log/journal/ e reiniciar o journald, mantém os logs entre reboots. Você pode verificar o uso com journalctl --disk-usage.

Como Usar o Comando logger

logger é uma ferramenta que envia mensagens ao syslog a partir da linha de comando ou de um script. É amplamente usado para registrar o log de execução de shell scripts.

logger "backup script started"
logger -p local0.info -t backup "nightly backup finished"

Confirmando o resultado registrado:

logger -p local0.info -t backup "nightly backup finished"
journalctl -t backup -n 1

May 30 02:00:03 host backup[2840]: nightly backup finished

A tag definida com -t backup pode ser filtrada com journalctl -t backup. Incorporar logger em um script permite rastrear posteriormente, via journal, se o trabalho lançado pelo cron e similares teve sucesso.

Como o logrotate Impede o Crescimento dos Logs?

logrotate é o mecanismo que periodicamente rotaciona arquivos de log para que não cresacm sem limite. A configuração principal é /etc/logrotate.conf, e configurações por serviço ficam sob /etc/logrotate.d/.

Exemplo de /etc/logrotate.conf:

weekly
rotate 4
create
compress
include /etc/logrotate.d

weekly rotaciona semanalmente, rotate 4 mantém 4 gerações, create cria um log vazio após a rotação e compress comprime logs antigos com gzip. include /etc/logrotate.d carrega as configurações por serviço.

Uma configuração por serviço (exemplo /etc/logrotate.d/nginx):

/var/log/nginx/*.log {
    daily
    rotate 14
    missingok
    notifempty
    postrotate
        systemctl reload nginx > /dev/null 2>&1 || true
    endscript
}

daily rotaciona diariamente e rotate 14 mantém 14 gerações. missingok não gera erro se o arquivo estiver ausente, e notifempty pula a rotação se estiver vazio. postrotate até endscript notifica o processo para recarregar após a rotação.

Verificando o comportamento (apenas avaliando, sem rotacionar de fato):

logrotate -d /etc/logrotate.conf

rotating pattern: /var/log/nginx/*.log  after 1 days (14 rotations)
considering log /var/log/nginx/access.log
  log does not need rotating (log has been already rotated)

-d (debug) é um dry run: não rotaciona e apenas imprime as decisões. Após alterar a configuração, a prática padrão é confirmar com -d antes de aplicar em produção. Adicionar -f (force) rotaciona mesmo quando as condições não são atendidas.

Onde Estão os Arquivos de Log Principais?

A localização dos logs de texto que o rsyslog escreve difere por distribuição. O exame pergunta sobre a diferença entre sistemas baseados em Red Hat e Debian.

Para investigar falhas de autenticação, olhe /var/log/secure em sistemas baseados em Red Hat e /var/log/auth.log em sistemas baseados em Debian. Em um ambiente com apenas systemd-journald, esses arquivos de texto podem não existir; nesse caso, obtenha a informação equivalente com journalctl.

Erros Comuns

Padrões típicos onde iniciantes tropeacam no gerenciamento de logs.

• Erro 2: Interpretar mal mail.info como "apenas info" - Uma única priority em um seletor inclui "aquela severidade e tudo mais severo". Para limitar apenas a info, use = como em mail.=info.
• Erro 3: Confundir facilities e priorities - auth / cron / mail e similares são a origem (facility); err / warning / debug e similares são a severidade (priority). Confundi-los impede que as regras de roteamento funcionem como pretendido.
• Erro 4: Acreditar que o logrotate executa no momento em que você configura - O logrotate avalia condições quando invocado pelo cron / timer. Para confirmar imediatamente, use logrotate -d (apenas avaliação) ou -f (forçar).
• Erro 5: Olhar apenas os logs de texto e ignorar o journal - Em um ambiente systemd, muitos logs de serviço existem apenas no journal. Mesmo que não haja arquivo sob /var/log/, verifique com journalctl -u <service>.

Solução de Problemas

Sintoma: journalctl -b -1 não mostra logs do boot anterior

Causa: O journald está volátil, então os logs foram perdidos no reboot

Verificação:

cat /etc/systemd/journald.conf | grep Storage
ls /var/log/journal 2>/dev/null

Correção: Crie /var/log/journal/ e torne o armazenamento persistente com sudo systemctl restart systemd-journald. Ou configure Storage=persistent.

Sintoma: Você escreveu uma regra rsyslog mas nenhum log é produzido

Causa: Um facility/priority com erro de digitação no seletor, ou um reload de configuração ausente

Verificação:

sudo rsyslogd -N1
systemctl status rsyslog

Correção: Valide a sintaxe com rsyslogd -N1 e recarregue com sudo systemctl restart rsyslog. Confirme também a existência e permissões do diretório de destino.

Sintoma: Logs estão enchendo o disco

Causa: Muitas gerações retidas no logrotate, ou um limite grande do journald

Verificação:

journalctl --disk-usage
du -sh /var/log/*

Correção: Revise a contagem de gerações rotate e compress no logrotate. O journald pode reduzir dados passados com journalctl --vacuum-size=200M.

Lista de Verificação

• [ ] Consegue ler e escrever o formato de seletor rsyslog (facility.priority)
• [ ] Consegue distinguir as listas de facilities e priorities
• [ ] Consegue usar journalctl -u / -b / -f / -p / --since
• [ ] Consegue executar os passos para tornar o journald persistente
• [ ] Consegue registrar uma mensagem com tag usando logger
• [ ] Consegue confirmar decisões de rotação com logrotate -d

Resumo

O logging do sistema é a base para investigação de incidentes e auditoria de segurança. Domine facilities e priorities do rsyslog, persistência do journald e gerenciamento de capacidade com logrotate, e você irá pontuar com segurança no 108.2.

Próximas Leituras

• Agendamento de Tarefas: cron e systemd timers
• O Processo de Boot e systemd
• Conceitos Básicos de Linha de Comando