Logs do Sistema: syslog, journald e logger

2026-05-30 Tempo de leitura: Cerca de 14 min Dificuldade: Intermediario

O Que Voce Vai Conquistar

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

Este e o nucleo 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 distribuicoes modernas, o systemd-journald recebe os logs primeiro e, quando necessario, os encaminha ao rsyslog para que tambem sejam escritos em logs de texto tradicionais como /var/log/messages. Essa configuracao em duas etapas e comum.

O journald mantem metadados estruturados (nome da unidade, PID, boot ID etc.) e permite filtragem flexivel com journalctl. O rsyslog e texto puro e e forte para encaminhamento a hosts remotos e retencao de longo prazo. O exame pergunta sobre ambos.

Como Escrever Regras de Roteamento rsyslog?

O roteamento rsyslog e escrito como um par de "seletor (facility.priority) mais acao (destino)". Voce coloca em /etc/rsyslog.conf ou em arquivos sob /etc/rsyslog.d/.

O formato e assim:

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

O lado esquerdo e o seletor e o lado direito e o destino. mail.info significa "a facility mail com priority info e acima". Especificar uma unica priority como info corresponde a aquela severidade e tudo mais severo, o que e 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 unica 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 configuracao.

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

Um unico @ encaminha via UDP, e um duplo @@ encaminha via TCP. Isso e usado para agregar logs em um servidor de log central. O lado receptor deve habilitar a recepcao na porta relevante.

Quais Sao as Opcoes-Chave do journalctl?

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

Opcoes 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 execucao:

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 ate debug) ou numeros (0 ate 7). -p err coleta err e acima juntos.

Como Tornar os Logs do journald Persistentes?

A localizacao de armazenamento do systemd-journald e controlada por Storage= em /etc/systemd/journald.conf. Por padrao (auto), armazena persistentemente em /var/log/journal/ se esse diretorio existir, e armazena de forma volatil em /run/log/journal/ (um tmpfs em memoria) caso contrario.

[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, mantem os logs entre reboots. Voce pode verificar o uso com journalctl --disk-usage.

Como Usar o Comando logger

logger e uma ferramenta que envia mensagens ao syslog a partir da linha de comando ou de um script. E amplamente usado para registrar o log de execucao 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 lancado pelo cron e similares teve sucesso.

Como o logrotate Impede o Crescimento dos Logs?

logrotate e o mecanismo que periodicamente rotaciona arquivos de log para que nao cresacm sem limite. A configuracao principal e /etc/logrotate.conf, e configuracoes por servico ficam sob /etc/logrotate.d/.

Exemplo de /etc/logrotate.conf:

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

weekly rotaciona semanalmente, rotate 4 mantem 4 geracoes, create cria um log vazio apos a rotacao e compress comprime logs antigos com gzip. include /etc/logrotate.d carrega as configuracoes por servico.

Uma configuracao por servico (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 mantem 14 geracoes. missingok nao gera erro se o arquivo estiver ausente, e notifempty pula a rotacao se estiver vazio. postrotate ate endscript notifica o processo para recarregar apos a rotacao.

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) e um dry run: nao rotaciona e apenas imprime as decisoes. Apos alterar a configuracao, a pratica padrao e confirmar com -d antes de aplicar em producao. Adicionar -f (force) rotaciona mesmo quando as condicoes nao sao atendidas.

Onde Estao os Arquivos de Log Principais?

A localizacao dos logs de texto que o rsyslog escreve difere por distribuicao. O exame pergunta sobre a diferenca entre sistemas baseados em Red Hat e Debian.

Para investigar falhas de autenticacao, 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 nao existir; nesse caso, obtenha a informacao equivalente com journalctl.

Erros Comuns

Padroes tipicos onde iniciantes tropeacam no gerenciamento de logs.

• Erro 2: Interpretar mal mail.info como "apenas info" - Uma unica 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 sao a origem (facility); err / warning / debug e similares sao 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 voce configura - O logrotate avalia condicoes quando invocado pelo cron / timer. Para confirmar imediatamente, use logrotate -d (apenas avaliacao) ou -f (forcar).
• Erro 5: Olhar apenas os logs de texto e ignorar o journal - Em um ambiente systemd, muitos logs de servico existem apenas no journal. Mesmo que nao haja arquivo sob /var/log/, verifique com journalctl -u <service>.

Solucao de Problemas

Sintoma: journalctl -b -1 nao mostra logs do boot anterior

Causa: O journald esta volatil, entao os logs foram perdidos no reboot

Verificacao:

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

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

Sintoma: Voce escreveu uma regra rsyslog mas nenhum log e produzido

Causa: Um facility/priority com erro de digitacao no seletor, ou um reload de configuracao ausente

Verificacao:

sudo rsyslogd -N1
systemctl status rsyslog

Correcao: Valide a sintaxe com rsyslogd -N1 e recarregue com sudo systemctl restart rsyslog. Confirme tambem a existencia e permissoes do diretorio de destino.

Sintoma: Logs estao enchendo o disco

Causa: Muitas geracoes retidas no logrotate, ou um limite grande do journald

Verificacao:

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

Correcao: Revise a contagem de geracoes rotate e compress no logrotate. O journald pode reduzir dados passados com journalctl --vacuum-size=200M.

Lista de Verificacao

• [ ] 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 decisoes de rotacao com logrotate -d

Resumo

O logging do sistema e a base para investigacao de incidentes e auditoria de seguranca. Domine facilities e priorities do rsyslog, persistencia do journald e gerenciamento de capacidade com logrotate, e voce ira pontuar com seguranca no 108.2.

Proximas Leituras

• Agendamento de Tarefas: cron e systemd timers
• O Processo de Boot e systemd
• Conceitos Basicos de Linha de Comando