Três da manhã, um alerta e nenhuma pista
Quando um alerta disparava de madrugada, o plantonista recebia uma mensagem com o nome da regra e mais nada. Para investigar, precisava descobrir sozinho qual dashboard abrir, qual painel olhar e se alguém tinha feito deploy naquela hora.
Fiz uma auditoria nos seis ambientes de produção e contei 871 regras de alerta ativas. Só 40 delas, 4,6%, levavam a algum painel. E quando abri esses poucos vínculos, a maioria estava errada. Apontavam para painéis do tipo gauge, que mostram o valor do instante sem a curva e sem marcação de eventos. Num caso, o alerta de disco do banco levava ao painel de tamanho da base de dados, que é outra grandeza. Quem clicasse ia investigar o número errado, e com confiança.
Nenhum produto tinha uma visão RED dos serviços (taxa, erros e duração), e nenhum Grafana mostrava quando um deploy tinha acontecido.
Cada alerta aponta para a própria condição
Mapeei regra por regra pela métrica que ela avalia, e não pelo nome do painel. Criei os painéis de série temporal que faltavam e um dashboard completo para o armazenamento de objetos, com 18 painéis de saúde, capacidade, tráfego e latência. Liguei cada regra ao painel exato e repeti o link na descrição do alerta, porque é a descrição que aparece na mensagem do plantonista.
Para que isso não se desfizesse com o tempo, tratei a numeração dos painéis como um contrato, de modo que editar um dashboard não quebre links já publicados, e escrevi um script que valida se todo link de alerta aponta para um painel que existe. As regras foram para o Git e passaram pelo promtool antes de aplicar.
RED, rápido
Construí dashboards RED em quatro produtos. Onde havia instrumentação de aplicação, usei o SigNoz, a partir de traces. Onde só existia a visão da borda, usei as métricas do ingress-nginx no Prometheus.
O histograma bruto de latência do ingress tinha 238.800 séries, e o Prometheus recusava a consulta numa janela de seis horas. Criei recording rules que pré-agregam por serviço e chegam a 228 séries. As 12 consultas do dashboard passaram a responder em 0,05 segundo.
Em cada painel escrevi uma descrição do que ele mede e de como ler o número, pensando em quem não é especialista. Já na primeira leitura os dashboards mostraram coisas que ninguém via, como um serviço com quase metade das respostas em erro 5xx. Num produto, também montei o painel de filas e conferi as métricas com os offsets reais do broker: 1% de diferença.
A linha vertical do deploy
A primeira pergunta de qualquer incidente é "mudou alguma coisa?". Configurei o ArgoCD Notifications para publicar cada deploy como anotação no Grafana, e todo gráfico passou a mostrar uma linha vertical no momento em que uma versão subiu.
Duas armadilhas apareceram antes de aplicar, e medi as duas. O token do Grafana precisava ficar num Secret fora do release do Helm, porque um helm upgrade reescreveria o Secret e apagaria o token sem nenhum erro. E, em aplicações com várias fontes, o campo de revisão do exemplo oficial vinha vazio, o que faria a notificação disparar uma vez e nunca mais. Usei a data de conclusão do deploy como chave. A carga retroativa publicou os deploys antigos no horário exato, conferido ao segundo.
O que mudou
Os alertas passaram a levar o plantonista direto ao gráfico da condição que disparou, como 39 de 39 regras num ambiente e 12 de 12 em outro, com os links validados por script. Os produtos ganharam visão RED por serviço, rápida mesmo em janelas longas, e os gráficos passaram a mostrar quando houve deploy.
O que eu levo disso
Um dashboard só ajuda se responde a pergunta que o alerta fez. Ligar o alerta ao painel "mais parecido" é pior do que não ligar, porque leva a pessoa ao número errado. E um bom painel ensina: a descrição de cada gráfico é documentação para quem está de plantão às três da manhã.