In Azure ogni segnale operativo utile per il monitoraggio nasce in Azure Monitor, il piano di raccolta unificato per metriche, log e attività della piattaforma. Un alert trasforma quel segnale in un’azione automatica seguendo sempre la stessa catena logica: signal → condition → action. Capire dove agisce ciascun tipo di alert, con quale latenza e con quale action group, è il cuore di questa competenza.

Signal, condition e severity

Il signal è la sorgente da valutare (una metrica, una query sui log, un evento di piattaforma). La condition definisce soglia e logica (Percentage CPU > 80), più i parametri temporali. La action collega uno o più action group che notificano o rimediano.

Ogni alert porta una severity da Sev0 a Sev4:

  • Sev0 – Critical, Sev1 – Error, Sev2 – Warning, Sev3 – Informational, Sev4 – Verbose.

La severity non cambia il comportamento tecnico: serve a instradare e prioritizzare in ITSM e nei runbook operativi. Un buon design assegna Sev0/Sev1 solo a ciò che richiede intervento immediato.

I tre tipi di alert

Metric alert

Valuta una metrica di piattaforma (o custom) a intervalli regolari, quasi in tempo reale. Ha due parametri chiave: aggregation granularity (window size), cioè l’intervallo su cui si aggrega il valore, e evaluation frequency, cioè ogni quanto si rivaluta la condizione. Supporta dynamic thresholds (soglie apprese via machine learning) e multi-resource alert su più VM omogenee. È la scelta giusta quando serve reattività bassa latenza: CPU, memoria, IOPS, latenza HTTP.

Log alert

Esegue a intervalli una query KQL su un Log Analytics workspace (o su Application Insights). Permette logica complessa e correlazioni impossibili con le metriche pure (es. contare errori 5xx per host). Il prezzo è la latenza maggiore: c’è il tempo di ingestion dei log più l’intervallo di valutazione, quindi un log alert può notificare minuti dopo l’evento reale. Da preferire quando la condizione richiede aggregazioni o join su dati testuali.

Activity log alert

Reagisce a eventi del control plane registrati nell’Activity Log: creazione/eliminazione di risorse, operazioni RBAC, Service Health e Resource Health. Non guarda le performance ma la governance (“qualcuno ha eliminato una NSG”, “manutenzione pianificata in region”). È lo strumento corretto per audit e per allertare su health della piattaforma, non su carico.

Action group

L’action group è l’unità riutilizzabile che definisce chi e come viene notificato. Un singolo action group può contenere più action di tipo diverso:

  • Email, SMS, Azure App push, voice — notifiche verso persone.
  • Webhook (incl. secure webhook con Entra ID) — integrazione con servizi esterni.
  • Azure Function, Logic App, Automation Runbook — auto-remediation.
  • ITSM connector — creazione ticket verso ServiceNow e simili.

Un action group è condivisibile fra molti alert, il che centralizza la gestione dei destinatari. Attenzione al rate limiting (es. SMS/voce hanno limiti di frequenza) e alle notification preferences per il canale.

Alert processing rule

Le alert processing rule (ex “action rule”) agiscono dopo la generazione dell’alert e servono a due scopi:

  • Suppression: silenziare le notifiche durante finestre di manutenzione pianificata, così gli alert continuano a nascere ma non generano rumore.
  • Apply/override action group: aggiungere o sostituire l’action group su un insieme di alert filtrati per scope, resource type o severity, senza toccare i singoli alert.

Sono lo strumento corretto per gestire manutenzioni ricorrenti e per applicare un action group in modo trasversale.

Trappole tipiche d’esame

  • Scenario: un alert non scatta abbastanza in fretta durante un picco di CPU → la soluzione è un metric alert con evaluation frequency e window size ridotti; un log alert avrebbe latenza troppo alta per un segnale near-real-time.
  • Scenario: le notifiche non arrivano ma nel portale gli alert risultano “fired” → il problema è l’action group (destinatario errato, canale non confermato, o alert senza action group associato), non la condition.
  • Scenario: devono essere allertati su una VM eliminata o su un evento di Service Health → serve un activity log alert, non un metric o log alert.
  • Scenario: durante una manutenzione notturna si vogliono evitare notifiche ma mantenere gli alert → configurare una alert processing rule di suppression con finestra temporale, non disabilitare gli alert.
  • Scenario: soglia fissa inadatta a un carico che varia per fascia oraria → usare un metric alert con dynamic thresholds invece di un valore statico.