DevOpsQuest
0 XP
Módulo 1 · Linux e Sistemas

Logs: encontrar a causa raiz com journalctl

Intermediário 45 min+25 XPjournalctlgreplogrotate

Objetivos desta aula

  • Filtrar logs por unidade, prioridade e janela de tempo
  • Encontrar o primeiro erro de uma cascata de falhas
  • Correlacionar eventos entre proxy, aplicação e banco
  • Padronizar log estruturado e evitar disco cheio
  • Proteger dados sensíveis ao compartilhar log

1. Log é a fonte primária de verdade

Em um incidente, opinião não vale nada; evidência vale tudo. O log é o registro do que o sistema realmente fez, com hora. Toda investigação séria começa nele e só depois formula hipótese.

2. Onde os logs ficam

  • journald (systemd): consultado com journalctl, indexado por unidade, prioridade e tempo.
  • /var/log/: arquivos de serviços que escrevem direto (nginx, PostgreSQL, aplicação).
  • Containers: saída padrão do processo, coletada pelo runtime.

3. Níveis de prioridade

De 0 a 7: emerg, alert, crit, err, warning, notice, info, debug. journalctl -p err traz erro e acima. Em produção, a aplicação registra em info; debug só temporariamente, porque enche disco e pode expor dados.

4. As quatro consultas que resolvem quase tudo

  • Por unidade: journalctl -u cloudshop-api -n 200.
  • Só erros recentes: journalctl -u cloudshop-api -p err --since "10 min ago".
  • Janela exata: --since "2026-09-06 09:00" --until "09:30".
  • Ao vivo: journalctl -u cloudshop-api -f.

Combine-as: a interseção de unidade, prioridade e tempo costuma revelar a primeira falha.

5. Procure o primeiro erro, não o último

Cascatas escondem a origem: o timeout do frontend aparece depois do erro de conexão com o banco. Ordene por tempo crescente e pergunte: qual foi a primeira anomalia? Essa disciplina separa quem adivinha de quem diagnostica.

6. Correlação entre camadas

Pegue o horário do erro visto pelo usuário e compare, no mesmo minuto: log do proxy (código HTTP e latência), log da aplicação (exceção) e log do banco (conexões recusadas, lentidão, deadlock). Se a aplicação propaga um identificador de requisição, a correlação fica trivial.

7. Log estruturado (JSON) muda o jogo

Texto livre é difícil de filtrar. Log em JSON com level, msg, requestId, rota e duracaoMs permite consultas precisas, gráficos e alertas — e é o formato que ferramentas como Loki e OpenSearch esperam. Vamos usá-lo no módulo de observabilidade.

8. Preserve a evidência

Erro clássico de iniciante: reiniciar o serviço antes de coletar log, apagando o rastro. A ordem correta é: copiar o trecho relevante para o registro do incidente, depois agir. Em container, reiniciar pode apagar o log anterior por completo.

9. Log enche disco — e derruba serviço

Limite o journal (SystemMaxUse em /etc/systemd/journald.conf) e configure logrotate para os arquivos da aplicação: rotação diária, retenção de 14 dias, compressão. Sem isso, o incidente seguinte será "disco cheio" causado pela sua própria observabilidade.

10. Log é risco de vazamento

Token, cookie de sessão, cartão, CPF e e-mail não devem ir para log. Antes de colar log em chamado ou chat, remova identificadores. Muitos vazamentos reais aconteceram por log compartilhado, não por invasão.

11. Analisando com pipes quando não há ferramenta

grep, awk, sort, uniq -c e wc -l resolvem contagem por hora, top de mensagens e taxa de erro. É o que você usa em um servidor sem acesso a painel — situação mais comum do que parece.

12. Checklist de investigação por log

  1. Qual serviço reclamou e em que horário exato?
  2. Quais erros existem nessa janela, em ordem crescente?
  3. Qual foi o primeiro?
  4. O que mudou antes disso (deploy, configuração, tráfego)?
  5. Que evidência eu guardo no registro do incidente?

Na prática

Consultas essenciais

bash

journalctl -u cloudshop-api -n 200 --no-pager
journalctl -u cloudshop-api -p err --since "10 min ago"
journalctl --since "2026-09-06 09:00" --until "2026-09-06 09:30"
journalctl -u cloudshop-api -f              # seguir ao vivo
journalctl -k -p warning                     # mensagens do kernel (ex.: OOM killer)
journalctl --disk-usage                      # Archived and active journals take 1.8G
sudo journalctl --vacuum-size=500M           # reduz para 500M

