Observabilidade para quem não tem time de SRE

Observabilidade virou sinônimo de uma pilha de ferramentas: coletor de métricas, banco de séries temporais, agregador de log, rastreamento distribuído, painel e gerenciador de alertas. Seis componentes para manter, atualizar e que também precisam ser monitorados.

Para operação com uma ou duas pessoas cuidando de infraestrutura, isso costuma produzir um resultado curioso: mais tempo mantendo o monitoramento que resolvendo o que ele aponta.

A boa notícia é que a maior parte do valor vem de poucos sinais, e eles cabem numa tarde de trabalho.

As perguntas que precisam de resposta

Antes de escolher ferramenta, vale definir o que se quer saber. Na prática, são quatro perguntas:

• Está no ar? A pergunta mais importante, e a que mais gente descobre por cliente.
• Está rápido? Latência percebida por quem usa.
• Está dando erro? Proporção de requisições que falham.
• Vai encher? Disco, memória e conexões que crescem até um limite.

Repare que nenhuma delas é "qual o uso de CPU". Uso de recurso é diagnóstico — importa depois que você já sabe que algo está errado. Alerta baseado em CPU produz notificação para situação normal e treina a equipe a ignorar.

Está no ar: o teste externo

O monitoramento mais valioso é o que roda fora da sua infraestrutura. Um script na própria máquina não avisa quando a máquina morre.

Serviços de verificação externa fazem isso de graça em plano básico, e vale usar. Se preferir controlar, um script em outra máquina resolve:

#!/usr/bin/env bash
# /usr/local/bin/check-externo.sh — roda em OUTRA máquina
ALVOS=("https://meusite.com.br/health" "https://api.meusite.com.br/health")
for u in "${ALVOS[@]}"; do
  cod=$(curl -sS -o /dev/null -w '%{http_code}' --max-time 10 "$u" || echo 000)
  [ "$cod" != "200" ] && echo "FORA: $u devolveu $cod"
done

Uma rota /health que confirma o essencial vale muito mais que a página inicial:

GET /health  →  200 se: aplicação viva, banco respondendo,
                        cache acessível, disco com espaço

Cuidado para não exagerar: se a rota verifica sete dependências externas, uma delas fora derruba o indicador inteiro e você perde a informação de que a aplicação em si está bem.

Está rápido e dando erro: o log já responde

Antes de instalar coletor de métricas, vale saber que o log de acesso do servidor web contém latência e código de resposta de cada requisição. Basta registrar:

log_format tempo '$remote_addr $status $request_time '
                 '$upstream_response_time "$request"';
access_log /var/log/nginx/access.log tempo;

E extrair o que interessa:

# Percentis da última hora
sudo awk -v h="$(date -d '1 hour ago' '+%d/%b/%Y:%H')" \
  '$0 ~ h {print $3}' /var/log/nginx/access.log | sort -n | awk '{a[NR]=$1}
  END {printf "p50=%.3f p95=%.3f p99=%.3f n=%d\n",
       a[int(NR*.5)], a[int(NR*.95)], a[int(NR*.99)], NR}'

# Taxa de erro
sudo awk '{c[$2]++} END {for (s in c) print c[s], s}' \
  /var/log/nginx/access.log | sort -rn | head

Isso responde "está rápido?" e "está dando erro?" sem nenhuma ferramenta nova. Para muita operação, é suficiente — e é infinitamente melhor que não ter resposta.

A distinção entre $request_time e $upstream_response_time é útil: a diferença entre os dois é o tempo gasto com o cliente, não com a aplicação. Cliente em rede ruim infla o primeiro sem que nada esteja errado do seu lado.

Vai encher: as tendências

Os recursos que se esgotam de forma previsível merecem acompanhamento de curva, não de valor instantâneo:

#!/usr/bin/env bash
# /usr/local/bin/coletar.sh — a cada 5 minutos
{
  printf '%s ' "$(date -Is)"
  printf 'disco=%s ' "$(df -P / | awk 'NR==2 {gsub(/%/,"",$5); print $5}')"
  printf 'mem=%s ' "$(free | awk '/Mem:/ {printf "%.0f", ($3/$2)*100}')"
  printf 'conn=%s ' "$(ss -tan state established | wc -l)"
  printf 'load=%s\n' "$(cut -d' ' -f1 /proc/loadavg)"
} >> /var/log/tendencias.log

Um arquivo de texto com uma linha a cada cinco minutos ocupa poucos megabytes por ano e responde a pergunta que mais importa: quando isso chega no limite?

O gráfico do painel dá a mesma informação para CPU, memória e disco sem nenhum trabalho — vale conferir o que já está disponível antes de coletar por conta própria.

Alerta que não vira ruído

