Cette page explique pourquoi certaines règles d'alerte avec des conditions basées sur le langage MQL (Monitoring Query Language) peuvent se comporter différemment que prévu, et propose des solutions dans ces situations.
Écarts de données
Vous avez créé une règle d'alerte avec une condition basée sur MQL, et les résultats de la requête MQL montrent un écart inattendu dans les données signalées.
Des écarts apparaissent dans les données alignées lorsqu'un calcul génère une valeur nulle pour un horodatage donné. Par exemple, le tableau de données suivant est lié à une requête sur une période de 30 secondes:
Tableau A1
| Code temporel | Value (Valeur) |
|---|---|
| 00:00:00 | 1 |
| 00:00:30 | 2 |
| 00:01:30 | 3 |
| 00:02:00 | 4 |
Comme vous avez une période de 30 secondes, vous devriez voir un horodatage à 00:01:00. De tels écarts peuvent se produire pour de nombreuses raisons.
Lacunes dus à l'alignement
Des fenêtres d'aligneur trop étroites peuvent entraîner des écarts de données. Par exemple, le tableau suivant de données de métriques brutes non alignées est écrit environ toutes les 30 secondes.
Tableau B1
| Code temporel | Value (Valeur) |
|---|---|
| 00:00:01 | 1 |
| 00:00:28 | 2 |
| 00:01:01 | 3 |
| 00:01:32 | 4 |
Si vous exécutez à 00:02:00 une requête qui aligne vos données à l'aide d'une opération next_older(30s), vous obtenez le résultat suivant, qui présente un écart de données à 00:01:00:
Tableau B2
| Code temporel | Value (Valeur) |
|---|---|
| 00:00:30 | 2 |
| 00:00:28 | 3 |
| 00:01:01 | 4 |
Cet écart se produit parce qu'aucun point des données brutes ne tombe dans la fenêtre de 30 secondes qui se termine à 00:01:00. Pour éviter ce type d'écart, utilisez une fenêtre plus grande.
Par exemple, une opération next_older(1m) génère une table sans écart de données:
Tableau B3
| Code temporel | Value (Valeur) |
|---|---|
| 00:00:01 | 1 |
| 00:00:28 | 2 |
| 00:01:01 | 3 |
| 00:01:32 | 4 |
En général, si vos données sont écrites toutes les S secondes, utilisez une fenêtre d'alignement supérieure à S. De cette façon, vous pouvez tenir compte de la répartition inégale des points de données au fil du temps.
Écarts dus aux opérations de la table
Certaines opérations de table peuvent produire des écarts inattendus. Par exemple, l'opération join ne produit un résultat qu'aux horodatages qui ont une valeur dans toutes les tables d'entrée.
Les opérations de table telles que join peuvent générer des écarts. Par exemple, vous joignez les deux tables alignées suivantes:
Tableau C1
| Code temporel | Value (Valeur) |
|---|---|
| 00:00:30 | 2 |
| 00:01:30 | 3 |
| 00:02:00 | 4 |
Tableau C2
| Code temporel | Value (Valeur) |
|---|---|
| 00:00:30 | 4 |
| 00:01:00 | 3 |
| 00:01:30 | 2 |
| 00:02:00 | 1 |
Vous obtenez alors le résultat suivant:
Tableau C3
| Code temporel | Valeur A | Valeur B |
|---|---|---|
| 00:00:30 | 1 | 4 |
| 00:01:30 | 2 | 2 |
| 00:02:00 | 3 | 1 |
Cette table n'a pas de valeur à 00:01:00 en raison de l'absence d'une valeur dans 00:01:00 dans la table C1.
Écarts dus à des valeurs manquantes
Certaines fonctions produisent des blancs lorsque leur sortie ne peut pas être convertie ou n'est pas définie. Par exemple, appliquez value.string_to_int64 à la table de valeurs de chaîne suivante:
Tableau D1
| Code temporel | Value (Valeur) |
|---|---|
| 00:00:30 | '4' |
| 00:01:00 | "3" |
| 00:01:30 | "init" |
| 00:02:00 | "1" |
La table obtenue contient un écart à 00:01:30, car MQL ne peut pas convertir 'init' en entier:
Tableau D2
| Code temporel | Value (Valeur) |
|---|---|
| 00:00:30 | 4 |
| 00:01:00 | 3 |
| 00:01:30 | null |
| 00:02:00 | 1 |
Pour éviter les écarts de données dus à des valeurs incorrectes ou manquantes, utilisez les fonctions has_value ou or_else pour gérer ces valeurs.
has_value renvoie false si son argument prend la valeur nulle. Sinon, elle renvoie true. Par exemple, si vous appliquez value has_value(1 / val()) à la table D2, vos résultats ne comporteront pas de lacunes:
Tableau D3
| Code temporel | Value (Valeur) |
|---|---|
| 00:00:30 | true |
| 00:01:00 | true |
| 00:01:30 | false |
| 00:02:00 | true |
Une alerte de seuil se déclenche lorsque le graphique MQL indique que le seuil n'a pas été dépassé
Vous souhaitez être averti si l'utilisation du processeur d'une machine virtuelle (VM) fluctue fortement. Vous devez donc créer une règle d'alerte qui surveille la métrique compute.googleapis.com/instance/cpu/utilization. Vous créez et configurez la condition pour générer un incident lorsque l'utilisation du processeur toutes les six heures dépasse un seuil de 50%. Votre condition utilise la requête suivante:
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge(6h) | condition val() > 0.5
Vous recevez une alerte au bout de 30 secondes. Toutefois, votre graphique MQL indique que le delta d'utilisation n'a pas dépassé le seuil.
Les règles d'alerte ont un intervalle de sortie de 30 secondes. Vous ne pouvez pas remplacer cette période en laissant la période non définie ou en en définissant une autre dans votre requête. Par exemple, les requêtes suivantes utilisent toujours une fenêtre de sortie de 30 secondes:
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge(6h) # period not 30 seconds | condition val() > 0.5
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge() # undefined period | condition val() > 0.5
Votre seuil de métrique a été dépassé dans les 30 premières secondes d'évaluation. Cloud Monitoring a donc envoyé une alerte. Pour éviter ce problème, ajoutez | every 30s à la fin de votre requête afin de vérifier que votre fenêtre de sortie produit les résultats souhaités. Exemple :
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge() | every 30s # explicit 30 second output window | condition val() > 0.5
Erreur: Impossible d'enregistrer la règle d'alerte. La requête contient un argument non valide.
Vous avez créé une règle d'alerte avec une condition basée sur MQL. Lorsque vous enregistrez la règle d'alerte, le message d'erreur suivant s'affiche:
Error: Unable to save alerting policy. Request contains an invalid argument.
Certaines opérations de table MQL, telles que group_by, nécessitent l'alignement de leurs entrées. Si votre requête n'aligne pas ses entrées, MQL aligne automatiquement les données. Cependant, cet alignement automatique entraîne parfois des arguments non valides.
Pour éviter ce problème, si votre requête utilise une opération de table, assurez-vous qu'elle inclut l'alignement des données. Pour obtenir la liste des fonctions d'alignement des données, consultez la section Alignement dans la documentation de référence de MQL.
La ligne de seuil n'apparaît pas sur le graphique MQL
Vous avez créé une règle d'alerte de seuil de métrique avec une condition basée sur MQL. Toutefois, la ligne de seuil n'apparaît pas sur le graphique MQL.
Cloud Monitoring ne trace la ligne de seuil que lorsque votre requête contient une expression booléenne qui compare deux valeurs, l'une étant une colonne et l'autre une valeur littérale. Par exemple, l'expression suivante représente une ligne de seuil:
val() > 5'GBy'
Toutefois, les expressions suivantes ne représentent pas de ligne de seuil:
val(0) > val(1) #one of the values must be a literal
5 > 4 #one of the values must be a column
val() #the expression must be a comparison