Aula 17: Logs do sistema — journalctl, syslog e rsyslog – BLOG

Bem-vindo à Aula 17 do curso Linux — Do Zero ao Avançado. Hoje mergulhamos em um dos pilares mais subestimados — e ao mesmo tempo mais críticos — da administração de sistemas: os logs do sistema. Se você já precisou diagnosticar uma falha em produção às 3h da manhã, sabe que o domínio sobre journalctl, syslog e rsyslog separa um profissional reativo de um engenheiro de infraestrutura preparado. Esta aula foi projetada para profissionais de TI, analistas de segurança da informação e entusiastas que desejam extrair inteligência real dos arquivos de log — não apenas lê-los, mas compreendê-los, centralizá-los e utilizá-los como ferramenta proativa de gerenciamento.

Em nossos projetos na JRT Technology Solutions, lidamos diariamente com ambientes onde uma análise incorreta de logs pode significar horas de downtime desnecessário ou, pior, uma brecha de segurança não detectada. Por isso, estruturamos este conteúdo com a mesma abordagem que usamos em nossos treinamentos corporativos: fundamento teórico sólido, procedimentos completos e verificáveis, e configurações que funcionam em Ubuntu/Debian e CentOS/RHEL/Rocky Linux. Cada comando mostrado aqui já foi executado, validado e documentado em ambientes reais de produção.

Nesta aula, você vai compreender a arquitetura de logging do Linux moderno — desde o tradicional daemon syslog e sua evolução com o rsyslog, até o sistema binário de journals do systemd. Vamos configurar regras de filtragem, rotacionar logs automaticamente, centralizar eventos de múltiplos servidores e, principalmente, utilizar o journalctl como ferramenta forense para consultas precisas e poderosas. Este é o nível intermediário do curso: você já sabe administrar usuários, processos e serviços; agora vai aprender a auditar tudo o que acontece no sistema.

Ao final desta aula, você será capaz de interpretar qualquer entrada de log, configurar facilidades e severidades do syslog, criar regras condicionais de roteamento com rsyslog, consultar journals com filtros por tempo, serviço e prioridade, além de diagnosticar problemas comuns que impedem a geração ou o registro correto de eventos. Prepare seu terminal: vamos transformar logs de um emaranhado de texto em um painel de controle completo sobre seus sistemas Linux.

O que você vai aprender nesta aula

Compreender a arquitetura de logs do sistema no Linux e a diferença entre syslog tradicional, rsyslog e journald
Instalar, configurar e gerenciar o rsyslog em distribuições Debian e Red Hat
Dominar o journalctl para consultas avançadas com filtros por tempo, unidade systemd, prioridade e campos personalizados
Criar regras de roteamento de logs baseadas em facility e severity
Configurar o armazenamento persistente do journal e integrar journald com rsyslog
Diagnosticar e resolver os erros mais comuns em sistemas de logging
Aplicar boas práticas de retenção, rotação e segurança dos arquivos de log

Pré-requisitos e Ambiente

Para acompanhar esta aula com aproveitamento máximo, você precisa ter acesso a um sistema Linux com systemd — recomendamos duas máquinas virtuais: uma rodando Ubuntu Server 24.04 LTS e outra com Rocky Linux 9 (ou CentOS Stream 9). O systemd é pré-requisito porque o journalctl é parte integrante do ecossistema systemd. Você também deve ter concluído as aulas anteriores do curso, em especial a Aula 12 (Gerenciamento de serviços com systemd) e a Aula 15 (Permissões e propriedade de arquivos), pois manipularemos arquivos em /var/log e /etc/rsyslog.d/ com privilégios de root.

Verifique se os pacotes essenciais estão presentes. No Ubuntu/Debian, o rsyslog costuma vir instalado por padrão, mas você pode confirmar com dpkg -l | grep rsyslog. No Rocky/CentOS, utilize rpm -qa | grep rsyslog. Ambos os sistemas já incluem o journald como parte do systemd. Se por acaso o rsyslog não estiver presente, instalaremos na seção dedicada. Garanta também que seu usuário tenha acesso a sudo. Vamos executar todos os comandos como root ou com sudo, conforme indicado, e cada procedimento será completamente reproduzível.

