Procedure ottimali per gli allarmi
Leggi le best practice per gli allarmi.
Crea un set di allarmi per ogni metrica
Per ogni metrica emessa dalle risorse, creare allarmi che definiscono i seguenti comportamenti delle risorse:
- A rischio. La risorsa rischia di diventare inutilizzabile, come indicato dai valori delle metriche.
- Non ottimale. Le prestazioni della risorsa sono a livelli non ottimali, come indicato dai valori della metrica.
- La risorsa è attiva o inattiva. La risorsa non è raggiungibile o non è operativa.
Negli esempi riportati di seguito viene utilizzata 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 nell'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 soglia di rischio tipica 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 utilizzano un'alta percentuale della CPU.
In questo esempio, si decide di informare immediatamente il team operativo, impostando la severità dell'allarme su "Critico" perché è necessaria la riparazione per riportare le istanze a livelli operativi ottimali. È possibile configurare le notifiche di allarme per il team responsabile sia tramite PagerDuty che tramite e-mail, richiedendo un'indagine e le correzioni appropriate prima che le istanze diventino inutilizzabili. Le notifiche ripetute vengono impostate ogni minuto. Quando un utente risponde alle notifiche di allarme, le notifiche vengono temporaneamente arrestate utilizzando la procedura consigliata per eliminare l'allarme . Quando le metriche tornano a valori ottimali, la soppressione viene rimossa.
NonOptimal Esempio
Una soglia standard non ottimale per la metrica CpuUtilization è compresa tra il 60 e l'80%. Quando i valori della metrica per un'istanza di computazione si trovano in questo intervallo, l'istanza supera l'intervallo operativo ottimale.
In questo esempio, si decide di notificare alla persona o al team appropriato che un'applicazione o un processo utilizza più CPU del solito. È possibile configurare un allarme soglia per notificare i contatti appropriati, impostando la severità dell'allarme come "Avvertenza", poiché non sono necessarie azioni immediate per indagare e ridurre la CPU. È possibile impostare la notifica solo per e-mail, indirizzata allo sviluppatore o al team appropriato, con notifiche ripetute ogni 24 ore per ridurre il rumore della notifica e-mail.
Esempio di risorsa attiva o inattiva
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 non essere più disponibile a causa di problemi di connettività.
In questo esempio, si decide di inviare una notifica immediata al team operativo, impostando la severità dell'allarme assenza come "Critico" poiché è necessaria la riparazione per mettere in linea le istanze. È possibile configurare le notifiche di allarme per il team responsabile sia tramite PagerDuty che tramite e-mail, richiedendo un'indagine e uno spostamento dei carichi di lavoro in un'altra risorsa disponibile. Le notifiche ripetute vengono impostate ogni minuto. Quando un utente risponde alle notifiche di allarme, le notifiche vengono temporaneamente arrestate utilizzando la procedura consigliata per eliminare l'allarme. Quando la metrica CpuUtilization viene nuovamente rilevata dalla risorsa, l'eliminazione viene rimossa.
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 Come ottenere notifiche basate su eventi per un allarme.
Selezionare l'intervallo di allarme corretto per la metrica
Selezionare un intervallo di allarme in base alla frequenza di emissione della metrica. 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 indagini
Quando un membro del team risponde a un allarme, eliminare le notifiche di durante il tentativo di analizzare o mitigare il problema. L'arresto temporaneo delle notifiche aiuta a evitare distrazioni durante l'indagine 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 di routine gli allarmi
Su base regolare, ad esempio settimanale, rivedere gli allarmi per garantire una configurazione ottimale. Calibrare i dettagli relativi a soglia, severità e notifica di ogni allarme, inclusi metodo, frequenza e audience target.
La configurazione ottimale degli allarmi risponde ai seguenti fattori:
- Criticità della risorsa.
- Funzionamento appropriato delle risorse. Valuta il comportamento singolarmente e nel contesto 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 | Frequenza | Audience mirata |
|---|---|---|---|---|
| >80% | Critici | PagerDuty + E-mail | 1 minuti | Computazione, operazioni e comunicazioni con i clienti |
| >60% e <80% | Avvertenza | Posta elettronica | Una volta al giorno | Computazione + operazioni |
Per istruzioni, vedere Aggiornamento di un allarme.