Meilleures pratiques pour les alarmes

Pour chaque mesure émise par les ressources, créez des alertes définissant les comportements de ressource suivants :

• Présentant un risque. La ressource risque de devenir inutilisable, comme indiqué par les valeurs de mesure.
• Non optimal. La ressource présente des niveaux de performances non optimaux, comme indiqué par les valeurs de mesure.
• La ressource est 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 mesure oci_computeagent. Cette mesure surveille l'utilisation de l'instance de calcul ainsi que le niveau d'activité de l'ensemble des services et des applications exécutés sur l'instance. CpuUtilization est une mesure clé de performance pour un service cloud car elle indique l'utilisation de l'UC pour l'instance de calcul et peut être utilisée pour examiner les problèmes de performances. Pour plus d'informations sur l'utilisation de l'UC, accédez à l'URL suivante : https://en.wikipedia.org/wiki/CPU_time.

Exemple d'at-risque

Le seuil de risque standard pour la mesure CpuUtilization concerne toutes les valeurs supérieures à 80 %. Une instance de calcul qui dépasse ce seuil risque de devenir inutilisable. Le plus souvent, ce comportement est causé par des applications consommant un pourcentage élevé d'UC.

Dans cet exemple, vous décidez d'avertir immédiatement l'équipe des opérations, en définissant la gravité de l'alarme sur Critique, car une réparation est nécessaire pour ramener les instances à des niveaux opérationnels optimaux. Vous configurez des notifications d'alarme pour l'équipe concernée via PagerDuty et par courriel, afin de demander un examen et des correctifs appropriés avant que les instances deviennent inutilisables. Vous définissez les notifications de sorte qu'elles se répètent toutes les minutes. Lorsqu'une personne répond aux notifications d'alarme, vous arrêtez temporairement les notifications, conformément aux meilleures pratiques de suppression de l'alarme . Lorsque les valeurs des mesures redeviennent optimales, enlevez la suppression.

Exemple NonOptimal

Le seuil non optimal standard pour la mesure CpuUtilization est compris entre 60 % et 80 %. Lorsque les valeurs de mesure d'une instance de calcul appartiennent à cette plage, l'instance dépasse la plage opérationnelle optimale.

Dans le cadre de cet exemple, vous décidez d'avertir la personne ou l'équipe concernée qu'une application ou un processus consomme plus d'UC que d'habitude. Vous configurez une alarme de seuil pour avertir les contacts appropriés, en définissant la gravité de l'alarme sur Avertissement, car aucune action immédiate n'est requise pour examiner et réduire l'utilisation de l'UC. Vous définissez une notification par courriel uniquement, destinée à l'équipe ou au développeur concerné, avec répétition des notifications toutes les 24 heures afin de réduire le bruit des notifications par courriel.

Exemple de ressource active ou inactive

L'un des indicateurs classiques de disponibilité des ressources est une absence de cinq minutes de la mesure CpuUtilization. Une instance de calcul qui dépasse ce seuil est inaccessible ou ne fonctionne pas. La réponse de la ressource est peut-être arrêtée ou elle est peut-être devenue indisponible en raison de problèmes de connectivité.

Dans cet exemple, vous décidez d'avertir immédiatement l'équipe des opérations, en définissant la gravité de l'alarme d'absence sur Critique, car une réparation est nécessaire pour ramener les instances en ligne. Vous configurez des notifications d'alarme pour l'équipe concernée via PagerDuty et par courriel, afin de demander un examen et le transfert des charges globale vers une autre ressource disponible. Vous définissez les notifications de sorte qu'elles se répètent toutes les minutes. Lorsqu'une personne répond aux notifications d'alarme, vous arrêtez temporairement les notifications, conformément aux meilleures pratiques de suppression de l'alarme. Lorsque la mesure CpuUtilization est de nouveau détectée pour la ressource, enlevez la suppression.

Sélectionnez un intervalle d'alarme en fonction de la fréquence d'émission de la mesure. 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 chaque minute, ce qui signifie que la plupart des mesures prennent en charge tout intervalle d'alarme. Afin de déterminer des intervalles d'alarme valides pour une mesure spécifique, reportez-vous à la référence de mesure du service approprié.

When a team member responds to an alarm, suppress  notifications during the effort to investigate or mitigate the issue. L'arrêt temporaire des notifications permet d'éviter les distractions pendant l'examen et l'atténuation. Enlevez la suppression une fois le problème résolu. Pour obtenir des instructions, reportez-vous aux rubriques Ajout d'une suppression d'alarme spécifique à une dimension et Ajout d'une suppression à l'échelle d'une alarme.

Vérifiez régulièrement vos alarmes pour assurer une configuration optimale (par exemple, toutes les semaines). Etalonnez les détails de seuil, de gravité et de notification de chaque alarme, y compris la méthode, la fréquence et les personnes ciblées.

La configuration optimale des alarmes prend en compte les facteurs suivants :

• Niveau d'importance de la ressource.
• Comportement approprié des ressources. Evaluez le comportement individuellement et dans le contexte de l'écosystème du service. Vérifiez les fluctuations des valeurs de mesure sur une période spécifique, puis ajustez les seuils selon les besoins.
• Bruit de notification acceptable. Evaluez la méthode de notification (par exemple, courriel ou PagerDuty), les destinataires appropriés et la fréquence de répétition des notifications.

Le tableau suivant présente un exemple d'ajustement d'une alarme.

Pour obtenir des instructions, reportez-vous à Mise à jour d'une alarme.