Conceitos Fundamentais de Logs do Sistema

Antes de executar comandos, precisamos estabelecer a base conceitual que sustenta os logs do sistema. No Linux, logging é o mecanismo pelo qual o kernel, os serviços e as aplicações registram eventos — erros, avisos, informações de debug, tentativas de autenticação, tráfego de rede e muito mais. Esses registros são armazenados em arquivos de texto no diretório /var/log (no modelo tradicional) ou em bancos de dados binários gerenciados pelo journald (no modelo systemd). Compreender essa dualidade é essencial: muitos sistemas modernos operam com ambos simultaneamente, e você precisa saber quando consultar cada um.

O protocolo syslog (RFC 5424) define um formato padronizado para mensagens de log, composto por três elementos fundamentais: facility (a origem ou categoria do evento), severity (a gravidade ou prioridade) e a mensagem propriamente dita. A facility identifica o subsistema gerador — por exemplo, auth para eventos de autenticação, kern para mensagens do kernel, mail para servidores de email, e local0 a local7 para aplicações customizadas. Já a severity segue uma escala numérica de 0 (emergência total do sistema) a 7 (debug detalhado). Esta classificação dupla permite filtrar e rotear mensagens com precisão cirúrgica.

O rsyslog (rocket-fast syslog) é a implementação moderna do protocolo syslog, presente na maioria das distribuições Linux atuais. Ele estende o syslog tradicional com capacidades como: suporte a múltiplos protocolos de transporte (UDP, TCP, TLS), enfileiramento de mensagens em memória para alta performance, parsing baseado em expressões regulares, e módulos dinâmicos para saída em bancos de dados SQL, Elasticsearch e outros destinos. Já o journald, parte do systemd, armazena logs em formato binário com indexação por dezenas de campos — ID do processo, UID, GID, unidade systemd, linha de execução e muito mais. O journalctl é a ferramenta de consulta desse banco de dados, oferecendo capacidades forenses que vão muito além de um simples grep em arquivos de texto.

Na prática, o fluxo de logging em um sistema Linux moderno funciona assim: aplicações e serviços podem enviar mensagens diretamente ao syslog socket (/dev/log) ou ao journald via API nativa do systemd. O journald armazena tudo em /var/log/journal/ (se configurado para persistência) e, opcionalmente, encaminha uma cópia para o rsyslog via socket /run/systemd/journal/syslog. O rsyslog, por sua vez, aplica suas regras de roteamento e grava as mensagens em arquivos de texto tradicionais como /var/log/syslog, /var/log/auth.log e /var/log/kern.log. Essa arquitetura em camadas garante que você tenha tanto o poder analítico do journalctl quanto a compatibilidade e simplicidade dos arquivos de texto plano.

O Ecossistema de Logs no Linux: syslog, rsyslog e journald

Agora que você compreende os fundamentos, vamos detalhar cada componente do ecossistema de logs do sistema. O protocolo syslog, embora antigo, permanece onipresente por sua simplicidade e interoperabilidade. Ele define que cada mensagem possui um PRI (priority) composto pela combinação de facility e severity, calculado como (facility * 8) + severity. Por exemplo, uma mensagem de kernel com severidade “error” (facility=0, severity=3) tem PRI=3. Este valor numérico viaja no cabeçalho de cada mensagem syslog e permite que servidores de log tomem decisões de roteamento sem precisar interpretar o texto.

As facilities padronizadas são 24 (0 a 23), mas as mais comuns no dia a dia são apenas algumas. A tabela abaixo lista as facilities essenciais que você encontrará em qualquer servidor Linux. Memorizar pelo menos estas 10 é um investimento que trará retorno imediato na sua capacidade de configurar regras de logging:

Tabela 1 — Facilities do syslog (RFC 3164/5424)
Código	Facility	Descrição	Exemplo de uso
0	kern	Mensagens do kernel	Detecção de hardware, drivers
1	user	Mensagens de processos de usuário	Aplicações genéricas
2	mail	Sistema de email	Postfix, Sendmail, Dovecot
3	daemon	Daemons do sistema	sshd, cron, rsyslog
4	auth	Autenticação e autorização	login, sudo, su, pam
5	syslog	Mensagens internas do syslog	Eventos do próprio rsyslog
6	lpr	Impressão	CUPS, spoolers
7	news	Servidores de notícias USENET	INN, NNTP
10	authpriv	Autenticação sensível	Logins, falhas de senha
13	audit	Auditoria do sistema	auditd, SELinux