# logs de aplicacao fora do journal
sudo grep -c "ERROR" /var/log/cloudshop/app.log        # 312
sudo awk '/ERROR/{print $1, $2, $NF}' /var/log/cloudshop/app.log | tail -20

Nota de segurança: Antes de colar log em ticket ou chat, remova tokens, e-mails e IDs de clientes. Log compartilhado é vazamento frequente.

Encontrando o primeiro erro de uma cascata

bash

# 1) Janela do incidente, todos os servicos, ordem crescente
journalctl --since "09:58" --until "10:05" -p warning --no-pager | head -40
# 09:59:12 cloudshop-db  FATAL: too many connections   <- PRIMEIRA anomalia (causa)
# 09:59:14 cloudshop-api Error: connect ETIMEDOUT
# 10:00:02 nginx         upstream timed out (110)      <- sintoma visivel

# 2) Confirme a hipotese no servico de origem
journalctl -u cloudshop-db --since "09:55" | grep -i "connection" | head
# 3) O que mudou antes? Deploy, reinicio ou configuracao
journalctl --since "09:30" | grep -iE "started|stopped|reload" | head

Log estruturado em JSON na aplicação

javascript

function log(level, msg, extra = {}) {
  // uma linha por evento: facil de filtrar, agregar e alertar
  process.stdout.write(JSON.stringify({
    ts: new Date().toISOString(),
    level,                       // info | warn | error
    msg,
    service: "cloudshop-api",
    ...extra,
  }) + "\n");
}

app.use((req, res, next) => {
  const inicio = Date.now();
  res.on("finish", () => {
    log("info", "request", {
      requestId: req.headers["x-request-id"],   // permite correlacionar entre servicos
      rota: req.path,
      status: res.statusCode,
      duracaoMs: Date.now() - inicio,
    });
  });
  next();
});

Nota de segurança: Nunca inclua headers de Authorization, cookies, senha ou dados pessoais no objeto de log.

Rotação de log da aplicação

ini

# /etc/logrotate.d/cloudshop
/var/log/cloudshop/*.log {
  daily
  rotate 14
  compress
  delaycompress
  missingok
  notifempty
  create 0640 cloudshop cloudshop
  sharedscripts
  postrotate
    systemctl reload cloudshop-api > /dev/null 2>&1 || true
  endscript
}
# Teste sem aplicar: sudo logrotate -d /etc/logrotate.d/cloudshop
# Forcar execucao:   sudo logrotate -f /etc/logrotate.d/cloudshop

Por que isso importa

Vagas pedem troubleshooting. Na prática, isso significa ler log com método e provar a causa com evidência.

Erro comum

Reiniciar o serviço antes de coletar log e perder a evidência do que aconteceu.

Dica de produção

Padronize log estruturado em JSON com nível, requestId e contexto. Isso torna busca e alerta viáveis.

Alerta de segurança

Nunca logue Authorization, cookies de sessão ou dados de pagamento.

Pergunta de entrevista

Como você correlaciona uma falha vista pelo usuário com o log da aplicação e do banco?

Glossário

journald
Coletor de logs do systemd, com índice binário e filtros por metadados.
logrotate
Utilitário que rotaciona, comprime e remove logs antigos por política.
prioridade (severity)
Nível do evento, de emerg a debug, usado para filtrar ruído.
log estruturado
Log em formato de dados (JSON) com campos consultáveis em vez de texto livre.
requestId
Identificador propagado entre serviços para reconstruir o caminho de uma requisição.
cascata de falhas
Sequência de erros derivados de uma causa única, que esconde a origem.
OOM killer
Mecanismo do kernel que encerra processos quando a memória se esgota.

Conexão com o CloudShop

Padronizar o log JSON da API do CloudShop e configurar rotação diária.

Quiz da aula

  1. 1. Qual comando mostra apenas erros da unidade nos últimos 10 minutos?

  2. 2. Em uma cascata de erros, qual deles normalmente aponta a causa?

  3. 3. Por que preferir log em JSON a texto livre?

  4. 4. Qual é a atitude correta ao encontrar um serviço com erro?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima