Azure
Configurare gli alert di Azure Monitor e gli action group
Una alert rule decide quando qualcosa non va. Un action group decide chi lo scopre. Separare queste due cose è il motivo per cui non finisci a modificare quaranta alert per cambiare un numero di telefono.
Tutto quello che ho fatto deploy su Azure finora, ho scoperto i problemi aprendolo e guardando. Funziona per un progetto di studio senza utenti. Ovviamente non funziona per niente di reale, ed è ciò che mi ha portato a questa parte dell'AZ-900.
Le due metà di un alert
La cosa che ha fatto click per me è che Azure divide l'alerting in due pezzi separati, e fanno lavori diversi.
Una alert rule è la condizione. Osserva una metrica o un log e decide quando qualcosa conta come sbagliato: CPU sopra l'80% per cinque minuti, risposte HTTP 5xx sopra un certo conteggio, una VM che ha smesso di rispondere.
Un action group è cosa succede dopo. È la lista di chi viene notificato e come: mandare un'email, mandare un SMS, chiamare un webhook, attivare una Logic App o una Function.
Tenerli separati sembrava un'indirezione inutile finché non ho pensato all'alternativa. Se i dettagli di notifica vivessero dentro ogni alert rule, cambiare chi viene avvisato significherebbe modificare ogni regola mai creata. Con gli action group, la lista dei contatti è definita una volta e referenziata da ogni regola che ne ha bisogno. Cambiala in un solo posto, ogni alert segue.
Su cosa puoi davvero fare alert
Due grandi fonti, e la differenza conta.
I metric alert girano su dati numerici che le resource emettono continuamente: percentuale CPU, memoria, conteggio di request, tempo di risposta, uso del disco. Si valutano velocemente e sono lo strumento giusto per "questa resource è sana adesso."
I log alert eseguono una query su log raccolti secondo una pianificazione. Più lenti, più flessibili, e lo strumento giusto per cose che una metrica non può esprimere, tipo "più di dieci tentativi di login falliti dallo stesso IP in cinque minuti."
Per il tipo di applicazioni che costruisco, quelli su metrica coprono la maggior parte di quello che vorrei. Il tempo di risposta che sale e il tasso di errore che sale sono i due segnali che mi dicono che qualcosa non va prima che me lo dica un utente.
Gli alert hanno una severity, e non è decorazione
Le alert rule ricevono una severity da 0 a 4, dove 0 è critico e 4 è verboso. Sembra metadato da riempire e ignorare.
Non lo è, perché è ciò che permette di instradare urgenze diverse verso action group diversi. Un alert severity 0 può far scattare un SMS alle 3 del mattino. Un severity 3 può mandare un'email che viene letta lunedì. Senza severity, tutto è ugualmente urgente, il che in pratica significa che niente lo è, perché le persone iniziano a ignorare il canale.
Il modo di fallire è troppi alert, non troppo pochi
Questa è stata la cosa più utile che ho tratto studiandolo, e non è un dettaglio tecnico.
Un alert che scatta di continuo viene ignorato. Una volta che un team impara che un particolare alert è di solito rumore, smette di leggerlo, e allora è peggio che non avere nessun alert, perché tutti credono che qualcosa venga osservato quando di fatto niente lo è.
Quindi la domanda utile quando crei un alert non è "mi piacerebbe saperlo." È "se questo scatta, c'è qualcosa che farei davvero?" Se la risposta onesta è no, l'alert è rumore travestito da etichetta di avviso. Una dashboard è il posto giusto per informazioni che vuoi poter controllare; un alert è per cose che richiedono che qualcuno agisca.
Cosa configurerei per i miei progetti
Per l'API che ho in esecuzione su Container Apps, tre alert coprirebbero i fallimenti realistici: tasso di errore in salita, tempo di risposta in salita, e l'app che fallisce il suo health check.
Tutto qui. Non CPU, non memoria, non la dozzina di altre metriche disponibili, perché non farei niente di diverso in base ad esse. Se la CPU è alta e niente è lento e niente sta fallendo, allora niente sta davvero andando storto.
Cosa non ho ancora fatto
Ho studiato questo piuttosto che farlo girare. Configurare alert su un'applicazione viva e poi conviverci per un po' è un'esperienza diversa dal capire i concetti, e mi aspetterei che sia lì che imparerei quali dovrebbero davvero essere le mie soglie. Scegliere un numero per "il tempo di risposta è troppo alto" senza traffico reale con cui confrontarlo è un'ipotesi, e l'unico modo per sistemarla è ipotizzare, osservare, e aggiustare.