Meilleures pratiques pour les alarmes
Découvrez les meilleures pratiques pour les alarmes.
Créer un jeu d'alarmes pour chaque mesure
Pour chaque mesure émise par des ressources, créez des alarmes qui définissent les comportements suivants des ressources :
- À risque. La ressource risque de devenir inutilisable, comme indiqué par les valeurs de mesure.
- Non optimal. Le fonctionnement de la ressource n'est pas optimal, comme indiqué par les valeurs de mesure.
- Ressource active ou inactive. La ressource est inaccessible ou ne fonctionne pas.
Les exemples suivants utilisent la mesure CpuUtilization émise par l'espace de noms de mesures oci_computeagent. Cette mesure surveille l'utilisation de l'instance de calcul et le niveau d'activité de tous les services et applications exécutés sur l'instance. CpuUtilization est une mesure de performance clé pour un service cloud service, car elle indique l'utilisation d'UC pour l'instance de calcul et peut être utilisée pour examiner les problèmes de performance. Pour en savoir plus sur l'utilisation de l'unité centrale, voir l'URL suivante : https://en.wikipedia.org/wiki/CPU_time.
Exemple de statut à risque
Un seuil classique pour le type À risque est une valeur CpuUtilization supérieure à 80 %. Une instance de calcul dépassant ce seuil risque de devenir inutilisable. Cette situation est souvent due au fait qu'au moins une application consomme un pourcentage élevé de l'unité centrale.
Dans cet exemple, vous décidez d'aviser immédiatement l'équipe des opérations, en réglant la gravité de l'alarme à "Critique", car une réparation est requise pour ramener les instances à un niveau de fonctionnement optimal. Vous configurez des avis d'alarmepour l'équipe responsable à la fois par PagerDuty et par courriel, en demandant un examen et l'application des correctifs appropriés avant que les instances ne deviennent inutilisables. Vous définissez des avis renvoyés toutes les minutes. Lorsqu'une personne répond aux avis d'alarme, vous arrêtez temporairement les avis en utilisant la meilleure pratique consistant à suspendre l'alarme. Lorsque les mesures reviennent à des valeurs optimales, vous supprimez la suspension.
Exemple NonOptimal
Un seuil standard non optimal pour la mesure CpuUtilization est compris entre 60 et 80 %. Lorsque les valeurs de mesure d'une instance de calcul sont comprises dans cet intervalle, l'instance dépasse l'intervalle opérationnel optimal.
Dans cet exemple, vous décidez d'aviser la personne ou l'équipe appropriée qu'une application ou un processus consomme plus d'unité centrale que d'habitude. Vous configurez une alarme avec seuil pour aviser les contacts appropriés, en réglant la gravité de l'alarme à " Avertissement ", car aucune action immédiate n'est requise pour examiner et réduire la consommation d'UC. Vous envoyez l'avis par courriel uniquement au développeur ou à l'équipe qui convient, avec des avis renvoyés toutes les 24 heures pour limiter les distractions causées par les courriels.
Exemple de ressource active ou inactive
Un indicateur typique de la disponibilité des ressources est une absence de cinq minutes de la mesure CpuUtilization. Si une instance de calcul dépasse ce seuil, cela signifie qu'elle est inaccessible ou ne fonctionne pas. La ressource a peut-être cessé de répondre ou elle est peut-être désactivée en raison de problèmes de connectivité.
Dans cet exemple, vous décidez d'aviser immédiatement l'équipe des opérations, en réglant la gravité de l'alarme d'absence à "Critique", car une réparation est requise pour mettre les instances en ligne. Vous configurez les avis d'alarme pour l'équipe responsable à la fois par PagerDuty et par courriel, en demandant un examen et le déplacement des charges de travail vers une autre ressource disponible. Vous définissez des avis renvoyés toutes les minutes. Lorsqu'une personne répond aux avis d'alarme, vous arrêtez temporairement les avis en utilisant la meilleure pratique consistant à suspendre l'alarme. Lorsque la mesure CpuUtilization est à nouveau détectée pour la ressource, vous retirez la suspension.
Parfois, vous souhaitez être avisé lorsqu'un événement se produit, par exemple l'arrêt d'une instance de base de données. Dans ce scénario, réglez les avis de répétition à zéro minute pour créer une alarme basée sur un événement. Pour obtenir des instructions, voir Obtention d'avis basés sur des événements pour une alarme.
Sélectionner l'intervalle d'alarme correct pour votre mesure
Sélectionnez un intervalle d'alarme en fonction de la fréquence à laquelle la mesure est émise. Par exemple, une mesure émise toutes les cinq minutes nécessite un intervalle d'alarme de 5 minutes ou plus. La plupart des mesures sont émises toutes les minutes, ce qui signifie que la plupart des mesures prennent en charge tout intervalle d'alarme. Pour déterminer les intervalles d'alarme valides pour une mesure spécifique, consultez les informations de référence sur les mesures du service concerné.
Suspendre les alarmes lors des examens
Lorsqu'un membre de l'équipe répond à une alarme, vous suspendez les avis pendant l'examen ou pendant l'effort visant à atténuer le problème. L'arrêt temporaire des avis permet de limiter les distractions pendant les phases d'examen et de correction du problème. Supprimez la suspension une fois le problème résolu. Pour des instructions, voir Suspension d'une seule alarme et Suspension de plusieurs alarmes.
Régler régulièrement les alarmes
Vérifiez les alarmes régulièrement, par exemple toutes les semaines, pour garantir une configuration optimale. Ajustez le seuil, la gravité et les détails des avis de chaque alarme, notamment la méthode, la fréquence et le public ciblé.
La configuration optimale des alarmes tient compte des facteurs suivants :
- Criticité de la ressource.
- Comportement approprié de la ressource. Évaluez le comportement séparément et dans le contexte de l'écosystème du service. Vérifiez les fluctuations des valeurs de mesure pour une période spécifique, puis ajustez les seuils selon les besoins.
- Niveau de distractions acceptable pour les avis. Évaluez la méthode d'avis (par exemple, courriel ou PagerDuty), les destinataires appropriés et la fréquence des avis renvoyés.
Le tableau suivant présente un exemple d'ajustement d'alarme.
| Seuil d'UC (%) | Gravité | Méthode d'avis | Fréquence | Public ciblé |
|---|---|---|---|---|
| > 80 % | Critique | PagerDuty + Courriel | 1 minute | Calcul, Ops et Communications des clients |
| > 60 % et > 80 % | Avertissement | Courriel | Une fois par jour | Calcul + Ops |
Pour des instructions, voir Mise à jour d'une alarme.