Observabilidade com orçamento enxuto: logs, métricas, traces e alertas
Um backend pequeno não precisa de uma plataforma corporativa de telemetria para responder perguntas básicas de produção. Precisa saber se o cliente conclui o trabalho, onde a requisição falhou e se a fila está atrasando. Comece com poucos sinais de alto valor, conecte-os por IDs de correlação e acrescente detalhes quando incidentes mostrarem lacunas. O orçamento inclui atenção de quem opera, armazenamento e cardinalidade, não apenas a fatura do fornecedor.
Publicado em 28 de setembro de 202614 min de leituraSinais e alertas acionáveis
Comece pelas perguntas operacionais
Cada sinal responde a uma pergunta diferente
MétricasCom que frequência, quantos, quão lento?
TracesOnde a requisição gastou tempo?
LogsO que ocorreu nesta etapa?
AlertasAlguém precisa agir agora?
Fluxo
Sinais iniciais
Alerta acionável
API HTTP
Volume, erros e percentis de latência
Falha persistente percebida pelo usuário
Jobs
Idade da fila, tentativas, conclusão e falhas
Trabalho mais antigo ultrapassa o prazo
Integrações
Latência externa, throttling e atualização dos dados
Dados críticos estão atrasados além do combinado
Banco
Saturação de conexões, consultas e espera no pool
Requisições ficam sem conexão e degradam
Correlacione sem registrar tudo
Use logs estruturados com horário, serviço, ambiente, severidade, operação e ID de trace. Inclua identificadores de entidade apenas quando forem seguros e necessários; nunca grave tokens, senhas, corpos completos ou dados sensíveis de clientes. A correlação permite sair de uma métrica agregada para o trace e daí para poucos eventos relevantes.
Instrumente primeiro as fronteiras: requisição, banco, API externa, publicação na fila e execução do worker. A instrumentação automática do OpenTelemetry cobre bibliotecas comuns; adicione spans para operações de negócio, não para cada linha de código. Amostre traces de sucesso em alto volume e retenha falhas e lentidão conforme a política.
Controle cardinalidade e custo
Métricas ajudam a ver tendências, mas cada combinação de labels consome estado e armazenamento. Evite IDs de usuário, URLs dinâmicas, textos de erro arbitrários e IDs ilimitados de clientes como labels. Prefira rotas normalizadas, classe de status, operação, serviço e ambiente. Coloque detalhes de alta cardinalidade em traces amostrados ou logs pesquisáveis.
Alerte sobre sintomas
Um alerta urgente deve significar que alguém precisa agir. Use falhas persistentes percebidas pelo usuário, latência, prazo perdido de processamento ou consumo do orçamento de SLO. Envie avisos menos urgentes para tickets ou dashboards. Inclua fluxo afetado, valor, janela, responsável e link para procedimento. Um período mínimo reduz alertas por picos breves; teste a entrega completa da notificação.
Defina retenção e amostragem
Guarde logs de debug por pouco tempo, mantenha registros de auditoria sob política própria e amostre traces comuns. Retenção deve refletir investigação e sensibilidade. Revise volume após instrumentar: um único campo ruidoso pode dominar custos. Defina limites para bytes, traces e alertas e remova sinais que ninguém consulta.
Em resumo
Observabilidade enxuta é seletiva, correlacionada e ligada a decisões. Meça resultados para usuários, use traces para localizar latência, logs para eventos e alerte somente quando houver ação. Limite labels, proteja dados, estabeleça retenção e verifique se cada sinal justifica seu custo.