As severities (ou prioridades) seguem uma hierarquia numérica onde valores menores indicam maior gravidade. Quando você configura uma regra com uma determinada severity, o rsyslog captura aquela prioridade e todas as superiores. Por exemplo, especificar warn (4) fará com que sejam registradas também as mensagens de err (3), crit (2), alert (1) e emerg (0). Esta lógica é frequentemente fonte de confusão para iniciantes, então grave bem este comportamento antes de prosseguir:

Tabela 2 — Severities do syslog e seu significado
Código	Severity	Palavra-chave	Significado
0	Emergency	emerg, panic	Sistema inutilizável
1	Alert	alert	Ação imediata necessária
2	Critical	crit	Condições críticas
3	Error	err, error	Condições de erro
4	Warning	warn, warning	Condições de aviso
5	Notice	notice	Eventos normais, mas significativos
6	Informational	info	Mensagens informativas
7	Debug	debug	Mensagens de depuração

O journald, por sua vez, não utiliza o conceito de facilities do syslog, mas mapeia as severities para campos binários indexados. Quando você consulta com journalctl -p err, está filtrando por prioridade máxima “error” ou superior (0-3), similar ao comportamento do syslog. A grande vantagem do journald é sua capacidade de armazenar metadados ricos — cada entrada de log inclui automaticamente dezenas de campos como _PID, _UID, _GID, _COMM, _EXE, _SYSTEMD_UNIT, _TRANSPORT e muitos outros. Esses campos são indexados e podem ser consultados com precisão milimétrica usando os filtros do journalctl.

Na arquitetura moderna, os logs do sistema fluem por três camadas que coexistem: o journald atua como coletor central e armazenamento estruturado, o socket /run/systemd/journal/syslog permite que o rsyslog leia os journals como se fossem mensagens syslog tradicionais, e o rsyslog persiste os dados em arquivos de texto, bancos SQL ou servidores remotos. Essa arquitetura garante que mesmo se o rsyslog falhar, os logs continuam sendo coletados pelo journald (que é parte do PID 1) e podem ser recuperados posteriormente. Em nossos treinamentos na JRT Technology Solutions, sempre enfatizamos: nunca desabilite o journald em favor do rsyslog; use ambos em conjunto.

Instalando e Configurando o rsyslog no Ubuntu/Debian e Rocky Linux/CentOS

Embora o rsyslog venha pré-instalado na maioria das distribuições, é importante verificar sua presença e garantir que o serviço esteja ativo e habilitado para iniciar com o sistema. Em ambientes mínimos (containers Docker, instalações cloud mínimas), o rsyslog pode estar ausente. Vamos executar o procedimento completo de verificação e instalação em ambas as famílias de distribuições. Todos os comandos devem ser executados como root ou com sudo.

Começamos pela família Debian. No Ubuntu Server 24.04 LTS, execute os seguintes passos em sequência para verificar, instalar se necessário e iniciar o serviço:

# Passo 1: Verificar se o pacote rsyslog está instalado
sudo dpkg -l | grep rsyslog

# Passo 2: Caso não apareça nada na saída, instale o pacote
sudo apt update
sudo apt install -y rsyslog

# Passo 3: Verificar o status do serviço rsyslog
sudo systemctl status rsyslog

# Passo 4: Habilitar o rsyslog para iniciar automaticamente no boot
sudo systemctl enable rsyslog

# Passo 5: Iniciar o serviço (caso não esteja rodando)
sudo systemctl start rsyslog

# Saída esperada do comando 'systemctl status rsyslog' no Ubuntu:
● rsyslog.service - System Logging Service
     Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2026-06-21 10:15:22 -03; 2min 34s ago
TriggeredBy: ● syslog.socket
       Docs: man:rsyslogd(8)
             https://www.rsyslog.com/doc/
   Main PID: 1245 (rsyslogd)
      Tasks: 4 (limit: 9422)
     Memory: 3.2M
        CPU: 134ms
     CGroup: /system.slice/rsyslog.service
             └─1245 /usr/sbin/rsyslogd -n -iNONE

