Observar o serviço e os seus utilizadores

Comece pela pergunta

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

Num serviço fictício de exportação, comece com uma pergunta do utilizador: um utilizador autorizado consegue receber o export correto dentro do tempo acordado? Depois, escolha sinais que respondam a essa pergunta e ajudem a explicar as falhas.

O OpenTelemetry fornece instrumentação e normas de telemetria. Pode enviar sinais para backends compatíveis. Continua a precisar de armazenamento, consultas, controlos de acesso, retenção e pessoas que atuem com base nas evidências. Introdução à observabilidade.

Ligue diferentes formas de evidência

Uma métrica mede uma quantidade ao longo do tempo. Um log regista um evento. Um trace liga operações relacionadas à medida que um pedido atravessa um sistema. Um span representa uma operação dentro de um trace.

Para trabalho assíncrono, preserve uma correlação segura entre o job submetido e a execução do worker. Uma resposta HTTP 202 pode significar que o trabalho foi aceite. Não prova que o export terminou.

Emita alertas quando for preciso agir

Defina o SLI e o respetivo denominador antes de estabelecer o SLO. No exemplo, conte os exports elegíveis concluídos corretamente dentro da duração acordada. Defina como entram na medição os jobs de longa duração e os abandonados.

Um orçamento de erro descreve o nível de falha permitido no período do SLO. A taxa de consumo descreve a rapidez com que as falhas consomem esse orçamento. As orientações da Google usam várias janelas temporais para equilibrar a deteção atempada e o ruído dos alertas. Alertas baseados em SLOs.

Contacte a pessoa de prevenção quando a condição exigir uma ação atempada. Encaminhe trabalho menos urgente para uma fila. Cada alerta precisa de um responsável, uma descrição do impacto, uma ligação para a investigação e uma instrução de resposta. Reveja alertas que repetidamente não levam a qualquer ação.

Não use um limiar genérico para todos os serviços. O impacto nos utilizadores, o tráfego, o horário de atividade e a capacidade de resposta afetam a decisão.

Proteja o pipeline de telemetria

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

Não use o email de um cliente ou um ID único de job como etiqueta de uma métrica. Etiquetas sem limites aumentam o número 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 controlo de acesso.

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

Investigue uma falha concreta

O serviço fictício devolve HTTP 202 para todos os pedidos. O tempo de espera dos jobs na fila aumenta de segundos para 15 minutos. Os logs dos workers mostram timeouts repetidos da base de dados. Os traces amostrados situam a maior parte do tempo dos workers em chamadas à base de dados.

Estas evidências sustentam uma investigação focada. Não permitem determinar se a causa é uma alteração da consulta, o esgotamento das ligações ou a capacidade da base de dados. Compare estas hipóteses com o método de depuração.

O Taiga Monitoring fornece uma perspetiva do estado do produto com sinais de disponibilidade e experiência no browser. Complementa a observabilidade da infraestrutura e da aplicação; não substitui esses sistemas. Monitoring.