journalctl no Debian 12 – Onde Estão Meus Logs?

Introdução.

O journalctl é a ferramenta de linha de comando para visualizar os logs gerenciados pelo systemd-journald, o sistema de registro de logs nativo do systemd. No Debian 12 (Bookworm), houve uma mudança significativa: o journald passou a ser o mecanismo de log padrão do sistema, substituindo o método tradicional baseado em syslog (geralmente fornecido pelo daemon rsyslog)

Em versões anteriores (como Debian 11 Bullseye), o rsyslog vinha instalado por padrão e recebia as mensagens do journald, gravando-as em arquivos de texto sob /var/log (por exemplo, /var/log/syslog)

Já no Debian 12, o pacote rsyslog não é mais instalado automaticamente, o que significa que os logs do sistema agora ficam centralizados no journald e são acessíveis principalmente via journalctl. Eu tenho utilizado e recomendado o uso do journalctl, como neste post.

Em outras palavras, o Debian 12 unificou os logs do sistema no journald, alinhando-se a uma tendência já presente em outras distribuições Linux modernas. Mas o que isso muda no dia a dia do administrador de sistemas? A seguir, vamos entender detalhadamente como era a estrutura de logs antes, como ficou agora e quais os impactos (incluindo prós e contras), além de apresentar comandos essenciais do journalctl e como retornar ao método tradicional caso necessário.

Na prática… Onde estão meus arquivos syslog, authlog…?

Como era antes (até o Debian 11): tradicionalmente, o Debian utilizava o rsyslog para registro de logs do sistema. Diversos arquivos de log em texto plano eram mantidos em /var/log/ – por exemplo: /var/log/syslog (log geral do sistema), /var/log/auth.log (autenticação), /var/log/kern.log (mensagens do kernel), /var/log/mail.log (serviço de mail), entre outros. Cada serviço ou componente do sistema podia gravar em arquivos separados, facilitando a localização por categoria. Administradores consultavam esses arquivos diretamente usando ferramentas clássicas como cat, tail, grep e awk para inspecionar eventos. No Debian 11, por padrão o journald encaminhava as mensagens para o rsyslog, que então as gravava nesses arquivos

Como é agora (Debian 12 em diante): os arquivos de log em /var/log/ mencionados acima deixaram de existir por padrão. Toda a saída de logs do sistema agora é capturada exclusivamente pelo systemd-journald e armazenada em um journal central. Esse journal é um banco de dados binário de logs localizado em /var/log/journal/ (no caso de logs persistentes em disco).

Para visualizar os eventos, utiliza-se o comando journalctl, em vez de abrir arquivos texto. Na prática, aquilo que antes era distribuído em vários arquivos agora é consultado de forma unificada. Por exemplo, ao rodar journalctl sem parâmetros, você verá todas as entradas de log disponíveis no journal (kernel, sistema, autenticação, etc.) mescladas em ordem cronológica. É possível filtrar por serviço, prioridade, intervalo de tempo e outras metainformações – funcionalidades proporcionadas pelo journald que antes exigiriam combinar grep/awk em múltiplos arquivos.

Vantagens do journald: a centralização e integração dos logs traz alguns benefícios claros. Primeiro, o journald armazena informações adicionais junto a cada registro (como nome da unidade de serviço, PID do processo, prioridade/severidade, timestamp com alta precisão, etc.), permitindo logs estruturados e consultas mais refinadas. O mecanismo de indexação interno possibilita busca rápida por critérios, algo semelhante a ter um mini banco de dados de logs. Também há melhorias em controle de acesso – por exemplo, usuários comuns não conseguem ler todos os logs a menos que tenham permissões específicas (normalmente é necessário estar no grupo adm ou usar sudo para ler logs do sistema).

