Dépannage des alarmes
Utilisez les informations de dépannage pour identifier et résoudre les problèmes courants qui peuvent survenir lors de l'utilisation d'alarmes dans Monitoring.
Avant de résoudre les problèmes, assurez-vous de bien comprendre comment les alarmes sont évaluées. Reportez-vous à Illustration of Alarm Evaluation.
L'alarme ne tire pas
L'alarme remplissait les conditions pour tirer, mais elle n'a pas tiré. Par exemple, une instance de calcul a été arrêtée.
Cause : délai de déclenchement long
L'expression d'alarme n'a pas été évaluée comme vraie pendant des minutes consécutives pendant la période de délai de déclenchement.
L'image suivante du graphique de mesures d'une alarme comprend une zone ombrée pour indiquer la période de délai de déclenchement. Dans cet exemple, le récapitulatif d'alarme affiché sur la page de détails de l'alarme est Alarm fires when the Mean of CpuUtilization is greater than the threshold value of 80, with a trigger delay of 10 minutes. Le délai de déclenchement commence à 1h30 (lorsque le seuil est dépassé) et se termine à 1h40. L'expression d'alarme est évaluée à 1:30, puis à 1:32. Cette véritable évaluation ne se poursuit pas pendant la période complète de délai de déclenchement de dix minutes, de sorte que l'alarme ne se déclenche pas.
Pour visualiser le graphique de mesures d'une alarme, obtenez son historique.
Pour plus d'informations sur l'évaluation des alarmes, reportez-vous à Illustration de l'évaluation des alarmes.
Remède : raccourcir le délai de déclenchement
Si le délai de déclenchement est trop long et que vous souhaitez que l'alarme se déclenche immédiatement après avoir dépassé le seuil, mettez à jour l'alarme pour utiliser un délai de déclenchement plus court. Par exemple, définissez le délai de déclenchement sur une minute. Reportez-vous à Définition du délai de déclenchement pour une alarme et à Référence MQL (Monitoring Query Language).
Cause : l'intervalle est plus court que la fréquence d'émission
L'expression d'alarme a été évaluée comme vraie, provoquant le déclenchement de l'alarme, mais à l'intervalle suivant, même si le dernier point de données a dépassé le seuil, l'alarme a été effacée. L'alarme a été effacée car l'intervalle est plus court que la fréquence d'émission pour la mesure sélectionnée.
L'image suivante du graphique de mesures d'une alarme affiche les points de données horaires de la mesure sélectionnée, StoredBytes, à partir de l'espace de noms de mesure oci_object_storage. La requête d'alarme est StoredBytes[1m].sum() > 800000000, ce qui indique un intervalle d'une minute. Cet intervalle est plus court que la fréquence d'émission de la mesure, qui est d'une heure. (La fréquence est documentée dans Mesures d'Object Storage.)
Dans cet exemple, l'alarme se déclenche à 3:00 et s'efface à 3:01. Si l'intervalle avait été défini sur une heure, l'expression d'alarme continuerait à prendre la valeur True et l'alarme continuerait à se déclencher jusqu'à 4h00.
Pour visualiser le graphique de mesures d'une alarme, obtenez son historique.
Pour plus d'informations sur l'évaluation des alarmes, reportez-vous à Illustration de l'évaluation des alarmes.
Solution : augmenter l'intervalle
Si vous voulez que l'alarme se déclenche, mettez à jour l'intervalle d'alarme pour qu'il soit identique ou plus long que la fréquence d'émission de la mesure. Par exemple, pour la mesure StoredBytes, mettez à jour l'intervalle d'alarme sur au moins une heure si vous voulez que l'alarme se déclenche à 3:01 et que vous continuez à se déclencher jusqu'à 4:00 dans l'exemple précédent. Reportez-vous à Sélection de l'intervalle pour une requête d'alarme et à Référence de Monitoring Query Language (MQL).
Cause : dimensions incorrectes
L'expression d'alarme n'a pas abouti lorsqu'une ressource remplit la condition définie dans l'alarme car elle a été filtrée à l'aide de dimensions.
Prenons l'exemple d'une alarme avec des dimensions sélectionnées pour le domaine de disponibilité 1. La ressource qui remplissait la condition se trouve dans le domaine de disponibilité 2. L'évaluation des alarmes ne prend en compte que les ressources correspondant aux dimensions spécifiées.
Solution : mettre à jour les dimensions
Supprimez les dimensions ou mettez-les à jour pour inclure la ressource. Reportez-vous à Sélection de dimensions pour une requête d'alarme.
Cause : requête incorrecte
Exemples courants :
- La requête d'alarme peut indiquer la mesure
MemoryUtilizationlorsque vous vouliez sélectionnerCpuUtilization. - La requête d'alarme peut indiquer la statistique
mean()lorsque vous souhaitez qu'elle surveille la somme des points de données dans un intervalle (sum()).
Pour rechercher une alarme dans la requête, obtenez ses détails.
Pour plus d'informations sur les éléments de requête, reportez-vous à Référence Monitoring Query Language (MQL). Pour plus d'informations sur l'évaluation des alarmes, reportez-vous à Illustration de l'évaluation des alarmes.
Solution : mettre à jour la requête
Cause : l'alarme est désactivée
Solution : activer l'alarme
L'alarme n'envoie pas de notification
Lorsque l'alarme se déclenche, elle n'envoie pas de notification.
Cause : l'alarme ou la dimension est supprimée
Solution : supprimer la suppression
Reportez-vous à Suppression d'une suppression d'une alarme unique et à Suppression de suppressions de plusieurs alarmes.
Cause : l'abonnement ne fait pas partie du sujet configuré
Par exemple, disons que vous ne recevez pas de messages d'alarme dans votre boîte de réception. Le sujet spécifié pour l'alarme peut ne pas avoir d'abonnement par courriel pour l'adresse électronique souhaitée.
Pour vérifier si le sujet inclut l'abonnement attendu, reportez-vous à Obtention des détails d'un sujet.
Solution : mettre à jour le sujet pour inclure l'abonnement
Reportez-vous à Création d'un abonnement.
Vous pouvez également mettre à jour l'alarme pour référencer un nouveau sujet et un nouvel abonnement, ou un sujet existant qui inclut l'abonnement de votre choix. Reportez-vous à Sélection d'un sujet comme destination de notification pour une alarm.
L'alarme envoie trop de notifications
Lorsque l'alarme se déclenche, elle envoie plus de notifications que prévu.
Cause : les notifications répétées sont activées
L'alarme est configurée pour répéter des notifications d'alarme lorsque l'alarme continue de se déclencher sans interruption.
Solution : désactiver les notifications répétées
Cause : les notifications de fractionnement sont activées
L'alarme est configurée pour envoyer une notification pour chaque flux de données de mesure déclenché. Par exemple, si 50 flux de données de mesure se déclenchent, l'alarme envoie 50 notifications. Ce comportement est attendu pour les notifications fractionnées. Reportez-vous à Scénario : séparation des messages par flux de données de mesure.
Par exemple, l'image suivante présente un graphique de mesures d'alarme avec deux flux de données de mesure qui dépassent le seuil à 1:30, provoquant le déclenchement de l'alarme.
Voici le message d'alarme envoyé pour l'instance de calcul avec la valeur de mesure 87.
Voici le message d'alarme envoyé pour l'instance de calcul avec la valeur de mesure 95.
Pour visualiser le graphique de mesures d'une alarme, obtenez son historique.
Réinitialisation de l'alarme
L'historique des alarmes affiche un état de transition RESET.
Une alarme est réinitialisée pour arrêter la vérification d'une mesure absente qui a déclenché l'état de déclenchement. Pour plus d'informations, voir A propos de la période de réinitialisation interne.
L'alarme n'est pas enregistrée (erreur 404)
Lorsque vous essayez d'enregistrer une alarme nouvelle ou mise à jour, une erreur 404 empêche la création ou la mise à jour de l'alarme.
Cause : stratégies insuffisantes
Une erreur 404 indique que vous ne disposez pas des stratégies IAM requises.
Solution : obtenir les stratégies requises
Déclenchement et effacement incessants d'une alarme
Dépannez une alarme qui bascule sans cesse entre les valeurs de statut Firing et OK.
L'intervalle d'alarme est trop petit ou le délai de déclenchement est trop grand (ou les deux). La ressource émet la mesure indiquée à une fréquence supérieure à l'intervalle de l'alarme.
Par exemple, prenons la mesure DatabaseAvailability, qui est émise toutes les 5 minutes.
Demande d'API (parties pertinentes) :
"isNotificationsPerMetricDimensionEnabled":false,
"namespace":"oci_autonomous_database",
"query":"DatabaseAvailability[1m].absent()",
"pendingDuration":"PT3M",Configuration de la console :
| Champ | Valeur |
|---|---|
| Espace de noms de mesure | oci_autonomous_database |
| Nom de mesure | DatabaseAvailability |
| Intervalle | 1 minute |
| Statistique | Moyenne |
| Règle de déclenchement |
|
| Regroupement de messages | Regrouper les messages des flux de données de mesure |
- Exemple : basculement du statut d'une alarme
Voici un exemple de basculement de statut d'une alarme entre les valeurs de statut Firing et OK de 1:00 à 1:08 Le statut est OK à 1:01, à 1:02, à 1:06 et à 1:07. A ces heures, les résultats de l'évaluation de l'alarme remplissaient la condition de l'intervalle d'une minute, mais le changement de statut était en attente en interne en raison du délai de déclenchement de trois minutes. Le statut de l'alarme est passé à Firing à 1:03 et à 1:08 car trois évaluations consécutives remplissaient la condition.
| Heure | Valeur dans le graphique de mesures* | Condition d'alarme remplie ? | Statut de l'alarme |
|---|---|---|---|
| 1:00 | 0 |
Non | OK |
| 1:01 | 1 |
Oui. La modification du statut est en attente en interne | OK |
| 1:02 | 1 |
Oui. La modification du statut est en attente en interne | OK |
| 1:03 | 1 |
Oui | Firing |
| 1:04 | 1 |
Oui | Firing |
| 1:05 | 0 |
Non | OK |
| 1:06 | 1 |
Oui. La modification du statut est en attente en interne | OK |
| 1:07 | 1 |
Oui. La modification du statut est en attente en interne | OK |
| 1:08 | 1 |
Oui | Firing |
* Pour la valeur dans le graphique de mesures, 0 signifie que la mesure est présente alors que 1 signifie qu'elle est absente. Pour obtenir un exemple de graphique de mesures, reportez-vous à Création d'une alarme d'absence.
Pour résoudre ce problème, mettez à jour la configuration de l'alarme comme suit :
- L'intervalle d'alarme doit être supérieur ou égal à la fréquence de l'émission de la mesure. Reportez-vous à Sélection de l'intervalle pour une requête d'alarme.
- Le délai de déclenchement doit être adapté à la latence. Reportez-vous à Définition du délai d'activation pour une alarme.
Par exemple, mettez à jour l'intervalle sur 10 minutes et le délai de déclenchement sur 1 minute.
Demande d'API (parties pertinentes) :
"isNotificationsPerMetricDimensionEnabled":false,
"namespace":"oci_autonomous_database",
"query":"DatabaseAvailability[10m].absent()",
"pendingDuration":"PT1M",Configuration de la console :
| Champ | Valeur |
|---|---|
| Espace de noms de mesure | oci_autonomous_database |
| Nom de mesure | DatabaseAvailability |
| Intervalle | 10 minutes |
| Statistique | Moyenne |
| Règle de déclenchement |
|
| Regroupement de messages | Regrouper les messages des flux de données de mesure |
- Exemple : la mesure est présente, l'alarme a le statut
OK - Dans cet exemple, la mesure est présente aux heures attendues (toutes les cinq minutes) : à 2:00, à 2:05 et à 2:10. Chaque fois, l'alarme évalue la présence de la mesure au cours des dix dernières minutes. Le statut de l'alarme reste
OKaux heures répertoriées.
- Exemple : la mesure est absente, l'alarme a le statut
Firing - Dans cet exemple, la mesure est présente à 2:00, mais absente à 2:05 et à 2:10. Comme l'intervalle d'alarme est d'une durée de dix minutes, la condition d'alarme n'est pas remplie à 2:05. A 2:10, l'alarme passe au statut
Firingcar la condition d'alarme est remplie (aucune mesure n'était présente au cours de l'intervalle de dix minutes).