Allarmi e incidenti

Il motore di allarmi lavora sui dati correlati. Questo cambia il tipo di allarme che può generare: non solo “questa metrica ha superato questa soglia”, ma anche condizioni che coinvolgono più oggetti e le loro relazioni.

Da dove nasce un allarme

Origine	Esempio
Soglia su metrica	CPU dell’host oltre il 90% per 15 minuti
Evento della sorgente	Un allarme di Prism Central, un failure di Citrix
Probe attiva	Una verifica dell’Infra Agent che fallisce
Stato di un oggetto	Un servizio fermo, un certificato in scadenza, un job di backup fallito
Assenza	Una piattaforma che ha smesso di riportare, un agent silente
Condizione correlata	Una VM critica su un datastore con meno del 10% libero

L’ultima categoria è quella che giustifica la correlazione: nessuna delle due metriche isolate meriterebbe un allarme, ma la loro combinazione sì.

L’assenza di dati merita una nota: un sistema che smette di riportare non genera allarmi, e questo è il modo classico in cui un guasto passa inosservato. Corellix tratta il silenzio come una condizione, non come uno stato normale.

Incidenti

Un guasto genera raramente un solo allarme. Un host che va giù produce l’allarme dell’host, quelli di ogni VM che ci girava, quelli delle sessioni interrotte, quelli delle probe che non rispondono più.

Corellix aggrega gli allarmi correlati in incidenti: un incidente ha una causa, una finestra temporale, un insieme di oggetti coinvolti e un elenco di allarmi. Si lavora sull’incidente, non sui quaranta allarmi.

Le pagine sono Operatività → Allarmi per gli allarmi attivi e Operatività → Incidenti per gli incidenti.

Severità

Livello	Significato
Critico	Servizio compromesso o perdita di dati imminente. Richiede intervento immediato
Alto	Degrado significativo o ridondanza persa. Richiede intervento a breve
Medio	Anomalia da verificare, senza impatto immediato
Basso	Segnalazione informativa

La severità dipende dalla regola, e può essere alzata o abbassata in base al ruolo VM dell’oggetto coinvolto: lo stesso sintomo su un domain controller e su una macchina di collaudo non merita la stessa attenzione.

Notifiche

Da Sistema → Impostazioni → Notifiche: e-mail, Slack, Microsoft Teams, webhook, oppure apertura automatica di un ticket su ServiceNow o Jira.

I canali si assegnano per severità e per ambito. Ricevere tutto su un solo canale è il modo più efficace per non ricevere nulla: dopo due settimane nessuno legge più quel canale.

Finestre di manutenzione

Durante una finestra di manutenzione gli allarmi degli oggetti coinvolti vengono soppressi, non cancellati: restano visibili nella cronologia, ma non generano notifiche.

Si definiscono in Operatività → Finestre di manutenzione, una volta o ricorrenti, su singoli oggetti o su gruppi.

Configurare le regole

Da Operatività → Allarmi → Regole. Ogni regola definisce:

• Ambito — a quali oggetti si applica, per tipo, piattaforma, ruolo o tag.
• Condizione — metrica e soglia, evento, stato, o combinazione.
• Durata — per quanto la condizione deve persistere prima di generare l’allarme. È il parametro che elimina la maggior parte dei falsi positivi.
• Severità.
• Notifiche.

Sulle soglie predefinite

I valori predefiniti sono ragionevoli e generici. Nel vostro ambiente saranno sbagliati in almeno un paio di punti: c’è sempre un cluster che lavora stabilmente all’85% senza che nessuno se ne preoccupi, e un servizio per cui il 60% è già un problema.

Le prime due settimane servono a osservare che cosa è normale. Poi si tarano le soglie. Un motore di allarmi non tarato genera rumore, e il rumore fa perdere gli allarmi veri.

Analisi delle cause

Dal dettaglio di un allarme o di un incidente, Corell!A può proporre un’analisi delle cause: ricostruisce la catena di dipendenze, indica le cause più probabili e mostra su che cosa si basa.

Non sostituisce la diagnosi. Restringe il campo, che nella maggior parte dei casi è il lavoro più lungo.