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 procéder au dépannage, vérifiez que vous comprenez comment les alarmes sont évaluées. Reportez-vous à la section Illustration of Alarm Evaluation.
L'alarme ne se déclenche pas
L'alarme répondait à la condition de tir, mais elle ne s'est pas déclenchée. Par exemple, une instance de calcul est tombée en panne.
Cause : délai de déclenchement long
L'expression d'alarme n'a pas donné la valeur True pendant des minutes consécutives dans la période de délai du déclencheur.
L'image suivante du graphique de mesures d'une alarme inclut une zone ombrée pour indiquer la période de délai de déclenchement. Dans cet exemple, le récapitulatif des alarmes 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 à 1:30 (lorsque le seuil est dépassé) et se termine à 1:40. L'expression d'alarme renvoie la valeur True à 1:30, puis la valeur False à 1:32. Cette véritable évaluation ne se poursuit pas pendant toute la durée du délai de déclenchement de dix minutes, de sorte que l'alarme ne se déclenche pas.
Afin d'afficher 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 : 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 d'une alarme et à Référence de Monitoring Query Language (MQL).
Cause : l'intervalle est plus court que la fréquence d'émission
L'expression d'alarme a la valeur True, 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 est 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, 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 à être évaluée sur True et l'alarme continuerait à se déclencher, jusqu'à 4:00.
Afin d'afficher 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 souhaitez 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 poursuivez le déclenchement 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 donné la valeur True lorsqu'une ressource remplissait la condition définie dans l'alarme car la ressource a été filtrée à l'aide de dimensions.
Par exemple, prenons 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 prend en compte uniquement les ressources qui correspondent 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 souhaitez sélectionnerCpuUtilization. - La requête d'alarme peut indiquer la statistique
mean()lorsque vous souhaitez plutôt que l'alarme 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 de 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 : enlever la suppression
- Pour enlever une suppression à l'échelle d'une alarme, reportez-vous à Suppression d'une suppression à l'échelle d'une alarme.
- Pour enlever une suppression propre à une dimension, reportez-vous à Suppression d'une suppression d'alarme propre à une dimension.
Cause : l'abonnement ne fait pas partie du sujet configuré
Par exemple, disons que vous n'obtenez pas de messages d'alarme dans votre boîte de réception. Le sujet spécifié pour l'alarme n'a peut-être pas 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 : mettez à jour le sujet pour inclure l'abonnement
Reportez-vous à la section 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 alerte.
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 les 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 fractionnées sont activées
L'alarme est configurée pour envoyer une notification pour chaque flux de mesure qui se déclenche. Par exemple, si 50 flux de mesure sont déclenchés, l'alarme envoie 50 notifications. Il s'agit d'un comportement 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.
Afin d'afficher le graphique de mesures d'une alarme, obtenez son historique.
Réinitialisation des alarmes
L'historique des alarmes affiche un état de transition RESET.
Une alarme se réinitialise pour arrêter la vérification d'une mesure absente qui a déclenché l'état de déclenchement. Pour plus d'informations, reportez-vous à la section About the Internal Reset Period.
L'alarme n'enregistre pas (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éclencheur |
|
| Groupement de messages | Regrouper les notifications entre les 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. Le changement de statut est en attente en interne | OK |
| 1:02 | 1 |
Oui. Le changement de 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. Le changement de statut est en attente en interne | OK |
| 1:07 | 1 |
Oui. Le changement de 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 de déclencheur pour une alerte.
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éclencheur |
|
| Groupement de messages | Regrouper les notifications entre les 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 de dix minutes, la condition d'alarme n'a pas été 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).