Cette page a été traduite par l'API Cloud Translation.

Annoter les incidents à l'aide de libellés

Ce document explique comment organiser et hiérarchiser vos incidents en leur attribuant des étiquettes définies par l'utilisateur. Ces libellés sont configurés au niveau des règles d'alerte et répertoriés sur les règles d'alerte et les incidents. Selon votre configuration, les libellés sont également répertoriés dans certaines notifications.

À propos des libellés

Les étiquettes, qui sont des paires clé/valeur, permettent d'associer des informations à une série temporelle, une règle d'alerte, un incident ou une notification. Par exemple, les étiquettes d'une série temporelle peuvent identifier l'instance de machine virtuelle (VM) spécifique à partir de laquelle des données ont été collectées. Les étiquettes sont définies par l'utilisateur ou prédéfinies.

Étiquettes personnalisés

Les étiquettes définies par l'utilisateur contiennent des informations que vous spécifiez. Ces étiquettes peuvent avoir des valeurs statiques ou dynamiques:

Les étiquettes statiques définies par l'utilisateur comportent des valeurs non modifiables. Vous pouvez créer des étiquettes statiques définies par l'utilisateur lorsque vous configurez une règle d'alerte à l'aide de la console Google Cloud ou de l'API Cloud Monitoring. Pour en savoir plus, consultez les documents suivants :
- Créez des règles d'alerte de seuil de métrique.
- Créez des règles d'alerte par API.
Les étiquettes dynamiques définies par l'utilisateur ont des valeurs qui peuvent changer en fonction des valeurs des données de séries temporelles. Vous pouvez créer des étiquettes dynamiques définies par l'utilisateur lorsque vous configurez la condition d'une règle d'alerte avec MQL. Vous trouverez un exemple dans la section Exemple: Ajouter des étiquettes définies par l'utilisateur avec des valeurs dynamiques.

Les libellés doivent commencer par une lettre minuscule. Les clés et les valeurs de libellé ne peuvent contenir que des lettres minuscules, des chiffres, des traits de soulignement et des tirets.

Étiquettes prédéfinis

Les libellés prédéfinis sont inclus dans les descripteurs de ressources. Ils doivent être renseignés lorsque des données de séries temporelles sont écrites. Ces libellés fournissent des informations sur la métrique collectée ou sur la ressource par rapport à laquelle la métrique est écrite. Par exemple, les libellés d'une série temporelle peuvent identifier une machine virtuelle (VM), une zone, un projet Google Cloud et un type d'appareil. Lorsque Monitoring crée un incident basé sur cette série temporelle, l'incident hérite de ces libellés.

Afficher les libellés

Vous pouvez afficher les libellés d'une règle d'alerte ou d'un incident sur la page d'informations d'un incident, sur la page des détails d'une règle d'alerte et dans certaines notifications.

Règles d'alerte: les étiquettes statiques définies par l'utilisateur sont répertoriées dans la section Étiquettes utilisateur. Les étiquettes dynamiques définies par l'utilisateur et les étiquettes prédéfinies ne sont pas visibles.
Incidents: les étiquettes statiques définies par l'utilisateur sont répertoriées dans la section Libellés de règles, tandis que les étiquettes dynamiques définies par l'utilisateur sont répertoriées dans la section Libellés de métriques. Les libellés prédéfinis sont répertoriés dans les sections Étiquettes de ressources surveillées et Étiquettes de métriques.
Notifications: les étiquettes prédéfinies et les étiquettes définies par l'utilisateur sont répertoriées dans les types de notification suivants:
- E-mail
- Google Chat
- PagerDuty
- Pub/Sub
- Webhook

Exemple: Ajouter des étiquettes définies par l'utilisateur avec des valeurs dynamiques

Vous pouvez utiliser MQL pour configurer une étiquette afin que sa valeur change de manière dynamique en fonction des données de séries temporelles. Par exemple, vous souhaitez que vos incidents soient associés à un libellé criticality dont la valeur change en fonction de la valeur de la métrique d'utilisation du processeur surveillée:

fetch gce_instance
| metric 'compute.googleapis.com/instance/cpu/utilization'
| group_by sliding(5m), [value_utilization_mean: mean(value.utilization)]
| map
    add[
      criticality:
        if(val() >= 90 '%', 'CRITICAL',
          if(val() >= 80 '%', 'WARNING',
            if(val() >= 70 '%', 'INFO', 'GOOD')))
    ]
| condition val() >= 70 '%'

La figure suivante montre comment les règles d'alerte qui utilisent des requêtes MQL traitent les données de séries temporelles qu'elles surveillent:

Illustration de la façon dont les règles d'alerte traitent les séries temporelles surveillées.

Le gestionnaire de règles traite les données d'utilisation du processeur et génère une série temporelle indiquant quand la condition est remplie. Dans l'exemple précédent, la condition est remplie lorsque l'utilisation du processeur est d'au moins 70%. Pour chaque série temporelle d'entrée, le gestionnaire de règles peut générer l'une des quatre séries temporelles suivantes:

