Observabilidade começa pelas perguntas
Publicado em 02 de outubro de 2026
Parte 1 de 8 — série Observabilidade na prática.
Uma pessoa abre um catálogo e a página demora a responder. O container da API continua ativo, o banco aceita conexões e o host tem espaço livre. Nesse cenário hipotético, o que falta descobrir para explicar a demora? Mais um painel pode ajudar, mas a escolha do painel depende da pergunta.
Essa API de catálogo será o fio condutor da série. Ela consulta PostgreSQL e pode chamar um serviço externo, cujo nome precisa ser resolvido por DNS. É uma ilustração de investigação, sem medições ou resultados apresentados como reais. As ferramentas entram à medida que uma pergunta exige um sinal diferente.
Monitorar é acompanhar perguntas importantes
Um sistema pode estar em execução e ainda assim não atender seus usuários. Um processo pode estar saudável para o gerenciador de containers enquanto suas requisições demoram; um servidor pode responder ao ping mesmo sem conseguir resolver nomes externos; um banco pode aceitar conexões e estar perto de esgotar seus recursos.
Por isso, visibilidade operacional combina sinais de diferentes partes do sistema. Monitoramento costuma significar acompanhar indicadores conhecidos e verificar condições previstas. Observabilidade é a capacidade de investigar comportamentos que não foram completamente antecipados. Os dois se complementam: alertas ajudam a perceber um problema recorrente, e bons dados ajudam a entender algo inesperado.
Uma maneira prática de começar é anotar perguntas que a operação precisa responder:
- O serviço está recebendo requisições e respondendo dentro de um prazo aceitável?
- O uso de CPU, memória, armazenamento ou conexões está mudando?
- Quando houve uma falha, qual parte da requisição demorou ou retornou erro?
- A própria coleta está funcionando?
- Quanto histórico é necessário para investigar uma tendência?
Cada resposta deve levar a uma ação possível. Medir dezenas de coisas sem saber como interpretá-las produz ruído, custo e mais trabalho de manutenção.
Três sinais, perspectivas diferentes
Métricas são medições numéricas associadas ao tempo, como uso de memória, taxa de erros e duração de uma operação. Elas são boas para acompanhar tendências, comparar períodos e avaliar regras de alerta. Em geral, mostram que uma condição mudou, mas não explicam sozinhas o que aconteceu em uma requisição específica.
Logs registram eventos: uma conexão recusada, uma operação concluída ou uma mensagem de diagnóstico. Eles podem trazer mais contexto que uma métrica, mas também podem guardar dados pessoais, segredos ou conteúdo de usuários. Volume, retenção, custo de busca e política de redação precisam fazer parte do desenho.
Traces acompanham uma operação através de etapas instrumentadas. Uma chamada a uma API pode esperar no serviço, chamar um banco e depois consultar outra dependência. Um trace organiza essa sequência em spans, com duração e atributos de diagnóstico. Ele ajuda a localizar onde o tempo foi gasto; só cobre os trechos instrumentados e correlacionados.
Os sinais podem apontar uns para os outros. Uma métrica identifica um aumento de latência; os traces mostram etapas demoradas; os logs ajudam a explicar erros ocorridos nessas etapas. Essa correlação exige nomes e identificadores consistentes. Não basta instalar três produtos diferentes e esperar que a relação apareça automaticamente.
Um mapa antes das ferramentas
Voltando ao catálogo, podemos organizar a investigação pelo caminho da operação. O cenário supõe que a API usa um pool de conexões com PostgreSQL. Para chamar a dependência externa, o cliente HTTP pode precisar resolver seu nome; também pode usar uma resposta em cache ou reutilizar uma conexão existente. Isso dá origem a perguntas em camadas:
- Uma requisição entra na API e pode terminar com sucesso ou erro.
- A API consulta o banco e pode esperar por uma conexão ou por um lock.
- O serviço depende de nomes DNS para alcançar uma dependência externa.
- Um host e seus containers fornecem CPU, memória, disco e rede para esses serviços.
Esse mapa ajuda a escolher sinais em camadas. Métricas do host descrevem os recursos disponíveis. Sinais da aplicação descrevem trabalho e resultados. Métricas do banco explicam a atividade interna. Uma sondagem DNS avalia uma pergunta específica. A instrumentação da API e do cliente de banco pode registrar a chamada SQL como um span. Isso não pressupõe que o próprio PostgreSQL receba contexto de trace ou gere spans internos; essa cobertura exige uma integração específica.
Também torna visíveis as lacunas. Uma sonda realizada no próprio host não prova que outro computador consegue chegar ao serviço. Um painel de uso de disco não mostra necessariamente se uma gravação está lenta. Um healthcheck ausente não significa serviço falhando: pode significar que o container não implementa aquela verificação.
Começar pequeno e aprender
Um primeiro passo pode acompanhar o estado do processo, recursos do host, disponibilidade de uma aplicação e erros relevantes. Depois que essas medições funcionarem e responderem a perguntas reais, novos sinais podem entrar por serviço.
Defina para cada métrica, log ou trace: qual pergunta responde, de onde vem, que decisão pode apoiar, por quanto tempo será mantido e quem poderá consultá-lo. Esse registro é especialmente útil quando mais de uma pessoa mantém a stack ou quando a instrumentação cresce além de quem a criou.
Visibilidade tem custo. Cada sinal ocupa armazenamento, rede, processamento e atenção humana. Um instrumento que ninguém consulta pode ser removido ou reduzido. O objetivo é diminuir o tempo entre perceber um comportamento e compreender suas causas, sem transformar a observabilidade em outro sistema opaco para operar.
Para o catálogo, a primeira vitória seria distinguir três coisas: a operação realmente demorou, o serviço sofreu pressão ou a coleta deixou de observar o que aconteceu. Essa distinção orienta o próximo passo e evita gastar tempo ampliando a stack sem reduzir a incerteza.
Próxima parte: Grafana e Prometheus: da coleta à interpretação.