Além disso, o journald suporta recursos como registros assinados criptograficamente para garantir integridade, compressão e rotação automáticas. Em resumo, ele traz para o sistema local capacidades que antes só eram obtidas com soluções de log centralizadas mais complexas. Do ponto de vista prático, um administrador pode inspecionar eventos de um serviço específico rapidamente (journalctl -u nome-do-serviço), ou filtrar apenas mensagens de erro (journalctl -p err), ou ainda ver tudo que aconteceu em uma janela de tempo definida – tarefas que com arquivos tradicionais poderiam ser trabalhosas.

Desvantagens e considerações: nem tudo são flores, e é importante mencionar os contras ou desafios dessa mudança. O journald utiliza um formato binário próprio para armazenar os logs, o que significa que você não pode simplesmente abrir o arquivo de log com um editor de texto ou usar ferramentas Unix comuns diretamente nele – é obrigatório usar o journalctl (ou APIs do systemd) para leitura. Para administradores acostumados ao método antigo, pode haver uma curva de aprendizagem: em vez de comandos clássicos curtos (tail -f /var/log/syslog), é preciso lembrar as opções do journalctl (por exemplo, journalctl -f para seguir em tempo real). Alguns comentam que isso pode ser “digitação extra desnecessária” comparado ao uso direto de utilitários tradicionais.

Além disso, a natureza monolítica do journald – que incorpora coleta, armazenamento, filtragem e outros recursos em um só componente – pode ser vista como mais pesada em comparação a uma cadeia de pequenas ferramentas (cada uma fazendo uma função específica). Outra consideração é a persistência dos logs: por padrão, se o journald não estiver configurado para armazenamento persistente, os logs ficam apenas em memória (voláteis) e se perdem após reboot. Em instalações novas do Debian 12, o journald normalmente já está configurado para salvar em disco (Storage=auto, criando /var/log/journal/ automaticamente se necessário), mas em upgrades a partir de sistemas antigos é bom verificar essa configuração.

Por fim, o journald não implementa nativamente o envio remoto de logs para um servidor central – algo com que muitos se preocupam em ambientes corporativos. Se houver necessidade de centralização de logs em outro host, é preciso recorrer a soluções adicionais (por exemplo, reativar o rsyslog ou usar o systemd-journal-remote). Em suma, a mudança exige adaptação: ferramentas de monitoramento que liam diretamente arquivos texto (como alguns analisadores de log, scripts de backup de logs ou mesmo o fail2ban) podem precisar ser reconfiguradas para ler do journal ou para apontar para novos caminhos.

Comandos Essenciais do journalctl

A ferramenta journalctl oferece diversas opções para filtrar e visualizar os logs. Aqui estão alguns comandos essenciais que todo administrador deve conhecer ao lidar com o Debian 12 (journald):

journalctl -f – Segue os logs em tempo real (modo follow), semelhante ao tail -f em um arquivo de log. Use este comando para monitorar continuamente as entradas de log à medida que elas ocorrem. Por exemplo, journalctl -f exibirá as novas mensagens de todos os serviços conforme elas vão surgindo. Você pode deixá-lo rodando em um terminal enquanto verifica o comportamento do sistema.
journalctl -u <serviço>.service – Mostra apenas os logs de um serviço específico (unidade do systemd). Substitua <serviço>.service pelo nome exato da unit que deseja filtrar. Por exemplo, journalctl -u ssh.service exibirá somente mensagens do serviço SSH (sshd), e journalctl -u apache2.service mostrará os logs do servidor web Apache. Isso facilita muito a depuração, pois você não precisa garimpar informações de um serviço específico no meio do log global. Dica: você pode omitir .service se for uma unidade do tipo serviço (ex.: -u apache2 já funciona).
journalctl --since "YYYY-MM-DD HH:MM:SS" – Exibe os logs a partir de uma data/hora específica. Você pode fornecer tanto datas absolutas ("2025-03-10 14:00:00", por exemplo) quanto descrições relativas como "1 hour ago" (há 1 hora). Por exemplo: journalctl --since "2023-12-01 08:00:00" mostraria tudo que ocorreu desde 1º de dezembro de 2023 às 08h00. Também é possível usar --until "..." de forma análoga para delimitar até uma data/hora. Esse recurso é muito útil para investigar eventos em um intervalo de tempo específico, como após um incidente ou durante a última inicialização.
journalctl -p err – Filtra os logs por prioridade. A opção -p (ou --priority) permite selecionar mensagens de certa gravidade. No exemplo, -p err mostra apenas mensagens de erro (priority “err”) ou mais graves (por design, inclui também níveis acima de erro, como critical, alert e emergency). Em outras palavras, esse comando lista erros severos ocorridos no sistema, ignorando informações informativas ou avisos menos importantes. Você pode ajustar o nível conforme necessário, por exemplo: -p warning para incluir avisos, ou -p crit para críticas e emergências. Os níveis de log seguem a convenção syslog (0 = emerg, 1 = alert, 2 = crit, 3 = err, 4 = warning, 5 = notice, 6 = info, 7 = debug). Assim, journalctl -p err equivale a prioridade ≤ 3, enquanto -p warning incluiria ≤ 4, e -p debug mostraria tudo (já que debug é o nível 7, o menos grave). Esse filtro de prioridade ajuda a focar rapidamente nos problemas mais sérios registrados.

