APRENDER. PRATICAR. EVOLUIR.Uma comparação bool não filtra a instância saudável
A terceira experiência usa uma taxa de erro de 0.01 e limiar 0.02. A comparação normal não devolve a série porque a condição é falsa. Com bool, conserva um elemento com valor zero. Uma regra de alerta considera os elementos presentes no resultado, pelo que a versão deliberadamente incorreta fica ativa. Isto é útil para compreender por que motivo uma expressão num dashboard pode não servir diretamente como regra de alerta. Antes de ativar, testa um serviço saudável e verifica se o resultado deveria ser vazio. O ficheiro do laboratório inclui esta regra errada para demonstrar o comportamento; não deve ser publicado como configuração operacional.
Manter estável a identidade do alerta
A fila tem valores 10, 11, 12 e 13 nas primeiras avaliações. A regra estável preserva service e severity; a regra incorreta acrescenta observed com o valor da fila. Cada alteração desse label cria uma identidade diferente e impede completar o período pending de três minutos. Uma annotation pode mostrar o valor atual sem alterar a identidade. No laboratório, a regra estável chega a firing em t=3m, enquanto a dinâmica está pending com observed=13. Não confundas esta identidade com o agrupamento de notificações no Alertmanager. O primeiro problema pertence à avaliação da regra; agrupar mensagens por serviço numa etapa posterior não recupera o tempo pending perdido.
Ensaiar lacunas e recuperação na linha temporal
for exige continuidade da instância ativa. No oitavo fixture, uma série stale interrompe pending em t=2m; a condição regressa em t=3m e só completa três minutos em t=6m. Noutro fixture, a regra já está firing quando a condição termina em t=4m. Com keep_firing_for de dois minutos, continua firing em t=5m e termina em t=6m. A espera pode evitar resoluções demasiado rápidas, mas não substitui a investigação dos dados em falta. O turno precisa de distinguir condição atual, estado retido e notificação entregue. Regista o intervalo de avaliação e as hipóteses do ensaio para não prometer tempos exatos diferentes dos que o desenho suporta.
Fixar a população e interpretar o orçamento
O fixture de canary contém 100 consultas elegíveis com dois erros e 900 health checks bem-sucedidos. Misturar tudo produz 0.2%; o SLI das consultas produz 2%. A medição deve seguir a definição acordada, não a versão que permite aprovar a mudança. Para interpretar consumo relativo, divide a fração de eventos maus pela fração permitida. Num exemplo separado, 2% sobre tolerância de 0.5% dá burn rate 4. Isso não significa automaticamente 4% do orçamento mensal consumido nem quatro minutos restantes. Essas conclusões exigem período, população e hipóteses adicionais. Usa os resultados para uma decisão com autoridade definida e preserva evidência da coorte afetada.
Conservar dimensões úteis para investigar a release
Uma série agregada por serviço pode ser suficiente para o estado global, mas não reconstrói uma versão removida na agregação. Planeia que dados permitem comparar canary e versão anterior dentro dos limites de retenção e custo. Durante a investigação, usa traces com relações temporais: três filhos de 100, 200 e 300 ms podem sobrepor-se dentro de um pedido de 350 ms. Somar os filhos não dá a latência end-to-end. Procura esperas e o caminho até à conclusão, com os limites da instrumentação. Uma coincidência com a release pode orientar a hipótese, mas a decisão de rollback deve respeitar critérios, autoridade e compatibilidade conhecidos.
Aceitar a cadeia completa de observação e resposta
O laboratório executa dez grupos originais no promtool 3.15.0, com 20 verificações de expressões e 12 de estados de alerta, além da validação das cinco regras. Não inicia Prometheus, não recolhe produção e não envia notificações. Passar estes testes demonstra o comportamento dos fixtures, não a entrega ao operador nem uma instalação Dynatrace. O handover deve incluir owner, runbook, permissões, métricas de frescura e ensaio autorizado de encaminhamento para um destino de teste. Para declarar recuperação do batch, confirma a saída útil e a sua data, além do exporter. Estes exemplos são fictícios e não representam procedimentos internos de qualquer banco.
groups:
- name: training-example
rules:
- alert: QueueStable
expr: dr_queue_depth > 5
for: 3m
labels:
severity: training
annotations:
summary: "Queue remains high"
observed: "{{ $value }}"A regra com labels estáveis chega a firing em t=3m. Acrescentar observed com o valor variável da fila mantém identidades novas em pending; mover o valor para annotation corrige essa separação.
Armadilhas comuns
bool como filtro; valor atual num label; for como número de amostras; firing como entrega; sucesso do promtool como aceitação de toda a plataforma.
Tópicos relacionados: Gestão de incidentes · SLIs e SLOs · Canary e rollback
Uma regra útil precisa de população correta, identidade estável, tempos ensaiados e uma cadeia de resposta comprovada no âmbito autorizado.
Referência: Alerting rules and states · Observability 2026-09; selected OpenTelemetry, Prometheus and Dynatrace Classic concepts