Agora, na família Red Hat. Em Rocky Linux 9 ou CentOS Stream 9, o procedimento é similar, mas utilizamos o gerenciador de pacotes dnf:

# Passo 1: Verificar se o pacote rsyslog está instalado
sudo rpm -qa | grep rsyslog

# Passo 2: Caso não apareça nada, instale com dnf
sudo dnf install -y rsyslog

# Passo 3: Verificar o status do serviço
sudo systemctl status rsyslog

# Passo 4: Habilitar no boot e iniciar
sudo systemctl enable rsyslog
sudo systemctl start rsyslog

# Saída esperada do comando 'systemctl status rsyslog' no Rocky Linux:
● rsyslog.service - System Logging Service
     Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2026-06-21 14:20:05 UTC; 1min 12s ago
       Docs: man:rsyslogd(8)
             https://www.rsyslog.com/doc/
   Main PID: 982 (rsyslogd)
      Tasks: 4 (limit: 22996)
     Memory: 3.1M
        CPU: 89ms
     CGroup: /system.slice/rsyslog.service
             └─982 /usr/sbin/rsyslogd -n

Note que em ambas as distribuições, o estado deve ser active (running) e enabled. Se o serviço estiver inativo, verifique os logs com sudo journalctl -xeu rsyslog para diagnosticar o problema antes de prosseguir. A diferença sutil na linha de comando do processo (com -iNONE no Ubuntu) está relacionada a configurações de compilação e não afeta o funcionamento. O importante é que o daemon rsyslogd esteja rodando como processo filho do systemd.

Trabalhando com o journalctl — Consultas Essenciais

O journalctl é a principal ferramenta de consulta aos logs do sistema armazenados pelo journald. Diferente do tradicional cat /var/log/syslog | grep algo, o journalctl oferece filtros integrados que exploram a indexação binária do journal — as consultas são ordens de magnitude mais rápidas e precisas. Vamos explorar os comandos mais importantes, começando do básico e avançando para filtros complexos que você usará diariamente como administrador de sistemas.

O comando mais simples é journalctl sem argumentos, que exibe todos os logs do sistema desde o boot atual, paginados com less. Use as setas para navegar e q para sair. Para ver logs de boots anteriores (extremamente útil para diagnosticar falhas que ocorreram antes de um reboot):

# Listar todos os boots registrados no journal
sudo journalctl --list-boots

# Exibir logs de um boot específico (ex: boot -1 = boot anterior)
sudo journalctl -b -1

# Exibir logs do boot atual com explicações estendidas
sudo journalctl -xe

# Saída esperada de 'journalctl --list-boots':
-3 f9a8c2b3d1e64d7a9b5c3d4e5f6a7b8c Fri 2026-06-19 08:15:11 -03—Fri 2026-06-19 18:30:45 -03
-2 3d7e8a9b1c2f4e5d6a7b8c9d0e1f2a3b Sat 2026-06-20 09:00:02 -03—Sat 2026-06-20 22:45:18 -03
-1 a1b2c3d4e5f67890abcdef1234567890 Sat 2026-06-20 23:10:55 -03—Sun 2026-06-21 02:33:41 -03
 0 d4e5f6a7b8c901234567890abcdef1234 Sun 2026-06-21 10:15:22 -03—Sun 2026-06-21 14:45:09 -03

A flag -x adiciona explicações textuais (help texts) para cada mensagem, mostrando informações do catálogo de mensagens do systemd. A flag -e pula diretamente para o final do journal (as mensagens mais recentes). Combinadas em -xe, você obtém as últimas entradas com contexto explicativo — o comando de diagnóstico rápido por excelência.

Agora, avançamos para filtros por tempo, essenciais para isolar eventos em uma janela específica durante análises forenses ou troubleshooting:

# Exibir logs gerados nas últimas 2 horas
sudo journalctl --since "2 hours ago"

# Exibir logs entre dois timestamps específicos
sudo journalctl --since "2026-06-21 08:00:00" --until "2026-06-21 12:00:00"

# Exibir logs de hoje
sudo journalctl --since today

