Best practice per gli allarmi
Scopri le best practice per gli allarmi.
Creare un set di allarmi per ogni metrica
Per ogni metrica emessa dalle risorse, creare allarmi che definiscono i comportamenti delle risorse riportati di seguito.
- a rischio. La risorsa rischia di diventare inutilizzabile, come indicato dai valori delle metriche.
- Non ottimale. La risorsa esegue prestazioni a livelli non ottimali, come indicato dai valori delle metriche.
- La risorsa è attiva o inattiva. La risorsa non è raggiungibile oppure non è operativa.
Gli esempi riportati di seguito utilizzano la metrica CpuUtilization emessa dallo spazio di nomi della metrica oci_computeagent. Questa metrica monitora l'utilizzo dell'istanza di computazione e il livello di attività di qualsiasi servizio e applicazione in esecuzione sull'istanza. CpuUtilization è una metrica delle prestazioni chiave per un servizio cloud perché indica l'uso della CPU per l'istanza di computazione e può essere utilizzata per analizzare i problemi relativi alle prestazioni. Per ulteriori informazioni sull'uso della CPU, vedere il seguente URL: https://en.wikipedia.org/wiki/CPU_time.
Esempio a rischio
Una tipica soglia di rischio per la metrica CpuUtilization è qualsiasi valore maggiore dell'80%. Un'istanza di computazione che supera questa soglia rischia di diventare inutilizzabile. Spesso la causa di questo comportamento è una o più applicazioni che consumano un'alta percentuale della CPU.
In questo esempio, si decide di avvisare immediatamente il team operativo, impostando la severità dell'allarme come "critica" perché è necessaria una riparazione per riportare le istanze a livelli operativi ottimali. È possibile configurare le notifiche di allarme al team responsabile sia tramite PagerDuty che tramite posta elettronica, richiedendo un'indagine e le correzioni appropriate prima che le istanze diventino inutilizzabili. Le notifiche di ripetizione vengono impostate ogni minuto. Quando un utente risponde alle notifiche di allarme, è possibile interrompere temporaneamente le notifiche utilizzando la procedura consigliata di soppressione dell'allarme. Quando le metriche tornano ai valori ottimali, si rimuove l'eliminazione.
Esempio NonOptimal
Una soglia non ottimale tipica per la metrica CpuUtilization è compresa tra il 60 e l'80%. Quando i valori della metrica per un'istanza di computazione rientrano in questo intervallo, l'istanza supera l'intervallo operativo ottimale.
In questo esempio, si decide di notificare all'individuo o al team appropriato che un'applicazione o un processo sta consumando più CPU del solito. È possibile configurare un allarme soglia per inviare una notifica ai contatti appropriati, impostando la severità dell'allarme come "Avvertenza", in quanto non sono necessarie azioni immediate per analizzare e ridurre la CPU. La notifica viene impostata solo via e-mail, indirizzata allo sviluppatore o al team appropriato, con notifiche ripetute ogni 24 ore per ridurre il rumore delle notifiche e-mail.
Esempio di risorsa attiva o non attiva
Un indicatore tipico della disponibilità delle risorse è l'assenza di cinque minuti della metrica CpuUtilization. Un'istanza di computazione che supera questa soglia non è raggiungibile o non è operativa. La risorsa potrebbe aver smesso di rispondere o potrebbe non essere più disponibile a causa di problemi di connettività.
In questo esempio, si decide di notificare immediatamente al team operativo, impostando la severità dell'allarme di assenza come "critica" perché è necessaria una riparazione per connettere le istanze. È possibile configurare le notifiche di allarme per il team responsabile tramite PagerDuty e posta elettronica, richiedendo un'indagine e uno spostamento dei carichi di lavoro in un'altra risorsa disponibile. Le notifiche di ripetizione vengono impostate ogni minuto. Quando un utente risponde alle notifiche di allarme, si interrompe temporaneamente le notifiche utilizzando la procedura consigliata di soppressione dell'allarme. Quando la metrica CpuUtilization viene nuovamente rilevata dalla risorsa, si rimuove l'eliminazione.
A volte si desidera ricevere una notifica ogni volta che si verifica un evento, ad esempio la chiusura di un'istanza di database. In questo scenario, impostare le notifiche ripetute su zero minuti per creare un allarme basato su eventi. Per istruzioni, vedere Ottenere notifiche basate su eventi per un allarme.
Selezionare l'intervallo di allarme corretto per la metrica
Selezionare un intervallo di allarme basato sulla frequenza alla quale la metrica viene emessa. Ad esempio, una metrica emessa ogni cinque minuti richiede un intervallo di allarme di 5 minuti o superiore. La maggior parte delle metriche viene emessa ogni minuto, il che significa che la maggior parte delle metriche supporta qualsiasi intervallo di allarme. Per determinare intervalli di allarme validi per una metrica specifica, controllare il riferimento alla metrica del servizio pertinente.
Elimina allarmi durante le indagini
Quando un membro del team risponde a un allarme, eliminare le notifiche durante l'impegno di analizzare o limitare il problema. L'arresto temporaneo delle notifiche consente di evitare distrazioni durante le indagini e la mitigazione. Rimuovere l'eliminazione quando il problema è stato risolto. Per istruzioni, vedere Soppressione di un singolo allarme e Soppressione di più allarmi.
Regolare regolarmente gli allarmi
Su base regolare, ad esempio settimanale, controllare gli allarmi per garantire una configurazione ottimale. Calibrare la soglia, la severità e i dettagli di notifica di ciascun allarme, inclusi il metodo, la frequenza e l'audience target.
La configurazione ottimale degli allarmi risponde ai seguenti fattori:
- Criticità della risorsa.
- Funzionamento appropriato delle risorse. Valuta il comportamento singolarmente e all'interno del context dell'ecosistema dei servizi. Rivedere le fluttuazioni dei valori delle metriche per un periodo di tempo specifico, quindi adeguare le soglie in base alle esigenze.
- rumore di notifica accettabile. Valutare il metodo di notifica (ad esempio, e-mail o PagerDuty), i destinatari appropriati e la frequenza delle notifiche ripetute.
La tabella seguente mostra un esempio di calibrazione dell'allarme.
| % CPU soglia | Severità | Metodo di notifica | la frequenza | Destinatari |
|---|---|---|---|---|
| >80% | Critico | PagerDuty + Email | 1 minuto | Compute, Ops e comunicazioni con i clienti |
| >60% e <80% | Avvertenza | Una volta al giorni | Computazione e operazioni |
Per istruzioni, vedere Aggiornamento di un allarme.