Une règle d'alerte est représentée dans l'API Cloud Monitoring par un objet AlertPolicy
, qui décrit un ensemble de conditions indiquant un état potentiellement non opérationnel dans votre système.
Ce document décrit les éléments suivants:
- Comment l'API Monitoring représente les règles d'alerte.
- Les types de conditions fournis par l'API Monitoring règles d'alerte.
- créer une règle d'alerte à l'aide de la Google Cloud CLI bibliothèques clientes.
Structure d'une règle d'alerte
La structure AlertPolicy
définit les composants d'une règle d'alerte. Lorsque vous créez une règle, vous spécifiez les valeurs des champs AlertPolicy
suivants :
displayName
: étiquette descriptive de la règle.documentation
: nous vous recommandons d'utiliser ce champ pour fournir des informations qui aident les personnes chargées de la gestion des incidents. Pour en savoir plus, consultez Annoter les notifications avec une documentation définie par l'utilisateur.userLabels
: tous les libellés définis par l'utilisateur associés à la stratégie. Pour plus d'informations sur l'utilisation des étiquettes avec des alertes, consultez Annotez les incidents à l'aide de libellés.conditions[]
: tableau de structuresCondition
.combiner
: opérateur logique qui détermine comment gérer plusieurs et conditions d'exploitation.notificationChannels[]
: tableau de noms de ressources, chacun identifiant uneNotificationChannel
.alertStrategy
: spécifie la rapidité avec laquelle Monitoring clôture les incidents lorsque les données ne sont plus reçues. Cet objet spécifie également si les notifications répétées sont activées pour les règles d'alerte basées sur les métriques, ainsi que l'intervalle entre ces notifications. Pour en savoir plus, consultez la section Configurer des notifications répétées pour les règles d'alerte basées sur les métriques.
Vous pouvez également spécifier le champ severity
lorsque vous utilisez l'API Cloud Monitoring et la console Google Cloud. Ce champ vous permet de définir le niveau de gravité des incidents. Si vous ne spécifiez pas de gravité, Cloud Monitoring définit la gravité de la règle d'alerte sur No Severity
.
Vous pouvez utiliser d'autres champs, selon les conditions que vous créez.
Lorsqu'une règle d'alerte contient une condition, une notification est envoyée cette condition est remplie. Pour en savoir plus sur les notifications lorsque les règles d'alerte contiennent plusieurs conditions, consultez les sections Règles comportant plusieurs conditions et Nombre de notifications par règle.
Lorsque vous créez ou modifiez la règle d'alerte, Monitoring définit d'autres champs, y compris le champ name
. La valeur du champ name
correspond au nom de la ressource pour la règle d'alerte, qui identifie la règle. Le nom de la ressource se présente sous la forme suivante :
projects/PROJECT_ID/alertPolicies/POLICY_ID
Types de conditions dans l'API
L'API Cloud Monitoring est compatible avec divers types de conditions dans la structure Condition
. Il existe plusieurs types de conditions pour les règles d'alerte basées sur les métriques, et un type pour les règles d'alerte basées sur les journaux. Les sections suivantes décrivent les types de conditions disponibles.
Conditions pour les règles d'alerte basées sur des métriques
Pour créer une règle d'alerte qui surveille les données de métriques, y compris celles basées sur les journaux vous pouvez utiliser les types de conditions suivants:
Conditions de métriques basées sur des filtres
Les conditions MetricAbsence
et MetricThreshold
utilisent des filtres Monitoring pour sélectionner les données de séries temporelles à surveiller. D'autres champs de la structure de conditions
indiquent comment filtrer,
regrouper et agréger
les données. Pour en savoir plus sur ces concepts, consultez la section Filtrage et agrégation : manipuler des séries temporelles.
Si vous utilisez le type de condition MetricAbsence
, vous pouvez créer une condition.
qui n'est satisfaite que lorsque toutes les séries temporelles sont absentes. Cette condition utilise le paramètre aggregations
pour agréger plusieurs séries temporelles en une seule. Pour en savoir plus, consultez la référence MetricAbsence
dans la documentation de l'API.
Une règle d'alerte en cas d'absence de métrique nécessite l'écriture de certaines données précédemment ; Pour en savoir plus, consultez Créez des règles d'alerte en cas d'absence de métrique.
Si vous souhaitez recevoir une notification en fonction d'une valeur prévue, configurez
votre règle d'alerte pour utiliser
Type de condition MetricThreshold
et pour définir forecastOptions
. Lorsque ce champ n'est pas défini, les données mesurées sont comparées à un seuil.
Cependant, lorsque ce champ est défini, les données prédites sont comparées à une
de sortie. Pour en savoir plus, consultez
Créez des règles d'alerte basées sur les métriques prévues.
Conditions de métriques basées sur MQL
La condition MonitoringQueryLanguageCondition
utilise le langage MQL (Monitoring Query Language) pour sélectionner et manipuler les données de séries temporelles à surveiller. Vous pouvez créer des règles d'alerte qui comparent les valeurs par rapport à un seuil ou tester l'absence de valeurs avec ce type de condition.
Si vous utilisez une condition MonitoringQueryLanguageCondition
, il doit s'agir de la seule condition de votre règle d'alerte. Pour en savoir plus, consultez la page Règles d'alerte avec MQL.
Conditions de métriques basées sur PromQL
La condition PrometheusQueryLanguageCondition
utilise des requêtes PromQL (Prometheus Query Language) pour sélectionner et manipuler les données de séries temporelles à surveiller.
Votre condition peut calculer un ratio de métriques,
évaluer les comparaisons de métriques, etc.
Si vous utilisez une condition PrometheusQueryLanguageCondition
, il doit s'agir de la seule condition de votre règle d'alerte. Pour en savoir plus, consultez
Règles d'alerte avec PromQL
Conditions d'alerte sur les ratios
Vous pouvez créer des règles d'alerte basées sur un seuil de métrique pour surveiller le ratio de deux métriques. Vous pouvez créer ces règles à l'aide du type de condition MetricThreshold
ou MonitoringQueryLanguageCondition
.
Vous pouvez également utiliser MQL directement dans la console Google Cloud. Vous ne pouvez pas créer ni gérer des conditions basées sur des ratios à l'aide de l'interface graphique pour créer des conditions de seuil.
Nous vous recommandons d'utiliser MQL pour créer des règles d'alerte basées sur des ratios.
MQL vous permet de créer des requêtes plus puissantes et flexibles que celles que vous pouvez créer à l'aide du type de condition MetricTheshold
et des filtres Monitoring.
Par exemple, avec une condition MonitoringQueryLanguageCondition
, vous pouvez calculer le ratio entre une métrique de jauge et une métrique delta. Pour obtenir des exemples, consultez les exemples de règles d'alerte MQL.
Si vous utilisez la condition MetricThreshold
, le numérateur et le dénominateur du ratio doivent avoir le même MetricKind
.
Pour obtenir une liste des métriques et de leurs propriétés, consultez la page Listes de métriques.
En général, il est préférable de calculer les ratios en fonction des séries temporelles collectées pour un type de métrique unique, à l'aide de valeurs de libellés. Un ratio calculé sur deux différents types de métriques présentent des anomalies en raison des différents types d'échantillonnage les périodes et les périodes d'alignement.
Par exemple, supposons que vous disposiez de deux types de métriques différents (nombre de RPC total et nombre de RPC en erreur), et que vous souhaitiez calculer le ratio du nombre de RPC en erreur par rapport au nombre de RPC total. Les RPC ayant échoué sont comptabilisés dans la série temporelle des deux types de métriques. Par conséquent, lorsque vous alignez la série temporelle, il se peut qu'un RPC en échec n'apparaisse pas dans le même intervalle d'alignement pour les deux séries temporelles. Cette différence peut se produire pour plusieurs raisons :
- Étant donné que deux séries temporelles enregistrent le même événement, deux valeurs de compteur sous-jacentes mettent en œuvre la collection et ne sont pas mises à jour de manière atomique.
- Les taux d'échantillonnage peuvent varier. Lorsque les séries temporelles sont alignées sur une période commune, les décomptes d'un seul événement peuvent apparaître dans des intervalles d'alignement adjacents dans la série temporelle des différentes métriques.
La différence du nombre de valeurs dans les intervalles d'alignement correspondants peut générer des valeurs de ratio error/total
insensées, telles que 1/0 ou 2/1.
Les ratios de nombres plus élevés sont moins susceptibles de générer des valeurs absurdes. Vous pouvez obtenir des nombres plus élevés par agrégation, soit en utilisant une fenêtre d'alignement plus longue que la période d'échantillonnage, soit en regroupant les données pour certains libellés. Ces techniques réduisent l'effet de différences mineures du nombre de points dans un intervalle donné. En d'autres termes, une disparité de deux points est plus importante lorsque le nombre attendu de points dans un intervalle est de 3 par rapport au nombre attendu de 300.
Si vous utilisez des types de métriques intégrés, vous n'aurez peut-être pas d'autre choix que de calculer les ratios sur l'ensemble des types de métriques pour obtenir la valeur souhaitée.
Si vous concevez des métriques personnalisées pouvant comptabiliser la même chose (par exemple, des RPC qui renvoient des états d'erreur) dans deux métriques différentes, envisagez plutôt d'utiliser une seule métrique, qui inclut un décompte à la fois. Par exemple, supposons que vous comptabilisiez les RPC et que vous souhaitiez suivre le ratio entre les RPC ayant échoué et tous les RPC. Pour résoudre ce problème, créez un seul type de métrique pour comptabiliser les RPC et utilisez un libellé pour enregistrer l'état de l'appel, y compris l'état "OK". Chaque valeur d'état (erreur ou état "OK") est ensuite enregistrée en mettant à jour un seul compteur pour ce cas.
Condition pour les règles d'alerte basées sur les journaux
Pour créer une règle d'alerte basée sur les journaux, qui vous avertit lorsqu'un message correspondant à votre filtre apparaît dans vos entrées de journal, utilisez le type de condition LogMatch
. Si vous utilisez une condition LogMatch
, il doit s'agir de la seule condition de votre règle d'alerte.
N'essayez pas d'utiliser le type de condition LogMatch
avec une condition basée sur les journaux
métriques. Les règles d'alerte qui surveillent les métriques basées sur les journaux sont des règles basées sur les métriques. Pour en savoir plus sur le choix de la règle d'alerte permettant de surveiller les métriques basées sur les journaux ou les entrées de journal, consultez la page Surveiller les journaux.
Les règles d'alerte utilisées dans les exemples du document Gérer les règles d'alerte via l'API sont des règles d'alerte basées sur les métriques, même si les principes sont les mêmes pour les règles d'alerte basées sur les journaux. Pour en savoir plus sur les règles d'alerte basées sur les journaux, consultez Créer une règle d'alerte basée sur les journaux à l'aide de l'API Monitoring dans la documentation Cloud Logging.
Avant de commencer
Avant d'écrire du code sur l'API, vous devez :
- Vous devez connaître la terminologie et les concepts généraux utilisés avec les règles d'alerte. Pour en savoir plus, consultez la page Présentation des alertes.
- Assurez-vous que l'API Cloud Monitoring est activée. Pour en savoir plus, consultez la section Activer l'API.
- Si vous prévoyez d'utiliser des bibliothèques clientes, installez-les pour les langues que vous souhaitez utiliser. Pour en savoir plus, consultez la page Bibliothèques clientes. Actuellement, la fonctionnalité d'alerte de l'API n'est compatible qu'avec les langages C#, Go, Java, Node.js et Python.
Si vous prévoyez d'utiliser Google Cloud CLI, installez-la. Toutefois, si vous utilisez Cloud Shell, Google Cloud CLI est déjà installé.
Des exemples utilisant l'interface
gcloud
sont également fournis sur cette page. Notez que, dans tous ces exemplesgcloud
, nous partons du principe que le projet en cours a déjà été défini comme cible (gcloud config set project [PROJECT_ID]
). Ainsi, les appels omettent l'option explicite--project
. L'ID du projet en cours dans les exemples esta-gcp-project
.
-
Pour obtenir les autorisations nécessaires pour créer et modifier des règles d'alerte à l'aide de l'API Cloud Monitoring, demandez à votre administrateur de vous accorder le rôle IAM Éditeur Monitoring AlertPolicy (
roles/monitoring.alertPolicyEditor
) sur votre projet. Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.
Pour en savoir plus sur les rôles IAM pour Monitoring, consultez Contrôlez les accès avec Identity and Access Management.
Concevez votre application pour des appels d'API Cloud Monitoring monothread qui modifier l'état d'une règle d'alerte projet Google Cloud. Par exemple, les appels d'API à thread unique qui créent, mettent à jour ou suppriment une règle d'alerte.
Créer une règle d'alerte
Pour créer une règle d'alerte dans un projet, utilisez la
alertPolicies.create
. Pour savoir comment appeler cette méthode, ses paramètres et les données de réponse, consultez la page de référence alertPolicies.create
.
Vous pouvez créer des règles à partir de fichiers JSON ou YAML.
La Google Cloud CLI accepte ces fichiers en tant qu'arguments.
vous pouvez lire les fichiers JSON de manière programmatique et les convertir en AlertPolicy
objets, et créer des stratégies à partir de ceux-ci
à l'aide de la méthode alertPolicies.create
. Si vous disposez d'un fichier de configuration JSON ou YAML Prometheus avec une règle d'alerte, la Google Cloud CLI peut le migrer vers une règle d'alerte Cloud Monitoring avec une condition PromQL. Pour en savoir plus, consultez
Migrer les règles d'alerte et les récepteurs à partir de Prometheus.
Chaque règle d'alerte appartient à un projet de champ d'application d'un champ d'application des métriques. Chaque projet peut contenir jusqu'à 500 règles.
Pour les appels d'API, vous devez fournir un "ID de projet". Utilisez l'ID du projet de champ d'application d'un champ d'application des métriques comme valeur. Dans les exemples figurant sur cette page, l'ID du projet de champ d'application d'un champ d'application des métriques est a-gcp-project
.
Les exemples suivants illustrent la création de règles d'alerte, mais ils ne décrivent pas comment créer un fichier JSON ou YAML une règle d'alerte. Au lieu de cela, les exemples supposent qu'un fichier au format JSON et ils illustrent comment émettre l'appel d'API. Par exemple, des fichiers JSON, consultez la section Exemples de règles. Pour en savoir plus sur la surveillance des ratios des métriques, consultez la page Ratios des métriques.
gcloud
Pour créer une règle d'alerte dans un projet, exécutez la commande gcloud alpha monitoring
policies create
. L'exemple suivant crée une règle d'alerte dans a-gcp-project
à partir du fichier rising-cpu-usage.json
:
gcloud alpha monitoring policies create --policy-from-file="rising-cpu-usage.json"
Si la commande réussit, elle renvoie le nom de la nouvelle règle, par exemple :
Created alert policy [projects/a-gcp-project/alertPolicies/12669073143329903307].
Le fichier rising-cpu-usage.json
contient le code JSON d'une règle dont le nom à afficher est "High CPU rate of change" ("Haute variation de l'utilisation du processeur"). Pour en savoir plus sur cette règle, consultez la section Règle de taux d'évolution.
Pour plus d'informations, consultez la documentation de référence sur gcloud alpha monitoring policies create
.
C#
Pour vous authentifier auprès de Monitoring, configurez les identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
Go
Pour vous authentifier auprès de Monitoring, configurez les identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
Java
Pour vous authentifier auprès de Monitoring, configurez les identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
Node.js
Pour vous authentifier auprès de Monitoring, configurez les identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
PHP
Pour vous authentifier auprès de Monitoring, configurez les identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
Python
Pour vous authentifier auprès de Monitoring, configurez les identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
L'objet AlertPolicy
créé contiendra des champs supplémentaires.
La règle en elle-même contiendra les champs name
, creationRecord
et mutationRecord
. En outre, un champ name
est également attribué à chaque condition de la règle.
Ces champs ne peuvent pas être modifiés de manière externe, il n'est donc pas nécessaire de les définir lors de la création d'une règle. Aucun des exemples JSON de cette page ne les inclut, mais si les règles créées à partir de ces exemples sont récupérées après leur création, ces champs seront présents.
Configurer des notifications répétées pour les règles d'alerte basées sur les métriques
Par défaut, une règle d'alerte basée sur les métriques envoie une notification à chaque canal de notification lorsqu'un incident est ouvert. Vous pouvez toutefois modifier le paramètre et configurer une règle d'alerte pour renvoyer les notifications à tous certains des canaux de notification pour votre règle d'alerte. Ces notifications répétées sont envoyées pour les incidents dont l'état est "Ouvert" ou "Confirmé". L'intervalle entre ces notifications doit être d'au moins 30 minutes et ne pas dépasser 24 heures, exprimé en secondes.
Pour configurer des notifications répétées, ajoutez à la configuration de la règle d'alerte un objet AlertStrategy
contenant au moins un objet NotificationChannelStrategy
.
Un objet NotificationChannelStrategy
comporte deux champs:
renotifyInterval
: intervalle, en secondes, entre les notifications répétées.Si vous modifiez la valeur du champ
renotifyInterval
lorsque qu'un incident pour la règle d'alerte est ouvert, voici ce qui se produit:- La règle d'alerte envoie une autre de l'incident.
- La règle d'alerte redémarre la période d'intervalle.
notificationChannelNames
: tableau de noms de ressources de canaux de notification qui sont des chaînes au formatprojects/PROJECT_ID/notificationChannels/CHANNEL_ID
, où CHANNEL_ID est une valeur numérique. Pour savoir comment récupérer l'ID de la chaîne, consultez Répertorier les canaux de notification d'un projet
Par exemple, l'exemple JSON suivant montre une stratégie d'alerte configurée pour envoyer des notifications répétées toutes les 1 800 secondes (30 minutes) à un canal de notification :
"alertStrategy": { "notificationChannelStrategy": [ { "notificationChannelNames": [ "projects/PROJECT_ID/notificationChannels/CHANNEL_ID" ], "renotifyInterval": "1800s" } ] }
Pour arrêter temporairement les notifications répétées, créez une mise en attente. À
éviter les notifications répétées, modifier la règle d'alerte à l'aide de l'API et
Supprimez l'objet NotificationChannelStrategy
.