Além desses, o journalctl possui muitas outras opções úteis – por exemplo, -b para ver logs do boot atual, ou -x/-e para fornecer informações extras/exibir o final do log – e suporta combinações dessas flags. Vale a pena consultar man journalctl ou journalctl --help para explorar mais possibilidades. Com prática, você poderá reproduzir praticamente qualquer análise que fazia nos arquivos de log tradicionais usando os parâmetros adequados do journalctl.

Restaurando os Logs no Padrão Tradicional (syslog)

Alguns administradores podem preferir (ou necessitar, por requisitos de software legados) voltar a ter os arquivos de log tradicionais em /var/log/ no Debian 12. Felizmente, isso é possível – o systemd-journald não impede o uso de um daemon de syslog. Para restaurar a funcionalidade de logs em texto como antes, siga estes passos:

Instale o rsyslog: Este é o daemon de syslog amplamente utilizado no Debian. Nos sistemas Debian 12, instalar o pacote rsyslog já é suficiente para reativar a geração dos arquivos de log tradicionais. Use o apt:

# Atualize a base de consulta do apt
apt-get update

# Instale o rsyslog
apt-get install rsyslog

O pacote inclui um serviço systemd (rsyslog.service) que iniciará automaticamente após a instalação e também será habilitado para iniciar nos boots futuros.

Verifique a configuração padrão: Em muitos casos, nenhuma alteração manual é necessária. O arquivo /etc/rsyslog.conf e os incluídos em /etc/rsyslog.d/ já possuem definições para gravar os principais logs do sistema. Por exemplo, por padrão o rsyslog no Debian tem linhas configurando auth.log, cron.log, kern.log, mail.log, user.log, além do consolidado syslog. Após a instalação, o rsyslog começará a ouvir as mensagens do sistema (journald encaminha para o socket do syslog ou os serviços logam diretamente em /dev/log) e criará os arquivos em /var/log/ como antigamente. Você pode testar isso gerando algum evento (por exemplo, fazendo login SSH para gerar entrada em auth.log) e verificando se o arquivo correspondente aparece em /var/log.
Atenção à duplicação de logs: Uma vez que o rsyslog esteja ativo, você terá dois sistemas de log operando em paralelo – o journald e o rsyslog. Por padrão, o journald continuará mantendo o seu journal (em memória ou disco) mesmo enviando mensagens para o rsyslog. Isso significa que as mesmas mensagens estarão sendo gravadas duas vezes: uma no journal binário e outra nos arquivos texto do rsyslog. Em geral isso não causa problemas funcionais e garante redundância, mas pode implicar em uso extra de espaço em disco. Se o objetivo for exclusivamente retornar aos logs em texto e economizar espaço, você pode desabilitar a persistência do journald (editando /etc/systemd/journald.conf para Storage=volatile ou simplesmente removendo o diretório /var/log/journal para forçar logs apenas em memória). Assim, o journald manterá apenas logs voláteis (para suporte a journalctl -f, por exemplo), enquanto o rsyslog armazenará tudo em /var/log. Importante: Avalie bem antes de desativar o journald ou apagar seus logs, pois você perderá funcionalidades do journalctl. Alternativamente, pode-se manter ambos e usar cada um conforme a necessidade.
Logs tradicionais de volta: Com o rsyslog em execução, administradores poderão novamente usar comandos familiares como tail -f /var/log/syslog ou consultar arquivos específicos como /var/log/auth.log. O comportamento será praticamente o mesmo de um Debian 11. Lembre-se apenas de gerenciar a rotação desses logs (o logrotate já cuida disso em Debian) e verificar compatibilidade de ferramentas (a maioria, como logwatch, fail2ban, etc., detecta automaticamente se deve usar journald ou arquivos texto, mas é bom conferir).

