 |
| Bellacosa Mainframe e o journalctl no linux |
☕ Um Café no Bellacosa Mainframe
journalctl Muito Além do tail -f
O Que Todo Programador COBOL Padawan Precisa Saber Sobre Logs, Systemd, DevOps, Observabilidade e Como Grandes Bancos Descobrem Problemas em Produção Antes Que Eles Virem Incidentes
"O bom programador escreve código. O excelente programador aprende a investigar sistemas. E o profissional que trabalha em grandes ambientes críticos sabe que, muitas vezes, o log conta uma história muito antes do usuário abrir um chamado."
Introdução
Quando um desenvolvedor COBOL começa sua jornada no universo Linux, normalmente encontra um ambiente completamente diferente daquele que conheceu durante anos no IBM Z.
No Mainframe existe uma enorme quantidade de ferramentas especializadas:
SDSF
JES2
JES3
SYSLOG
LOGREC
RMF
SMF
RACF
IPCS
CICS Messages
DB2 Messages
Cada uma possui sua finalidade.
No Linux moderno existe algo semelhante, porém muito mais integrado.
Seu nome é Systemd Journal.
E a ferramenta que permite conversar com ele chama-se:
journalctl
Muitos iniciantes acreditam que o journalctl serve apenas para "ver logs".
Na realidade, ele é muito mais do que isso.
Ele é praticamente um mecanismo de investigação forense do sistema operacional.
Hoje vamos tomar um café e descobrir por que praticamente todo Engenheiro DevOps vive com uma janela do journalctl aberta.
O problema dos arquivos de log tradicionais
Durante décadas, o Linux utilizou arquivos texto.
Você provavelmente já ouviu falar em:
/var/log/messages
/var/log/syslog
/var/log/auth.log
/var/log/secure
/var/log/dmesg
Cada aplicação escrevia seus próprios registros.
Imagine um servidor contendo:
Apache
Nginx
Docker
PostgreSQL
Java
Python
Kubernetes
SSH
Firewall
Redis
Cada um gerando milhares de linhas por minuto.
Agora imagine descobrir por que uma API caiu exatamente às 14:32.
Você teria que abrir dezenas de arquivos diferentes.
Era exatamente esse o problema.
Imagine um grande banco
Vamos fazer uma analogia.
Imagine um banco processando:
PIX
TED
DOC
Internet Banking
Mobile Banking
Cartões
Crédito
Investimentos
Cada sistema produzindo logs.
Agora imagine que esses logs fossem gravados em centenas de arquivos espalhados.
Encontrar uma única falha seria semelhante a procurar uma agulha num palheiro.
Foi justamente para resolver esse caos que nasceu o Systemd Journal.
O que é o Systemd Journal?
Pense nele como um enorme banco de dados de eventos.
Em vez de simplesmente gravar texto em arquivos, o Systemd Journal armazena informações estruturadas.
Cada evento contém muito mais do que apenas uma mensagem.
Por exemplo:
Horário
Servidor
PID
UID
GID
Nome do Serviço
Executável
Container
Prioridade
Boot
Mensagem
Hostname
Machine ID
Kernel
Cgroup
Namespace
Ou seja...
O log deixa de ser somente texto.
Ele passa a possuir contexto.
Uma analogia para quem vem do Mainframe
No IBM Z temos diversas fontes de informação.
| IBM Mainframe | Linux |
|---|---|
| SDSF | journalctl |
| JESMSGLG | Journal |
| SYSLOG | Journal |
| Console do Operador | journalctl -f |
| LOGREC | Eventos críticos |
| RMF | Métricas do sistema |
| SMF | Eventos estruturados |
Não é exatamente igual.
Mas o conceito é extremamente parecido.
O administrador consulta um repositório central de eventos.
Como funciona internamente?
Imagine esta arquitetura.
Aplicação
↓
stdout
↓
stderr
↓
Kernel
↓
systemd-journald
↓
Banco de Eventos
↓
journalctl
Observe que o journalctl não cria logs.
Quem cria é o systemd-journald.
O journalctl apenas consulta.
Uma biblioteca gigante
Imagine uma biblioteca.
Cada livro possui:
autor
assunto
data
idioma
editora
Você consegue localizar qualquer livro em segundos.
O Journal faz exatamente isso.
Cada log recebe etiquetas.
Depois basta perguntar.
O comando mais simples
journalctl
Resultado:
Todos os eventos do sistema.
Pode facilmente retornar centenas de milhares de linhas.
Por isso quase nunca utilizamos o comando sozinho.
Consultando apenas um serviço
Aqui começa a verdadeira magia.
Imagine um servidor rodando Nginx.
Basta fazer:
journalctl -u nginx
Agora o Journal retorna apenas:
inicialização
parada
reload
erros
avisos
Tudo relacionado ao Nginx.
Sem grep.
Sem filtros complicados.
O que significa "-u"?
O parâmetro:
-u
Significa:
Unit
Ou seja:
Uma unidade do Systemd.
Normalmente um serviço.
Exemplos:
journalctl -u docker
journalctl -u nginx
journalctl -u ssh
journalctl -u postgresql
journalctl -u mysql
É um dos comandos mais utilizados em produção.
E se eu tiver minha própria aplicação?
Imagine que você criou uma API Java.
Ela roda como:
minha-api.service
Consultar seus eventos é simples.
journalctl -u minha-api
Pronto.
Todos os logs aparecem organizados.
Logs em tempo real
Uma das funções favoritas dos profissionais DevOps.
journalctl -f
O "-f" significa:
Follow.
É praticamente o equivalente moderno ao famoso:
tail -f
Enquanto chegam novos eventos, eles aparecem imediatamente.
Muito utilizado durante:
Deploy
Testes
Atualizações
Migrações
Produção
O que acontece durante um Deploy?
Imagine uma API.
Você faz:
systemctl restart minha-api
Em outra janela:
journalctl -u minha-api -f
Você observa tudo acontecendo.
Stopping service...
Loading configuration...
Connecting database...
Listening on port 8080...
Application Started.
Caso exista um erro, ele aparece na hora.
O famoso journalctl -xe
Você provavelmente verá esse comando em praticamente todo tutorial.
journalctl -xe
Ele mostra:
erros recentes
contexto
mensagens relacionadas
detalhes
Em vez de apenas:
Falhou.
Você recebe praticamente uma investigação.
Filtrando por tempo
Uma das maiores vantagens do Journal.
Últimos 30 minutos.
journalctl --since "30 min ago"
Última hora.
journalctl --since "1 hour ago"
Hoje.
journalctl --since today
Ontem.
journalctl --since yesterday
Intervalo específico.
journalctl \
--since "2026-07-04 08:00" \
--until "2026-07-04 10:00"
Isso elimina milhares de linhas desnecessárias.
Investigando um incidente
Imagine.
Às 15:22 um cliente informou:
"O sistema caiu."
Você pode consultar exatamente aquele período.
journalctl \
--since "15:15" \
--until "15:30"
É praticamente viajar no tempo.
Boot atual
journalctl -b
Mostra tudo desde o último boot.
Extremamente útil para investigar:
drivers
inicialização
montagem de discos
serviços
Boot anterior
journalctl -b -1
Imagine que o servidor reiniciou sozinho durante a madrugada.
Você consegue analisar exatamente aquele boot.
Isso economiza horas de investigação.
Prioridades
Nem todo log possui a mesma importância.
O Journal utiliza níveis.
0 Emergency
1 Alert
2 Critical
3 Error
4 Warning
5 Notice
6 Info
7 Debug
Consultar somente erros.
journalctl -p err
Somente críticos.
journalctl -p crit
Somente warnings.
journalctl -p warning
A verdadeira força: combinar filtros
O Journal permite combinar praticamente tudo.
Exemplo.
journalctl \
-u nginx \
-p err \
--since "1 hour ago"
Tradução.
Mostre:
apenas o Nginx
apenas erros
apenas na última hora
É exatamente isso que um analista faria durante um incidente.
O Journal é inteligente
Imagine um processo.
PID:
5412
Consultar.
journalctl _PID=5412
Ou um executável.
journalctl _EXE=/usr/bin/python3
Ou um usuário.
journalctl _UID=1000
Ou um comando.
journalctl _COMM=java
Você não precisa procurar texto.
Você consulta atributos.
É muito mais eficiente.
Kernel
Quer apenas mensagens do Kernel?
journalctl -k
Ali aparecem informações sobre:
CPU
Memória
USB
Drivers
Rede
Disco
NVMe
SATA
Muito útil para administradores.
Persistência
Um detalhe extremamente importante.
Algumas distribuições mantêm logs apenas na memória.
Após reboot.
Tudo desaparece.
Para ativar armazenamento permanente.
sudo mkdir -p /var/log/journal
Depois.
sudo systemctl restart systemd-journald
Agora os logs permanecem.
Configuração
Arquivo principal.
/etc/systemd/journald.conf
Ali controlamos:
Storage
Compress
Seal
SplitMode
SystemMaxUse
RuntimeMaxUse
MaxRetentionSec
RateLimitInterval
RateLimitBurst
Controle de espaço
Imagine um servidor Kubernetes.
Milhões de eventos.
O Journal possui limites automáticos.
Exemplo.
SystemMaxUse=5G
Nunca utilizará mais de cinco gigabytes.
Limpando logs
Por tamanho.
journalctl --vacuum-size=2G
Por tempo.
journalctl --vacuum-time=30d
Por quantidade.
journalctl --vacuum-files=10
Muito mais elegante do que apagar arquivos manualmente.
JSON
Pouca gente conhece.
O Journal consegue exportar em JSON.
journalctl -o json
Isso permite integração com:
Elastic
OpenSearch
Grafana Loki
Splunk
SIEM
Ferramentas de IA
Pipelines DevOps
Containers
O Docker pode enviar seus logs diretamente ao Journal.
Assim você pode consultar informações de containers utilizando filtros específicos, sem precisar acessar cada arquivo de log individualmente.
Em ambientes com dezenas ou centenas de containers, isso simplifica muito a operação e a análise de incidentes.
Observabilidade
Nos últimos anos surgiu uma palavra muito importante.
Observabilidade.
Ela responde perguntas como:
O sistema está saudável?
O que aconteceu?
Onde ocorreu?
Quando começou?
Qual serviço falhou?
Qual usuário foi afetado?
A observabilidade moderna normalmente é baseada em três pilares:
Logs
Métricas
Traces
O journalctl representa o primeiro pilar.
DevOps
Uma equipe DevOps dificilmente trabalha sem logs.
Imagine um pipeline.
Git Push
↓
Build
↓
Testes
↓
Deploy
↓
Restart
↓
journalctl
↓
Validação
Os logs confirmam se tudo ocorreu corretamente.
Um exemplo prático para um COBOL Padawan
Imagine que você modernizou um sistema COBOL utilizando IBM z/OS Connect para expor um serviço REST. Um gateway Nginx recebe as requisições, encaminha para uma API Java que, por sua vez, conversa com programas COBOL em CICS. Após um deploy, as chamadas começam a retornar erro HTTP 502.
Em vez de procurar em diversos arquivos, um engenheiro pode seguir uma sequência lógica:
Verificar os logs do Nginx:
journalctl -u nginx --since "10 min ago"Verificar a API Java:
journalctl -u minha-api --since "10 min ago"Consultar apenas mensagens de erro:
journalctl -p err --since "10 min ago"Acompanhar a recuperação em tempo real:
journalctl -u minha-api -f
Em poucos minutos é possível identificar se o problema está na aplicação, na infraestrutura ou em um serviço dependente.
Bellacosa Insight ☕
Existe uma frase muito conhecida entre administradores experientes:
"Logs não impedem falhas. Eles impedem que você fique perdido durante uma falha."
No Mainframe aprendemos a consultar o JES, o SYSLOG, o SDSF e os registros do sistema para entender o comportamento de uma aplicação. No Linux moderno, o journalctl desempenha um papel semelhante: ele centraliza informações críticas e fornece ferramentas poderosas para filtrar, correlacionar e investigar eventos.
Dominar o journalctl não significa decorar dezenas de parâmetros. Significa desenvolver uma mentalidade investigativa. O profissional deixa de apenas executar comandos e passa a formular perguntas ao sistema: o que aconteceu?, quando começou?, qual serviço foi afetado?, qual a gravidade?, o problema ocorreu antes ou depois do último reboot?.
É exatamente essa mudança de postura que diferencia um programador que apenas desenvolve software de um engenheiro capaz de manter aplicações críticas funcionando 24 horas por dia, sete dias por semana.
No fim das contas, em um grande banco, em uma fintech ou em qualquer ambiente corporativo moderno, os logs contam a história do sistema. Aprender a ler essa história é uma das habilidades mais valiosas para qualquer Programador COBOL Padawan que deseja evoluir para o universo de DevOps, SRE e Engenharia de Software Moderna.
Sem comentários:
Enviar um comentário