Nom de la série temporelle de sortie	Condition remplie	Description
"BON"	Non	Cette série temporelle possède les mêmes libellés que la série temporelle d'entrée. Il ne comporte pas d'étiquette de gravité.
"CRITICAL"	Oui	L'utilisation du processeur est d'au moins 90%. La série temporelle de sortie comporte les mêmes étiquettes que la série temporelle "BON" et comporte un libellé de gravité associé à la valeur "CRITICAL".
"AVERTISSEMENT"	Oui	L'utilisation du processeur est d'au moins 80 %, mais inférieure à 90%. La série temporelle de sortie comporte les mêmes étiquettes que la série temporelle "BON" et comporte un libellé de gravité avec la valeur "WARNING".
"INFO"	Oui	L'utilisation du processeur est d'au moins 70 %, mais inférieure à 80%. La série temporelle de sortie comporte les mêmes libellés que la série temporelle "BON" et comporte un libellé de gravité associé à la valeur "INFO".

Les données de séries temporelles générées par le gestionnaire de règles sont les entrées du gestionnaire d'incidents, qui détermine à quel moment les incidents sont créés et fermés. Pour déterminer quand fermer un incident, le gestionnaire d'incidents utilise les valeurs des champs duration, evaluationMissingData et autoClose.

Bonnes pratiques

Pour vous assurer qu'au maximum un incident est ouvert à la fois lorsque vous créez des étiquettes dont les valeurs sont définies dynamiquement, procédez comme suit:

Dans l'objet MetricThreshold, remplacez les valeurs par défaut pour les champs suivants:
- Champ duration: définissez une valeur non nulle.
- Champ evaluationMissingData: défini de manière à ce que les incidents soient fermés lorsque les données cessent d'arriver. Lorsque vous utilisez l'API Cloud Monitoring, définissez ce champ sur EVALUATION_MISSING_DATA_INACTIVE. Lorsque vous utilisez la console Google Cloud, définissez le champ sur "Points de données manquants traités comme des valeurs qui n'enfreignent pas la condition de règle".
Dans l'objet AlertStrategy, définissez le champ autoClose sur sa valeur minimale de 30 minutes. Lorsque vous utilisez l'API Cloud Monitoring, définissez ce champ sur 30m.

Pour en savoir plus, consultez la section Données de métrique partielles.

Flux d'incidents

Supposons que les mesures d'utilisation du processeur soient inférieures à 70% lors de la création de la règle d'alerte. La séquence suivante montre comment les incidents sont ouverts et fermés:

Comme les mesures d'utilisation du processeur sont inférieures à 70%, le gestionnaire de règles génère la série temporelle "BON" et aucun incident n'est ouvert.
Supposons maintenant que l'utilisation du processeur passe à 93%. Le gestionnaire de règles cesse de générer les données de séries temporelles "BONNE" et commence à en générer pour la série temporelle "CRITICAL".

Le gestionnaire d'incidents voit une nouvelle série temporelle "CRITICAL" qui remplit la condition, puis ouvre un incident. La notification inclut le libellé de gravité avec la valeur CRITICAL.
Supposons que l'utilisation du processeur tombe à 75%. Le gestionnaire de règles cesse de générer la série temporelle "CRITICAL" et commence à générer la série temporelle "INFO".

Le gestionnaire d'incidents voit une nouvelle série temporelle "INFO" qui remplit la condition, puis ouvre un incident. La notification inclut le libellé de gravité avec la valeur INFO.

Le gestionnaire d'incidents constate qu'aucune donnée n'arrive pour la série temporelle "CRITICAL" et qu'un incident est ouvert pour cette série temporelle. Étant donné que cette règle est configurée pour fermer les incidents lorsque les données n'arrivent plus, le gestionnaire d'incidents clôture l'incident associé à la série temporelle "CRITICAL". Par conséquent, seul l'incident dont le libellé de gravité est défini sur INFO reste ouvert.
Enfin, supposons que l'utilisation du processeur passe à 45%. Cette valeur étant inférieure à tous les seuils, le gestionnaire de règles cesse de générer la série temporelle "INFO" et commence à générer la série temporelle "GOOD".

Le gestionnaire d'incidents constate qu'aucune donnée n'arrive pour la série temporelle "INFO" et qu'un incident est ouvert pour celle-ci. Comme la règle utilise les paramètres recommandés, l'incident est clôturé.

Si vous n'utilisez pas la valeur recommandée pour le champ evaluationMissingData, les incidents ouverts ne sont pas fermés immédiatement lorsque les données cessent d'arriver. Par conséquent, vous pouvez voir plusieurs incidents ouverts pour la même série temporelle d'entrée. Pour en savoir plus, consultez la section Données de métrique partielles.