# Exibir logs dos últimos 30 minutos
sudo journalctl --since "30 min ago"

Os formatos de data aceitos pelo –since e –until são extremamente flexíveis: você pode usar “2026-06-21”, “yesterday”, “2 weeks ago”, “2026-06-21 14:30:00” ou qualquer combinação que o GNU date entenda. Isso elimina a necessidade de cálculos manuais de timestamps e torna as consultas muito mais intuitivas.

Um dos filtros mais poderosos e frequentemente subutilizados é o -u para filtrar por unidade systemd. Se você sabe qual serviço está investigando, este filtro restringe os resultados exatamente àquele contexto:

# Exibir logs do serviço ssh
sudo journalctl -u ssh.service

# Exibir logs do ssh com explicações, últimos 100 registros
sudo journalctl -xe -u ssh.service -n 100

# Exibir logs do ssh desde a última hora
sudo journalctl -u ssh.service --since "1 hour ago"

# Acompanhar logs em tempo real (similar a tail -f)
sudo journalctl -u ssh.service -f

O filtro por prioridade -p segue a mesma lógica das severities do syslog: ao especificar um nível, você recebe aquela prioridade e todas as superiores. Por exemplo, -p err mostra emerg, alert, crit e err, mas não warn, notice, info ou debug:

# Exibir apenas logs com prioridade error ou superior
sudo journalctl -p err

# Exibir logs de warning ou superior do serviço nginx (se instalado)
sudo journalctl -u nginx.service -p warning

# Combinar filtros múltiplos: erros do ssh nas últimas 24h
sudo journalctl -u ssh.service -p err --since yesterday

Para finalizar esta seção, apresentamos o uso de campos personalizados com a flag _FIELD=VALUE. O journald indexa automaticamente dezenas de campos para cada entrada. Você pode listar todos os campos disponíveis com journalctl –output=verbose e então filtrar por qualquer um deles. Exemplos práticos:

# Filtrar logs de um usuário específico (UID 1000)
sudo journalctl _UID=1000

# Filtrar logs gerados por um binário específico
sudo journalctl _EXE=/usr/sbin/sshd

# Filtrar logs do kernel
sudo journalctl _TRANSPORT=kernel

# Combinar campos: mensagens do sshd com prioridade info
sudo journalctl _EXE=/usr/sbin/sshd _PRIORITY=6

Conforme mencionamos, nossos especialistas da JRT Technology Solutions utilizam diariamente combinações como journalctl _SYSTEMD_UNIT=nginx.service _PID=12345 –since “30 min ago” para isolar rapidamente o contexto de um processo específico em produção. A indexação do journald faz com que mesmo journals com centenas de milhares de entradas sejam consultados em frações de segundo.

Configuração Detalhada do rsyslog — Arquivos e Regras

A configuração do rsyslog é definida em arquivos localizados em /etc/rsyslog.conf (configuração principal) e /etc/rsyslog.d/ (arquivos de configuração adicionais). A filosofia moderna é manter o arquivo principal enxuto e colocar suas regras customizadas em arquivos separados dentro de /etc/rsyslog.d/ — tipicamente nomeados como 50-nome-da-regra.conf. O número no início (50, 99, etc.) define a ordem de carregamento, permitindo que você controle a precedência das regras.

Vamos examinar o conteúdo completo do arquivo /etc/rsyslog.conf padrão do Ubuntu e comentar cada seção relevante. Este arquivo define os módulos carregados, as configurações globais e as diretivas de inclusão:

# /etc/rsyslog.conf — Configuração principal do rsyslog
# Este é o arquivo padrão do Ubuntu 24.04 LTS

#################
#### MODULES ####
#################

# Módulo para suporte a syslog sobre UDP tradicional (porta 514)
# Comentado por padrão — descomente se precisar receber logs remotos
#module(load="imudp")
#input(type="imudp" port="514")

# Módulo para syslog sobre TCP (mais confiável que UDP)
#module(load="imtcp")
#input(type="imtcp" port="514")

# Módulo para receber logs do journald via socket
module(load="imjournal" StateFile="imjournal.state")

###########################
#### GLOBAL DIRECTIVES ####
###########################

