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

Annoter les incidents à l'aide d'étiquettes

Ce document décrit comment vous pouvez organiser et hiérarchiser vos incidents en leur attribuant des étiquettes définies par l'utilisateur. Ces étiquettes sont configurées sur des règles d'alerte. Elles sont répertoriées les incidents. Selon votre configuration, les étiquettes sont également figurant dans certaines notifications.

À propos des libellés

Les étiquettes, qui sont des paires clé/valeur, sont utilisées pour associer 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 instance de machine virtuelle (VM) à partir de laquelle les données ont été collectées. Les étiquettes sont prédéfinies ou définies par l'utilisateur.

Étiquettes personnalisés

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

Les valeurs des étiquettes statiques définies par l'utilisateur ne peuvent pas être modifiées. Vous pouvez créer des étiquettes statiques définies par l'utilisateur lorsque vous configurez une règle d'alerte en utilisant la console Google Cloud ou l'API Cloud Monitoring. Pour en savoir plus, consultez les documents suivants :
- Créez des règles d'alerte basées sur les seuils de métriques.
- Créez des règles d'alerte par API.
Les valeurs des libellés dynamiques définis par l'utilisateur peuvent changer les données des séries temporelles. Vous pouvez créer des étiquettes dynamiques définies par l'utilisateur lorsque configurer la condition d'une règle d'alerte avec MQL ; Pour voir un exemple, consultez 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 d'étiquette et les étiquettes ne peuvent contenir que des lettres minuscules, des chiffres, des traits de soulignement et tirets.

Étiquettes prédéfinis

Les étiquettes prédéfinies sont incluses dans les descripteurs de ressources. ces étiquettes doivent être renseignés lors de l'écriture de données de séries temporelles. Ces libellés indiquent des informations à propos de la métrique collectée ou de la ressource de référence n'est pas rédigée. Par exemple, les étiquettes d'une série temporelle peuvent identifier une machine virtuelle (VM), une zone, un projet Google Cloud et un type d'appareil. Quand Monitoring crée un incident à partir de cette série temporelle, l'incident hérite de ces libellés.

Afficher les libellés

Vous pouvez afficher les étiquettes d'une règle d'alerte ou d'un incident sur la page d'informations de l'incident, la page d'informations 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 Étiquettes utilisateur. Libellés dynamiques définis par l'utilisateur et libellés prédéfinis ne sont pas visibles.
Incidents: les libellés statiques définis par l'utilisateur sont répertoriés dans les libellés de règle. et les libellés dynamiques définis par l'utilisateur sont répertoriés dans la section Libellés de métriques. . Les étiquettes prédéfinies sont listées dans Libellés de ressource surveillée. et Libellés de métriques.
Notifications: les libellés prédéfinis et les libellés définis par l'utilisateur sont répertoriés. dans les types de notifications suivants:
- Adresse 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 de manière dynamique en fonction de données de séries temporelles. Par exemple, vous voulez 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 Les 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 leurs 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 qui indique quand la condition est remplie. Lors de la précédente exemple, la condition est remplie lorsque l'utilisation du CPU 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 étiquettes que la série temporelle d'entrée. Il n'a pas d'étiquette de gravité.
"CRITIQUE"	Oui	L'utilisation du processeur est d'au moins 90%. La série temporelle de sortie a les mêmes étiquettes que la série "GOOD" série temporelle suivie d'une étiquette de gravité associée à la valeur "CRITICAL".
"AVERTISSEMENT"	Oui	L'utilisation du processeur est comprise entre 80% et 90%. La série temporelle de sortie a les mêmes étiquettes que la série "GOOD" série temporelle plus une étiquette de gravité associée à la valeur "WARNING" (AVERTISSEMENT).
"INFO"	Oui	L'utilisation du processeur est d'au moins 70 %, mais inférieure à 80%. La série temporelle de sortie a les mêmes étiquettes que la série "GOOD" série temporelle suivie d'une étiquette de gravité associée à la valeur "INFO".

Les données de séries temporelles générées par le gestionnaire de règles constituent l'entrée de la 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 l'API les valeurs de duration, evaluationMissingData, et autoClose.

Bonnes pratiques

Pour vous assurer qu'un seul incident est ouvert à la fois lorsque vous créez des libellés dont les valeurs sont définies de manière dynamique, procédez comme suit:

Dans l'objet MetricThreshold, remplacez la des valeurs par défaut pour les champs suivants:
- Champ duration: défini sur une valeur non nulle.
- Champ evaluationMissingData: défini de sorte 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 "Points de données manquants traités comme des valeurs qui n'enfreignent pas la condition du règlement".
Dans l'objet AlertStrategy, définissez 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 des incidents

Supposons que les mesures d'utilisation du processeur soient inférieures à 70% lorsque d'alerte est créée. La séquence suivante montre comment les incidents sont ouvertes et fermées:

Comme les mesures d'utilisation du processeur sont inférieures à 70%, le gestionnaire de règles génère l'état "BON" des séries temporelles qu'aucun incident n'est ouvert.
Supposons ensuite que l'utilisation du processeur passe à 93%. Gestionnaire de règles cesse de générer le résultat "BON" de séries temporelles et commence à générer des données le "CRITICAL" de séries temporelles.

Le gestionnaire d'incidents voit une nouvelle erreur "CRITICAL" de séries temporelles qui respecte puis ouvre un incident. Cette notification inclut une étiquette de gravité associée à la valeur CRITICAL.
Supposons que l'utilisation du processeur tombe à 75%. Gestionnaire de règles cesse de générer l'erreur "CRITICAL" série temporelle et commence à générer l'instruction "INFO" de séries temporelles.

Le gestionnaire d'incidents voit une nouvelle fenêtre "INFO" de séries temporelles qui respecte puis ouvre un incident. La la notification inclut l'étiquette de gravité avec la valeur INFO.

Le gestionnaire d'incidents constate qu'aucune donnée n'arrive pour l'incident "CRITICAL" série temporelle et qu'un incident est ouvert pour cette série temporelle. En effet, est configurée pour fermer les incidents lorsque les données cessent d'arriver, le gestionnaire des incidents clôture d'incident "CRITICAL" de séries temporelles. Par conséquent, seul l'incident dont l'étiquette de gravité a la valeur INFO reste ouvert.
Enfin, supposons que l'utilisation du processeur tombe à 45%. Cette valeur est inférieure que tous les seuils, de sorte que le gestionnaire de règles cesse de générer INFO série temporelle et commence à générer de séries temporelles.

Le gestionnaire d'incidents constate qu'aucune donnée n'arrive pour l'erreur "INFO". série temporelle et qu'un incident est ouvert pour cette série temporelle. En effet, utilise les paramètres recommandés, l'incident est clos.

Si vous n'utilisez pas la valeur recommandée pour le champ evaluationMissingData, lorsque les données cessent d'arriver, les incidents ouverts ne sont pas fermés immédiatement. Il se peut donc que plusieurs incidents ouverts s'affichent pour la même entrée de séries temporelles. Pour en savoir plus, consultez la section Données de métrique partielles.