Bonnes pratiques pour les règles d'alerte MQL

Cette page contient un index des bonnes pratiques pour les règles d'alerte avec une condition basée sur le langage MQL (Monitoring Query Language). Les informations collectées ici vous offrent un aperçu rapide des éléments à prendre en compte lors de la configuration d'une règle d'alerte avec une condition basée sur MQL.

Cette page ne décrit pas les principes de base de l'utilisation des requêtes MQL dans vos règles d'alerte. Si vous êtes un nouvel utilisateur, consultez la page Règles d'alerte avec MQL.

Opérations recommandées pour les requêtes MQL dans les règles d'alerte

L'évaluation des règles d'alerte implique plusieurs services internes. En raison de la manière dont ces services interagissent avec MQL, nous vous recommandons vivement d'utiliser certaines opérations MQL plutôt que d'autres. Par exemple, si vous utilisez delta au lieu de delta_gauge, les alertes peuvent se déclencher au mauvais moment.

Le tableau suivant présente une liste d'opérations à éviter et les opérations recommandées à utiliser à la place.

À éviter	Recommandations
adjacent_rate	rate
adjacent_delta	delta_gauge
delta	delta_gauge
window	sliding

Utiliser l'instruction every 30s avec des règles d'alerte

Les règles d'alerte évaluent leur condition toutes les 30 secondes. Cette période est appelée fenêtre de sortie. Nous vous recommandons d'inclure une opération every 30s explicite dans vos conditions pour rappeler cette période.

Par exemple, la requête MQL de la règle d'alerte suivante inclut une instruction every 30s explicite:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 30s

Si vous enregistrez une règle d'alerte avec une requête MQL qui utilise une valeur différente pour l'opération every, Cloud Monitoring utilise toujours une valeur de 30 secondes lorsque la règle d'alerte est active. Par exemple, une règle d'alerte avec la requête suivante a toujours une fenêtre de sortie de 30 secondes:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 90s

Améliorer l'efficacité des requêtes

Les requêtes s'exécutent lentement lors du traitement d'importants volumes de données. Pour améliorer l'efficacité d'une requête, vous pouvez essayer de réduire la quantité de données traitées par la requête. Les sections suivantes proposent plusieurs options pour réduire le volume de données évalué par votre requête.

Placez des filtres plus tôt dans votre requête

Lorsque vous placez des filtres plus tôt dans votre requête, ils peuvent filtrer les données inutiles avant que la requête n'exécute des opérations sur vos données. Prenons par exemple la requête suivante:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by [resource.zone], .sum
| filter zone = 'us-west1-b'
| condition val() > 5'GBy'

La requête peut s'exécuter plus rapidement si vous déplacez l'opération filter avant l'opération group_by:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| filter zone = 'us-west1-b'
| group_by [resource.zone], .sum
| condition val() > 5'GBy'

Réduire la fenêtre d'alignement de la requête

Lorsqu'une requête utilise l'opération align, une fenêtre d'alignement plus petite représente une période plus courte que Cloud Monitoring évalue pour chaque point de la série temporelle. Par conséquent, vous pouvez essayer d'améliorer l'efficacité de votre requête en réduisant la valeur de votre opération align. Par exemple, la requête suivante a un intervalle d'alignement de deux heures:

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(2h)
| every 30s
| condition val() > 2'GBy'

Toutefois, si vous ne devez afficher les données que pour une période d'une heure, vous pouvez réduire la période d'alignement à une heure:

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(1h)
| every 30s
| condition val() > 2'GBy'

Pour en savoir plus, consultez la section Alignement.

Réduire la durée de la règle d'alerte

La fenêtre de durée de la règle d'alerte représente la période au cours de laquelle chaque mesure doit violer la condition avant qu'une alerte ne soit envoyée. Si vous réduisez la durée de la règle d'alerte sans augmenter l'intervalle d'alignement des requêtes, Cloud Monitoring dispose de moins de points à évaluer pour la condition de votre règle d'alerte.

Pour en savoir plus, consultez la section Intervalle de temps.

Attribuer des valeurs par défaut aux métadonnées nulles

Si une valeur de métadonnées est nulle, vos requêtes peuvent produire des résultats inattendus. Vous pouvez éviter des résultats inattendus en utilisant la fonction or_else pour attribuer aux métadonnées une valeur par défaut qui aurait normalement une valeur nulle.

Par exemple, vous exécutez une requête qui agrège toutes vos données:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

La requête produit un résultat de 10 Mo. Ensuite, exécutez une requête pour vérifier comment les 10 Moys sont répartis entre les zones de nœuds:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [metadata.system.node_zone], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

La requête de distribution renvoie les résultats suivants:

node_zone	egress_byte_count
us-central1-f	7,3 Mo
us-west1-b	2,5 Mo

Ces résultats indiquent un total de 9,8 Mo, au lieu des 10 Mo attendus. Cet écart peut se produire si l'un des libellés de métadonnées agrégées a une valeur nulle, comme dans l'ensemble de données suivant:

valeur	valeur de métadonnées
7,3 Mo	us-central1-f
2,5 Mo	us-west1-b
0,2 Mo par an

Pour éviter les problèmes liés aux métadonnées nulles, vous pouvez encapsuler votre référence de métadonnées dans une opération or_else, ce qui vous permet de spécifier une valeur par défaut si une colonne de métadonnées n'a pas de valeur. Par exemple, la requête suivante utilise or_else afin de définir une valeur de métadonnées de no zone pour toutes les colonnes de métadonnées sans valeur:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [or_else(metadata.system.node_zone, 'no zone')], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

Cette nouvelle requête produit les résultats suivants, qui totalisent 10 Mo:

node_zone	egress_byte_count
us-central1-f	7,3 Mo
us-west1-b	2,5 Mo
aucune zone	0,2 Mo par an