# Formato de timestamp tradicional (compatível com RFC 3164)
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# Habilita recebimento de mensagens via socket /dev/log (aplicações locais)
$ModLoad imuxsock

# Suporte a recebimento de logs do kernel
$ModLoad imklog

# Ativa o processamento de templates avançados
$WorkDirectory /var/spool/rsyslog

# Incluir todos os arquivos de configuração do diretório
$IncludeConfig /etc/rsyslog.d/*.conf

# Diretiva para onde enviar mensagens por padrão (catch-all)
*.*;auth,authpriv.none   -/var/log/syslog

# Arquivos específicos por facility/severity
auth,authpriv.*          /var/log/auth.log
*.*;auth,authpriv.none   -/var/log/syslog
kern.*                   -/var/log/kern.log
mail.*                   -/var/log/mail.log
mail.err                 /var/log/mail.err

# Cron (tarefas agendadas)
cron.*                   /var/log/cron.log

# Mensagens de emergência para todos os usuários logados
*.emerg                  :omusrmsg:*

Cada linha de regra segue o formato facility.severity ação. O asterisco * funciona como coringa: *.* significa “todas as facilities, todas as severities”. A sintaxe auth,authpriv.none na regra do /var/log/syslog instrui o rsyslog a NÃO gravar mensagens de auth e authpriv nesse arquivo (elas já vão para auth.log, e duplicá-las seria redundante). O hífen – antes do caminho do arquivo (ex: -/var/log/syslog) indica que a gravação deve ser assíncrona — o rsyslog não força um sync a disco após cada escrita, melhorando performance em sistemas com alto volume de logs, mas com um pequeno risco de perda das últimas mensagens em caso de crash.

Agora, vamos criar um arquivo de configuração customizado para uma necessidade comum: separar logs de um servidor web Nginx em seu próprio arquivo, utilizando a facility local0. Este é o procedimento padrão para aplicações que não possuem facility nativa no syslog:

# Criar arquivo de configuração customizado
sudo nano /etc/rsyslog.d/50-nginx.conf

# Conteúdo completo do arquivo 50-nginx.conf:
# ------------------------------------------------------------
# Regra: Todas as mensagens enviadas para facility local0
# com qualquer severidade serão gravadas em /var/log/nginx/access.log
# com rotação assíncrona (hífen)
local0.*    -/var/log/nginx/access.log

# Regra adicional: erros de local0 vão para arquivo separado
local0.err  /var/log/nginx/error.log
# ------------------------------------------------------------

Após criar o arquivo, precisamos verificar a sintaxe da configuração antes de reiniciar o serviço. O rsyslogd possui um modo de validação que detecta erros de sintaxe sem aplicar as mudanças:

# Verificar a configuração do rsyslog (modo de validação)
sudo rsyslogd -N1

# Se a saída for limpa, reiniciar o serviço para aplicar as mudanças
sudo systemctl restart rsyslog

# Verificar se o serviço reiniciou sem erros
sudo systemctl status rsyslog

# Saída esperada do comando 'rsyslogd -N1':
rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

Se houver algum erro de sintaxe, o rsyslogd reportará a linha exata e o tipo de erro. Nunca reinicie o rsyslog sem antes validar a configuração — um erro de sintaxe pode silenciosamente impedir que todos os logs do sistema sejam gravados, criando um apagão de visibilidade perigoso em produção. Em nossos treinamentos na JRT Technology Solutions, sempre reforçamos este mantra: valide, depois reinicie.

Configurando o Armazenamento Persistente do Journal

Por padrão, o journald armazena seus logs em /run/log/journal/, que é um sistema de arquivos em memória (tmpfs) — ou seja, os logs são perdidos a cada reboot. Para manter os logs do sistema persistentes entre boots, você precisa configurar o armazenamento em disco e criar o diretório /var/log/journal/. Este é um passo fundamental em servidores de produção, onde a capacidade de auditar eventos pós-reboot é mandatória para conformidade e troubleshooting.

O procedimento é idêntico em Ubuntu/Debian e Rocky/CentOS, pois mexe no arquivo de configuração do systemd-journald e na estrutura de diretórios gerenciada pelo systemd:

# Passo 1: Editar o arquivo de configuração do journald
sudo nano /etc/systemd/journald.conf

# Descomente e altere a linha Storage=auto para Storage=persistent
# (Remova o # do início da linha e defina o valor como persistent)
# Storage=persistent

# Passo 2: Criar o diretório de armazenamento persistente
sudo mkdir -p /var/log/journal

# Passo 3: Aplicar permissões corretas (o systemd-journald roda como root)
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

# Passo 4: Reiniciar o serviço do journald para aplicar as mudanças
sudo systemctl restart systemd-journald

# Passo 5: Verificar se o diretório foi populado com arquivos de journal
ls -la /var/log/journal/

# Saída esperada do 'ls -la /var/log/journal/':
total 16
drwxr-sr-x 3 root systemd-journal 4096 Jun 21 14:50 .
drwxrwxr-x 10 root syslog         4096 Jun 21 14:50 ..
drwxr-sr-x 2 root systemd-journal 4096 Jun 21 14:50 f9a8c2b3d1e64d7a9b5c3d4e5f6a7b8c

O diretório com nome hexadecimal é o machine ID do seu sistema, obtido de /etc/machine-id. Dentro dele, você encontrará arquivos com extensão .journal — estes são os bancos binários que contêm todos os logs persistentes. Para forçar o journald a rotacionar os arquivos imediatamente (útil após ativar a persistência), use sudo journalctl –rotate. Para verificar o uso de disco atual do journal, execute sudo journalctl –disk-usage.

A configuração de limite de tamanho é crítica: em servidores com pouco espaço em disco, o journal pode crescer descontroladamente. No arquivo /etc/systemd/journald.conf, você pode definir SystemMaxUse= (limite máximo em disco), SystemKeepFree= (espaço livre mínimo a manter) e SystemMaxFileSize= (tamanho máximo por arquivo de journal). Os valores padrão são razoáveis (SystemMaxUse normalmente 10% do tamanho do filesystem, cap em 4GB), mas em servidores de log é comum aumentar para 10GB ou mais, dependendo da retenção exigida:

# Trecho relevante do /etc/systemd/journald.conf após edição:
[Journal]
Storage=persistent
SystemMaxUse=5G
SystemKeepFree=10G
SystemMaxFileSize=1G
MaxRetentionSec=30day

Após alterar estes parâmetros, reinicie o systemd-journald com sudo systemctl restart systemd-journald e verifique se os limites foram aplicados corretamente com journalctl –disk-usage. A gestão adequada do espaço em disco para logs do sistema evita surpresas desagradáveis como servidores que param de responder porque o /var/log encheu completamente.

Verificando a Instalação / Testando a Configuração

Nesta seção obrigatória, vamos executar uma série de verificações práticas para garantir que todo o ecossistema de logs do sistema está funcionando corretamente — desde o journald até o rsyslog, passando pelas regras customizadas que criamos. Seguiremos um roteiro ordenado: gerar eventos de teste, verificar sua presença no journal, confirmar que o rsyslog os capturou e inspecionar os arquivos de destino.

Primeiro, geramos um evento de teste utilizando o comando logger, que envia mensagens diretamente ao socket do syslog. Vamos simular mensagens com diferentes facilities e severities para validar nossas regras:

# Enviar uma mensagem de teste com facility local0 e severity info
logger -p local0.info "TESTE_AULA17: Mensagem de info para local0"

# Enviar uma mensagem com facility local0 e severity err
logger -p local0.err "TESTE_AULA17: Mensagem de erro para local0"

# Enviar uma mensagem de autenticação simulada (facility authpriv)
logger -p authpriv.warning "TESTE_AULA17: Tentativa de login falhou para usuario teste"

A flag -p do logger especifica a prioridade no formato facility.severity. O texto em maiúsculas (TESTE_AULA17) é nossa string marcadora — facilita a localização nos logs. Após enviar as mensagens, verificamos se elas aparecem nos destinos esperados:

# Verificar no journal as mensagens marcadas
sudo journalctl -g "TESTE_AULA17" --no-pager

# Verificar no arquivo /var/log/syslog (Ubuntu) ou /var/log/messages (RHEL)
sudo grep "TESTE_AULA17" /var/log/syslog

# Verificar no arquivo customizado do nginx (se criado)
sudo cat /var/log/nginx/access.log | grep "TESTE_AULA17"
sudo cat /var/log/nginx/error.log | grep "TESTE_AULA17"

# Verificar no arquivo de autenticação
sudo grep "TESTE_AULA17" /var/log/auth.log

# Saída esperada do 'journalctl -g "TESTE_AULA17"':
Jun 21 15:00:01 ubuntu-server unknown[5678]: TESTE_AULA17: Mensagem de info para local0
Jun 21 15:00:05 ubuntu-server unknown[5680]: TESTE_AULA17: Mensagem de erro para local0
Jun 21 15:00:10 ubuntu-server unknown[5682]: TESTE_AULA17: Tentativa de login falhou para usuario teste

# Saída esperada do 'grep "TESTE_AULA17" /var/log/syslog':
Jun 21 15:00:01 ubuntu-server unknown: TESTE_AULA17: Mensagem de info para local0
Jun 21 15:00:05 ubuntu-server unknown: TESTE_AULA17: Mensagem de erro para local0
Jun 21 15:00:10 ubuntu-server unknown: TESTE_AULA17: Tentativa de login falhou para usuario teste

# Saída esperada do 'grep "TESTE_AULA17" /var/log/auth.log':
Jun 21 15:00:10 ubuntu-server unknown: TESTE_AULA17: Tentativa de login falhou para usuario teste

Agora verificamos a integridade do serviço e a comunicação entre journald e rsyslog. O socket /run/systemd/journal/syslog deve existir e o rsyslog deve estar lendo a partir dele. Para confirmar, podemos inspecionar os sockets abertos pelo rsyslogd:

# Verificar se o socket journal-syslog está sendo utilizado pelo rsyslog
sudo ss -lpx | grep syslog

# Verificar estatísticas do journal (entradas, tamanho, etc.)
journalctl --disk-usage

# Teste final: gerar um evento e acompanhar em tempo real
logger -p daemon.info "TESTE_AULA17_FINAL: Verificacao concluida" && \
sudo journalctl -f -n 1 & sleep 2; kill %1

# Saída esperada de 'ss -lpx | grep syslog':
u_str LISTEN 0      4096    /run/systemd/journal/syslog 12345       * 0
u_str LISTEN 0      4096    /dev/log                     12346       * 0

# Saída esperada de 'journalctl --disk-usage':
Archived and active journals take up 48.7M in the file system.

Se você conseguiu ver todas as mensagens de teste nos arquivos e no journal, com o rsyslog ativo e consumindo do socket correto, seu sistema de logging está plenamente funcional. A capacidade de gerar, rastrear e confirmar logs em múltiplos destinos é uma habilidade que diferencia administradores competentes — e esta verificação sistemática deve fazer parte de qualquer procedimento de deploy ou troubleshooting.

Erros Comuns e Como Resolver

Em nossa experiência na JRT Technology Solutions, encontramos repetidamente os mesmos problemas de configuração de logs do sistema em ambientes de clientes. Documentamos aqui os quatro erros mais frequentes, com suas causas, sintomas e soluções completas — para que você possa diagnosticá-los rapidamente e resolvê-los sem escalar para níveis superiores de suporte.

Erro 1: rsyslog não inicia após editar arquivo de configuração.
Causa: Erro de sintaxe no arquivo de configuração (vírgula no lugar de ponto, bloco de módulo mal fechado, diretiva obsoleta).
Sintoma: O comando systemctl restart rsyslog falha e journalctl -xeu rsyslog mostra mensagens como “error during parsing” ou “invalid selector”.
Solução: Execute sudo rsyslogd -N1 para validar a configuração. O validador indicará a linha exata do erro. Corrija o arquivo, valide novamente e só então reinicie o serviço. Se você não souber qual arquivo está causando o problema, mova temporariamente os arquivos de /etc/rsyslog.d/ para outro diretório, reinicie o rsyslog e vá adicionando-os de volta um a um até identificar o ofensor.
Erro 2: Logs não aparecem nos arquivos de destino.

Quer aprender na prática com especialistas?

A JRT Technology Solutions oferece treinamentos e implementação de Linux para equipes corporativas.

Falar no WhatsApp