Azure
Configurando alertas do Azure Monitor e action groups
Uma alert rule decide quando algo está errado. Um action group decide quem fica sabendo. Separar essas duas coisas é o motivo de você não acabar editando quarenta alertas para mudar um número de telefone.
Tudo que eu fiz deploy no Azure até agora, eu descobri sobre problemas abrindo e olhando. Isso funciona para um projeto de estudo sem usuários. Obviamente não funciona para nada de verdade, o que foi o que me levou para essa parte do AZ-900.
As duas metades de um alerta
A coisa que fez sentido para mim é que o Azure divide alerting em duas peças separadas, e elas fazem trabalhos diferentes.
Uma alert rule é a condição. Ela observa uma métrica ou um log e decide quando algo conta como errado: CPU acima de 80% por cinco minutos, respostas HTTP 5xx acima de uma certa contagem, uma VM que parou de responder.
Um action group é o que acontece depois. É a lista de quem é notificado e como: mandar um email, mandar um SMS, chamar um webhook, disparar um Logic App ou uma Function.
Manter eles separados parecia indireção desnecessária até eu pensar na alternativa. Se os detalhes de notificação vivessem dentro de cada alert rule, então mudar quem recebe o aviso significa editar toda regra que você já criou. Com action groups, a lista de contatos é definida uma vez e referenciada por toda regra que precisar dela. Mude num lugar só, todo alerta segue.
No que você de fato pode alertar
Duas fontes amplas, e a diferença importa.
Metric alerts rodam em cima de dados numéricos que os resources emitem continuamente: porcentagem de CPU, memória, contagem de requests, tempo de resposta, uso de disco. Eles avaliam rápido e são a ferramenta certa para "esse resource está saudável agora."
Log alerts rodam uma query contra logs coletados numa agenda. Mais lentos, mais flexíveis, e a ferramenta certa para coisas que uma métrica não consegue expressar, tipo "mais de dez tentativas de login falhas do mesmo IP em cinco minutos."
Para o tipo de aplicações que eu construo, os de métrica cobrem a maior parte do que eu ia querer. Tempo de resposta subindo e taxa de erro subindo são os dois sinais que me dizem que algo está errado antes de um usuário me dizer.
Alertas têm severity, e não é decoração
Alert rules recebem uma severity de 0 a 4, onde 0 é crítico e 4 é verbose. Parece metadado que você preenche e ignora.
Não é, porque é o que permite rotear urgências diferentes para action groups diferentes. Um alerta severity 0 pode disparar SMS às 3 da manhã. Um severity 3 pode mandar um email que é lido na segunda. Sem severities, tudo é igualmente urgente, o que na prática significa que nada é, porque as pessoas começam a ignorar o canal.
O modo de falha é alertas demais, não de menos
Essa foi a coisa mais útil que tirei estudando isso, e não é um detalhe técnico.
Um alerta que dispara o tempo todo é ignorado. Assim que um time aprende que um alerta específico geralmente é ruído, param de ler, e aí é pior do que não ter alerta nenhum, porque todo mundo acredita que algo está sendo observado quando efetivamente nada está.
Então a pergunta útil ao criar um alerta não é "eu gostaria de saber sobre isso." É "se isso disparar, existe algo que eu de fato faria?" Se a resposta honesta é não, o alerta é ruído usando uma etiqueta de aviso. Um dashboard é o lugar certo para informação que você quer poder checar; um alerta é para coisas que precisam que alguém aja.
O que eu configuraria para meus próprios projetos
Para a API que tenho rodando no Container Apps, três alertas cobririam as falhas realistas: taxa de erro subindo, tempo de resposta subindo, e a aplicação falhando no health check.
Só isso. Não CPU, não memória, não a dúzia de outras métricas disponíveis, porque eu não faria nada diferente baseado nelas. Se a CPU está alta e nada está lento e nada está falhando, então nada está de fato errado.
O que eu ainda não fiz
Eu estudei isso em vez de rodar. Configurar alertas numa aplicação viva e depois viver com eles por um tempo é uma experiência diferente de entender os conceitos, e eu esperaria que fosse aí que eu aprenderia quais deveriam ser de fato meus thresholds. Escolher um número para "tempo de resposta está alto demais" sem tráfego real para comparar é um palpite, e a única forma de consertar isso é palpitar, observar, e ajustar.