Não dá para instalar monitoramento depois que o sistema já está no ar?

Dá para instalar o genérico — uso de CPU, memória, se a página respondeu. O que não dá para adicionar depois é o que interessa no incidente: o significado de negócio de cada operação, que só existe se alguém instrumentou o código quando o escreveu.

Qual ferramenta de observabilidade vocês recomendam?

A escolha da ferramenta é a parte menos importante e a mais discutida. O que muda o tempo de recuperação é o que foi instrumentado e se existe alerta que chega em alguém antes do cliente ligar. Ferramenta boa sobre sistema sem instrumentação continua sem responder por onde olhar.

Quanto isso custa em desempenho?

Pouco, quando é decidido no projeto: registro estruturado e métrica agregada custam frações de milissegundo. Caro é o oposto — descobrir a causa por tentativa e erro com o sistema fora do ar.

Observabilidade não se instala depois do

Quando o sistema cai, o tempo até voltar depende do que foi instrumentado antes. Por que observabilidade adicionada depois nunca cobre o que interessa.

O sistema caiu. A equipe entra em chamada, alguém abre o servidor, e começa a pergunta que define quanto vai durar: por onde a gente olha?

A resposta a essa pergunta foi decidida meses antes, quando o sistema foi construído. Se ninguém instrumentou nada, o que resta é adivinhar — e adivinhar é a parte cara de um incidente, não corrigir.

Por que "colocamos monitoramento depois" não funciona

Observabilidade adicionada depois de pronto quase sempre vira: uso de processador, uso de memória, o sistema responde ou não responde.

São métricas de máquina. Elas dizem que algo está errado, o que você já sabia — o telefone tocou. Não dizem o quê.

O que resolve incidente é informação de domínio: quantos pedidos entraram na fila e quantos saíram, quanto tempo a integração com o gateway levou para responder, quantas tentativas de pagamento falharam na última hora e com qual erro. Esses números não existem por acaso: alguém precisa tê-los emitido no ponto do código onde o evento acontece.

Por isso não dá para instalar depois. Instrumentação é parte do código, não uma camada por cima.

Três coisas, e elas não se substituem

Registro estruturado. Não texto corrido — evento com campos. Em vez de escrever uma frase que alguém vai ter que interpretar, emita um registro com o identificador da operação, o cliente, a duração e o resultado. A diferença aparece no incidente: com texto você lê; com campos você filtra e agrega, e a resposta sai em segundos.

Métrica. Número agregado ao longo do tempo. Serve para responder "isso é normal?" — pergunta que é impossível de responder sem histórico. Sem métrica, toda anomalia parece igualmente grave, e a equipe queima energia em variação normal.

Rastro. O caminho de uma requisição atravessando as partes do sistema. É o que diz onde os oitocentos milissegundos foram gastos. Sem rastro, otimização vira palpite — e o palpite costuma cair no lugar errado.

Um identificador único por requisição, propagado por tudo e presente em todo registro, é o que faz as três se ligarem. É barato de implementar e é a diferença entre investigar um incidente em minutos ou em horas.

O alerta que ninguém mais lê

Toda equipe que já sofreu um incidente cria alertas. Muitos. Alguns meses depois, ninguém olha para eles.

O motivo é sempre o mesmo: alerta que dispara sem exigir ação treina a equipe a ignorar. E aí o alerta que importava chega no meio do ruído.

A regra que sustenta é dura e simples: todo alerta precisa ter uma ação associada. Se, ao receber, a resposta honesta for "vou olhar depois", aquilo não é alerta — é métrica que alguém achou interessante. Métrica mora no painel; alerta acorda gente.

Um punhado de alertas que sempre exigem ação vale mais que cinquenta que às vezes exigem.

Custo: o que não se mede, não se questiona

Conta de nuvem sem rastreio por serviço é um número que se aceita porque não há como contestar.

Marcar recursos por serviço e ambiente custa pouco e muda a conversa: dá para ver que o ambiente de homologação custa quarenta por cento do total, que a cópia de segurança está guardando dados de dois anos que ninguém consulta, que a máquina dimensionada para um pico que nunca voltou continua ligada.

Nada disso é otimização sofisticada. É desperdício estrutural que ficou invisível porque a conta chegava agregada.

Antes de trocar a infraestrutura, meça

Diante de lentidão, a reação comum é aumentar a máquina. Às vezes resolve. Quase sempre esconde.

Boa parte dos ganhos de desempenho em sistema de informação vem de dois lugares: consultas ao banco que fazem muito mais trabalho do que precisam, e trabalho repetido que poderia ter sido guardado em memória. Nenhum dos dois melhora proporcionalmente com máquina maior — e os dois pioram quando o volume cresce, porque você comprou tempo, não solução.

Medir antes de mexer não é preciosismo de engenheiro. É o que separa gastar uma vez de gastar todo mês.

O critério prático

Quando avaliar um sistema — para comprar, para herdar ou para modernizar — uma pergunta resume tudo:

"Se isso cair às três da manhã, o que a pessoa de plantão abre primeiro?"

Se a resposta for um painel específico, existe observabilidade. Se for "a gente entra no servidor e vê os registros", não existe — e o custo disso não aparece no orçamento do projeto. Aparece no tempo de cada incidente futuro, um por um.

Como aplicamos isso: registro estruturado, métrica e alerta configurados junto com o sistema, não depois. Veja cloud e plataforma.

Observabilidade não se instala depois do incidente