Esta é a parte que mais determina se o monitoramento será útil ou ignorado.

A regra: alerta é para o que exige ação agora. Todo o resto é painel, para ser consultado quando alguém for olhar.

Três disciplinas complementam:

• Alerta que dispara e ninguém age precisa ser removido. Ele está treinando a equipe a ignorar os outros.
• Todo alerta precisa de ação óbvia. Se a reação for "vou observar", não era alerta.
• Notificação em canal que acorda alguém só para o que justifica acordar.

O alerta de backup que não rodou é o mais subestimado da lista. Backup falha em silêncio, e a descoberta acontece semanas depois, na hora da restauração — cenário descrito no artigo sobre testar restauração.

Log: centralizar sem projeto

Com poucas máquinas, o journal local resolve — e o artigo sobre journalctl mostra que ele responde bastante.

O journal tem envio remoto nativo, que evita adotar um agregador só para juntar os logs:

# Na máquina central
sudo apt install systemd-journal-remote
sudo systemctl enable --now systemd-journal-remote.socket

# Nas demais
sudo apt install systemd-journal-upload

# /etc/systemd/journal-upload.conf
[Upload]
URL=http://10.0.0.5:19532

Restrinja a porta à rede interna — ou melhor, faça o tráfego passar pela VPN, já que log costuma conter dado sensível.

Quando vale adotar ferramenta dedicada

Os sinais de que o arranjo simples ficou pequeno:

• Mais de cinco ou seis máquinas. Correlacionar à mão passa a doer.
• Vários serviços interdependentes, onde "quem causou a lentidão" não é óbvio.
• Necessidade de histórico longo com consulta rápida.
• Mais de uma pessoa investigando, precisando de vocabulário comum.
• Compromisso contratual de disponibilidade, que exige medição confiável.

Aí vale adotar uma stack — e o caminho mais econômico é começar por métricas, que é onde está o maior retorno, deixando rastreamento distribuído para quando houver serviços demais para acompanhar de cabeça.

O mínimo defensável, em ordem

Se for para fazer só o essencial, esta é a sequência por retorno:

• Teste externo de disponibilidade, com alerta. Meia hora de trabalho.
• Rota `/health` que confirme banco e disco.
• Alerta de disco em 85% e de backup que não rodou.
• Percentis de latência extraídos do log de acesso, olhados semanalmente.
• Coleta de tendência em arquivo de texto, para prever o que vai encher.
• Alerta de certificado vencendo, como no artigo sobre renovação de SSL.

São seis itens, nenhum exige ferramenta nova, e juntos respondem as quatro perguntas do começo. Um time pequeno com isso funcionando está em situação bem melhor que um time com stack completa que ninguém consulta — e a diferença entre os dois raramente é orçamento, é escolher o que medir antes de escolher com o que medir.

Registrar o que já foi investigado

Um hábito de custo quase zero que multiplica o valor de tudo acima: manter um registro curto dos incidentes.

Para cada ocorrência que exigiu investigação, três linhas bastam — o que aconteceu, qual era a causa, e como foi descoberta. Um arquivo de texto no repositório de infraestrutura serve.

O retorno aparece de duas formas. A primeira é o reconhecimento de padrão: na terceira vez que a mesma coisa acontecer, alguém vai lembrar que já viu — e o registro transforma "acho que foi algo com o disco" em "foi o log do worker sem rotação, em março".

A segunda é a orientação sobre onde investir. Um registro com seis meses de incidentes mostra objetivamente o que mais dói, e essa lista quase nunca coincide com a intuição. Vale mais para decidir a próxima melhoria que qualquer avaliação teórica de arquitetura.

É também o que permite responder a pergunta desconfortável que aparece em auditoria e em conversa com cliente: quantas vezes ficamos fora, por quanto tempo, e por quê. Sem registro, a resposta honesta é "não sabemos".

O erro de começar pela ferramenta

Vale fechar com o padrão que mais desperdiça tempo nesse tema: adotar a stack antes de definir as perguntas.

O caminho comum é instalar coletor e painel, importar dezenas de gráficos prontos, e terminar com uma tela cheia de números que ninguém olha — porque nenhum deles foi escolhido para responder algo específico. Meses depois, o monitoramento existe, está desatualizado e não impediu nenhum dos incidentes que aconteceram.

O caminho que funciona é o inverso. Escreva as perguntas primeiro, responda cada uma com o meio mais simples disponível, e só adote ferramenta quando o meio simples deixar de dar conta. Isso garante que cada componente adicionado tem uma pergunta associada — e que a stack cresce por necessidade, não por completude.

O teste final é direto: se acontecer um incidente hoje, o que você tem consegue dizer o que aconteceu? Se a resposta for não, o problema não se resolve adicionando mais um painel.