APRENDER. PRATICAR. EVOLUIR.Preservar resets antes de agregar
O laboratório representa duas instâncias do serviço funds. A primeira tem os valores 0, 60, 120, 0, 60 e 120 em minutos consecutivos; a segunda aumenta 120 por minuto. A soma prévia nunca desce, apesar do reset da primeira. Aos cinco minutos, o promtool calcula 2.75/s ao somar as taxas por série e 2.25/s sobre a série pré-agregada. A diferença mostra a informação escondida pela agregação. Não a interpretes como contagem exata de pedidos perdidos: rate estima uma taxa a partir de amostras e trata os limites da janela. Num dashboard de APS, mantém o contrato que permite distinguir reinícios de alterações de procura.
Escolher uma janela com amostras suficientes
Uma consulta pode estar correta na sintaxe e não ter dados suficientes para produzir uma taxa. No fixture, há uma amostra em cada minuto exato. Aos cinco minutos, a janela [1m] exclui a amostra situada exatamente no limite esquerdo e inclui a da direita. Fica apenas uma amostra, pelo que rate não produz o resultado pretendido. [2m] inclui duas e devolve 1/s para o counter que aumenta 60 por minuto. Esta observação não define a janela ideal para todos os serviços. Em operação, considera intervalo de recolha, falhas e atraso de deteção. Testa arranque, reinício e lacunas para não transformar ausência de estimativa em ausência de atividade.
Tratar labels como contrato de correspondência
O numerador do segundo fixture tem service=funds e region=eu; o denominador só tem service=funds. A divisão sem modificador fica vazia. Com uma série de cada lado e on(service), o resultado é 0.01 com o label service, sem region. Antes de aplicar esta solução a produção, confirma o significado das populações. Um total global pode ser o denominador errado para um SLI regional, mesmo que a consulta passe a devolver números. Se existirem várias séries por serviço, analisa a cardinalidade e a agregação ou correspondência necessária. group_left não distribui automaticamente tráfego pelas regiões. O contrato deve especificar também os labels que a saída precisa de preservar.
Distinguir zero observado, vazio e valor de fallback
No quarto fixture, uma série presente mantém zero e outra nunca é fornecida. absent_over_time não assinala a primeira; devolve um sinal de ausência para a segunda. Acrescentar or vector(0) faz a série em falta parecer zero no painel, mas não cria uma observação do serviço. Também não torna uma divisão 0/0 numa medição de sucesso: o caso sem eventos precisa de política explícita. Para séries esperadas, inicializar valores a zero pode melhorar o contrato de instrumentação. Mantém uma forma separada de observar a saúde da recolha. Num incidente, comunica desconhecido quando a evidência falta; não uses uma convenção visual para declarar recuperação.
Medir o limite de latência que foi aprovado
O quinto fixture publica um histograma clássico com buckets de 300 ms, 500 ms e infinito. As taxas são 90, 98 e 100 observações por segundo. A fração dentro de 300 ms é 90%; usar o bucket de 500 ms produziria 98% para uma pergunta diferente. Não mudes a legenda para corrigir a diferença. Se o limite aprovado não coincide com a resolução disponível, melhora a instrumentação ou apresenta uma estimativa identificada como tal. A população e a janela devem coincidir no numerador e no denominador. O laboratório usa histogramas clássicos de propósito; não estabelece equivalência de consultas nem precisão para todas as representações nativas.
Separar frescura da amostra e frescura do resultado
Uma amostra recente pode transportar informação antiga. O fixture de batch conserva o valor zero como instante do último sucesso e fornece amostras novas até t=600 segundos. time() menos o valor dá uma idade de 600 segundos; time() menos timestamp da métrica dá zero. São perguntas diferentes. Na aplicação real, documenta o que atualiza last_success: a execução terminar, a validação da saída ou outra condição acordada. O gestor de projeto deve incluir esse contrato no handover. Uma recolha saudável não demonstra que o ficheiro diário está atualizado. Correlaciona a idade do sucesso com a data de negócio, volume esperado e evidência de processamento autorizado.
# Independent PromQL expressions for the matching synthetic fixtures
sum by (service) (rate(dr_requests_total[5m]))
dr_error_rate / on (service) dr_total_rate
absent_over_time(dr_missing{service="funds"}[3m])
time() - dr_last_success_timestamp_secondsCom amostras novas em t=600 e last_success=0, a idade do último sucesso é 600 segundos. A idade da amostra é zero. O painel deve responder à pergunta acordada.
Armadilhas comuns
Agregação antes de tratar resets; janela com uma amostra; join válido com população errada; fallback como observação; bucket de 500 ms como limite de 300 ms.
Tópicos relacionados: SLIs e SLOs · Recolha de telemetria · Operação de batch
Verifica população, labels, tipo, janela e ausência antes de transformar um número num estado operacional.
Referência: Unit testing for rules · Observability 2026-09; selected OpenTelemetry, Prometheus and Dynatrace Classic concepts