Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Présentation

Que vous débutiez ou que vous soyez un utilisateur plus expérimenté de Grafana Alerting, découvrez les principes fondamentaux et les fonctionnalités disponibles qui vous aident à créer, gérer et répondre aux alertes, et à améliorer la capacité de votre équipe à résoudre rapidement les problèmes.

Principes

Dans les systèmes d'alerte basés sur Prometheus, vous disposez d'un générateur d'alertes qui crée des alertes et d'un récepteur d'alertes qui reçoit les alertes. Par exemple, Prometheus est un générateur d'alertes chargé d'évaluer les règles d'alerte, tandis qu'Alertmanager est un récepteur d'alertes chargé de regrouper, d'inhiber, de désactiver et d'envoyer des notifications concernant le déclenchement et la résolution des alertes.

Grafana Alerting est basé sur le modèle Prometheus de conception de systèmes d'alerte. Il dispose d'un générateur d'alertes interne chargé de planifier et d'évaluer les règles d'alerte, ainsi que d'un récepteur d'alertes interne chargé de regrouper, d'inhiber, de désactiver et d'envoyer des notifications. Grafana n'utilise pas Prometheus comme générateur d'alertes car Grafana Alerting doit fonctionner avec de nombreuses autres sources de données en plus de Prometheus. Cependant, il utilise Alertmanager comme récepteur d'alertes.

Les alertes sont envoyées au récepteur d'alertes où elles sont acheminées, groupées, inhibées, réduites au silence et notifiées. Dans Grafana Alerting, le récepteur d'alerte par défaut est le gestionnaire d'alertes intégré à Grafana, appelé Grafana Alertmanager. Cependant, vous pouvez également utiliser d'autres gestionnaires d'alertes, appelés gestionnaires d'alertes externes.

Principes fondamentaux

Vous trouverez ci-dessous un aperçu des différentes parties de l'alerte Grafana.

Règles d'alerte

Une règle d'alerte est un ensemble de critères qui déterminent le moment où une alerte doit être déclenchée. Il comprend une ou plusieurs requêtes et expressions, une condition qui doit être remplie, un intervalle qui détermine la fréquence à laquelle la règle d'alerte est évaluée et une durée pendant laquelle la condition doit être remplie pour qu'une alerte se déclenche.

Les règles d'alerte sont évaluées sur leur intervalle, et chaque règle d'alerte peut être déclenchée par zéro, une ou plusieurs alertes à la fois. L'état de la règle d'alerte est déterminé par le niveau severe d'alerte le plus élevé, qui peut être normal, en attente ou en cours de déclenchement. Par exemple, si au moins une des alertes d'une règle d'alerte est déclenchée, la règle d'alerte est également déclenchée. L'état d'une règle d'alerte est déterminé par le statut de sa dernière évaluation. Elles peuvent être OK, Error et NoData.

Une caractéristique très importante des règles d'alerte est qu'elles prennent en charge les annotations et les étiquettes personnalisées. Ils vous permettent d'instrumenter les alertes à l'aide de métadonnées supplémentaires telles que des résumés et des descriptions, et d'ajouter des étiquettes supplémentaires pour acheminer les alertes vers des politiques de notification spécifiques.

Alerts (Alertes)

Les alertes sont identifiées de manière unique par des ensembles de paires clé/valeur appelés étiquettes. Chaque clé est un nom d'étiquette et chaque valeur est une valeur d'étiquette. Par exemple, une alerte peut avoir les étiquettes foo=bar et une autre les avoirfoo=baz. Une alerte peut avoir plusieurs étiquettes, par exemplefoo=bar,bar=baz, mais elle ne peut pas avoir deux fois la même étiquette, par exemplefoo=bar,foo=baz. Deux alertes ne peuvent pas non plus avoir les mêmes étiquettes, et si deux alertes ont les mêmes étiquettes, telles foo=bar,bar=baz que foo=bar,bar=baz et, l'une des alertes sera supprimée. Les alertes sont résolues lorsque la condition de la règle d'alerte n'est plus remplie ou lorsque la règle d'alerte est supprimée.

Dans Grafana Managed Alerts, les alertes peuvent être en état normal, en attente, en alerte, sans données ou en état d'erreur. Dans les alertes gérées par des sources de données, telles que Mimir et Loki, les alertes peuvent être en mode normal, en attente et en mode alerte, mais pas NoData ou en erreur.

Points de contact

Les points de contact déterminent où les notifications sont envoyées. Par exemple, vous pouvez avoir un point de contact qui envoie des notifications à une adresse e-mail, à Slack, à un système de gestion des incidents (IRM) tel que OnCall Grafana ou Pagerduty, ou à un webhook.

Les notifications envoyées depuis les points de contact peuvent être personnalisées à l'aide de modèles de notification. Vous pouvez utiliser des modèles de notification pour modifier le titre, le message et la structure de la notification. Les modèles de notification ne sont pas spécifiques à des intégrations ou à des points de contact individuels.

Politiques de notification

Les politiques de notification regroupent les alertes puis les acheminent vers les points de contact. Ils déterminent à quel moment les notifications sont envoyées et à quelle fréquence les notifications doivent être répétées.

Les alertes sont mises en correspondance avec les politiques de notification à l'aide de correcteurs d'étiquettes. Il s'agit d'expressions lisibles par l'homme qui indiquent si les libellés de l'alerte correspondent exactement, ne correspondent pas exactement, contiennent ou ne contiennent pas le texte attendu. Par exemple, le matcher fait foo=bar correspondre les alertes à l'étiquette foo=bar tandis qu'il foo=~[a-zA-Z]+ associe les alertes à n'importe quelle étiquette appelée foo dont la valeur correspond à l'expression régulière. [a-zA-Z]+

Par défaut, une alerte ne peut correspondre qu'à une seule politique de notification. Cependant, grâce à continue cette fonctionnalité, des alertes peuvent être créées pour correspondre à un certain nombre de politiques de notification en même temps. Pour plus d'informations sur les politiques de notification, consultez la section Politiques de notification.

Silences et temps de sourdine

Les silences et les durées de sourdine vous permettent de suspendre les notifications pour des alertes spécifiques ou même pour des politiques de notification complètes. Utilisez le silence pour suspendre les notifications de manière ponctuelle, par exemple lorsque vous travaillez sur le correctif d'une alerte, et utilisez le mode muet pour suspendre les notifications à intervalles réguliers, par exemple pendant les fenêtres de maintenance planifiées régulièrement.