Observe o serviço e seus usuários

Comece pela pergunta

O monitoramento verifica condições conhecidas. A observabilidade ajuda a investigar o comportamento do sistema, incluindo falhas que você não previu. Mais dashboards não oferecem automaticamente respostas melhores.

Para um serviço fictício de exportação, comece com uma pergunta do usuário: um usuário autorizado consegue receber a exportação correta no tempo acordado? Depois, escolha sinais que ajudem a responder e a explicar as falhas.

O OpenTelemetry fornece instrumentação e padrões de telemetria. Pode enviar sinais a backends compatíveis. Você ainda precisa de armazenamento, consultas, controles de acesso, retenção e pessoas que ajam sobre as evidências. Introdução à observabilidade.

Conecte formas diferentes de evidência

Uma métrica mede uma quantidade ao longo do tempo. Um log registra um evento. Um trace conecta operações relacionadas enquanto uma requisição atravessa o sistema. Um span representa uma operação dentro de um trace.

Em trabalho assíncrono, preserve uma correlação segura entre o job enviado e a execução do worker. Uma resposta HTTP 202 pode significar que o trabalho foi aceito. Não prova que a exportação terminou.

Alerte quando for necessário agir

Defina o SLI e seu denominador antes de estabelecer o SLO. No exemplo, conte exportações elegíveis concluídas corretamente dentro da duração acordada. Defina como jobs de longa duração e jobs abandonados entram na medição.

Um orçamento de erro descreve a falha permitida na janela do SLO. A taxa de consumo, ou burn rate, descreve a velocidade com que as falhas consomem esse orçamento. As orientações do Google usam várias janelas para equilibrar detecção em tempo hábil e ruído de alertas. Alertas baseados em SLOs.

Acione uma pessoa quando a condição exigir uma ação rápida. Encaminhe trabalho menos urgente para uma fila. Todo alerta precisa de responsável, descrição do impacto, link para investigação e instrução de resposta. Revise alertas que repetidamente não levam a nenhuma ação.

Não use um único limite genérico para todos os serviços. Impacto no usuário, tráfego, horário de negócio e capacidade de resposta afetam a decisão.

Proteja o pipeline de telemetria

A telemetria pode conter dados pessoais, tokens, parâmetros de requisição e documentos confidenciais. Defina os campos permitidos antes da coleta. Restrinja acesso e retenção. Remova ou oculte segredos antes de exportar para um backend externo. Telemetria sensível.

Não use um e-mail de cliente ou ID único de job como rótulo de métrica. Rótulos sem limites aumentam a quantidade de séries temporais e podem expor identificadores. Use dimensões controladas nas métricas. Coloque identificadores de correlação aprovados em logs ou traces com controle de acesso.

Meça o próprio pipeline. Verifique falhas de ingestão, dados descartados e o tempo desde a observação mais recente. Um gráfico plano de erros pode significar ausência de erros ou ausência de telemetria recebida. Mostre essa distinção.

Investigue uma falha concreta

O serviço fictício retorna HTTP 202 para toda requisição. O tempo dos jobs na fila sobe de segundos para 15 minutos. Os logs dos workers mostram tempos limite de banco de dados excedidos repetidamente. Os traces amostrados concentram a maior parte do tempo dos workers em chamadas ao banco.

Essas evidências apoiam uma investigação focada. Não estabelecem se a causa é uma alteração de consulta, conexões esgotadas ou capacidade do banco. Compare essas hipóteses com o método de depuração.

O Monitoring da Taiga oferece uma visão da saúde do produto com sinais de disponibilidade e experiência no navegador. Complementa a observabilidade de infraestrutura e aplicação; não substitui esses sistemas. Monitoring.