Em resumo, restaurar os logs clássicos no Debian 12 é tão simples quanto instalar o pacote rsyslog, já que a configuração padrão cobre os casos mais comuns. Isso oferece uma saída para quem tem scripts legados ou preferências pessoais pelos arquivos plaintext, permitindo que a transição para o journald seja feita no seu próprio ritmo.

Finalizando

A adoção do journalctl (systemd-journald) como padrão no Debian 12 representa uma mudança importante na forma de lidar com logs do sistema. Essa mudança centraliza e moderniza o logging, trazendo recursos avançados de filtragem e pesquisa que podem melhorar a vida do administrador – especialmente em sistemas complexos com muitos serviços. Por outro lado, envolve abrir mão (ao menos por padrão) da simplicidade dos arquivos de texto onipresentes em /var/log/ que tantos admins Unix/Linux já dominam de olhos fechados.

Para os administradores de sistemas, a dica principal é: familiarize-se com o journalctl. Aproveite um tempo para aprender os comandos básicos mencionados (e outros, conforme necessário), pois eles serão seus aliados na hora de diagnosticar problemas no Debian 12 e em diante. Considere também atualizar procedimentos e documentações internas: por exemplo, se antes você instruía alguém a verificar “o arquivo X em /var/log”, agora talvez tenha que ensiná-lo a usar journalctl com os filtros apropriados. Ferramentas automatizadas de monitoramento de logs devem ser revisadas – muitas já suportam o journald nativamente (via APIs ou comando journalctl), mas talvez precisem de ajustes de configuração.

É natural que haja alguma resistência ou curva de aprendizagem na transição. Administradores veteranos podem inicialmente estranhar a mudança “rumo ao Event Log do Windows”, como alguns criticam. No entanto, vale lembrar que a introdução do journald visa justamente facilitar a análise de logs em sistemas modernos com volume crescente de mensagens. A longo prazo, a capacidade de fazer consultas avançadas e ter logs estruturados pode superar a falta do grep nos arquivos texto. E para quem realmente precisar dos arquivos tradicionais, o Debian 12 não impede essa flexibilidade – em poucos minutos é possível reinstaurar o bom e velho /var/log/syslog e cia.

Em suma, o impacto para os administradores de sistemas será positivo se abraçarem as novidades: com o journalctl, ganha-se uma poderosa ferramenta de troubleshooting, e o Debian 12 fica alinhado às práticas contemporâneas de logging. Já para ambientes legados ou casos especiais, a distribuição oferece meios de manter a compatibilidade com o modelo antigo. O importante é conhecer ambas as abordagens para tirar o melhor proveito de cada uma. Boa administração de logs!

Você conhecia o journalctl? Prefere o sistema legado? Conte para nós sua experiência nos comentários.

Referências

Compartilhe!

Comandos Essenciais do journalctl

Deixe um comentário Cancelar resposta