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.
Notifications
Cette rubrique de documentation est conçue pour les espaces de travail Grafana compatibles avec la version 9.x de Grafana.
Pour les espaces de travail Grafana compatibles avec la version 12.x de Grafana, voir. Travailler dans la version 12 de Grafana
Pour les espaces de travail Grafana compatibles avec la version 10.x de Grafana, voir. Travailler dans la version 10 de Grafana
Pour les espaces de travail Grafana compatibles avec la version 8.x de Grafana, voir. Travailler dans la version 8 de Grafana
Grafana utilise Alertmanagers pour envoyer des notifications en cas de déclenchement et de résolution d'alertes. Grafana possède son propre Alertmanager, appelé « Grafana » dans l'interface utilisateur, mais prend également en charge l'envoi de notifications depuis d'autres Alertmanagers, tels que le Prometheus Alertmanager.
Politiques de notification
Les politiques de notification contrôlent quand et où les notifications sont envoyées. Une politique de notification peut choisir d'envoyer toutes les alertes ensemble dans la même notification, d'envoyer les alertes sous forme de notifications groupées en fonction d'un ensemble d'étiquettes ou d'envoyer des alertes sous forme de notifications distinctes. Vous pouvez configurer chaque politique de notification pour contrôler la fréquence à laquelle les notifications doivent être envoyées, ainsi que pour désactiver les notifications à certains moments de la journée et certains jours de la semaine.
Les politiques de notification sont organisées dans une arborescence où, à la racine de l'arborescence, se trouve une politique de notification appelée politique racine. Il ne peut y avoir qu'une seule politique racine et la politique racine ne peut pas être supprimée.
Les politiques de routage spécifiques sont dérivées de la politique racine et peuvent être utilisées pour faire correspondre toutes les alertes ou un sous-ensemble d'alertes en fonction d'un ensemble d'étiquettes correspondantes. Une politique de notification correspond à une alerte lorsque ses libellés correspondants correspondent à ceux de l'alerte.
Une politique de routage spécifique peut avoir ses propres politiques secondaires, appelées politiques imbriquées, qui permettent une correspondance supplémentaire des alertes. Par exemple, une politique de routage spécifique peut consister à envoyer des alertes d'infrastructure à l'équipe des opérations, tandis qu'une politique secondaire peut envoyer des alertes prioritaires à Pagerduty et des alertes de faible priorité à Slack.
Toutes les alertes, quel que soit leur libellé, sont conformes à la politique racine. Toutefois, lorsque la politique racine reçoit une alerte, elle examine chaque stratégie de routage spécifique et envoie l'alerte à la première stratégie de routage spécifique correspondant à l'alerte. Si la politique de routage spécifique comporte d'autres politiques secondaires, elle peut tenter de faire correspondre l'alerte à l'une de ses politiques imbriquées. Si aucune politique imbriquée ne correspond à l'alerte, la politique de routage spécifique est la politique correspondante. S'il n'existe aucune politique de routage spécifique ou si aucune politique de routage spécifique ne correspond à l'alerte, la stratégie racine est la stratégie correspondante.
Points de contact
Les points de contact contiennent la configuration pour envoyer des notifications. Un point de contact est une liste d'intégrations, chacune d'entre elles envoyant une notification à une adresse e-mail, un service ou une URL en particulier. Les points de contact peuvent avoir plusieurs intégrations du même type ou une combinaison d'intégrations de différents types. Par exemple, un point de contact peut contenir une intégration Pager Duty, une intégration Pager Duty et Slack, ou une intégration Pager Duty, une intégration Slack et deux intégrations Amazon SNS. Vous pouvez également configurer un point de contact sans intégrations ; dans ce cas, aucune notification n'est envoyée.
Un point de contact ne peut pas envoyer de notifications tant qu'il n'a pas été ajouté à une politique de notification. Une politique de notification ne peut envoyer des alertes qu'à un seul point de contact, mais un point de contact peut être ajouté à plusieurs politiques de notification en même temps. Lorsqu'une alerte correspond à une politique de notification, l'alerte est envoyée au point de contact indiqué dans cette politique de notification, qui envoie ensuite une notification à chaque intégration dans sa configuration.
Note
Pour plus d'informations sur les intégrations prises en charge pour les points de contact, consultezPoints de contact.
Modèles de notifications
Vous pouvez personnaliser les notifications à l'aide de modèles. Par exemple, les modèles peuvent être utilisés pour modifier le titre et le message des notifications envoyées à Slack.
Les modèles ne se limitent pas à une intégration ou à un point de contact individuel, mais peuvent être utilisés dans un certain nombre d'intégrations au sein d'un même point de contact et même dans des intégrations entre différents points de contact. Par exemple, un utilisateur de Grafana peut créer un modèle appelé custom_subject_or_title et l'utiliser à la fois pour modéliser les sujets dans Pager Duty et les titres des messages Slack sans avoir à créer deux modèles distincts.
Tous les modèles de notifications sont rédigés dans le langage de modélisation de Go
Silences
Vous pouvez utiliser les silences pour désactiver les notifications relatives à une ou plusieurs règles de déclenchement. Les silences n'empêchent pas les alertes de se déclencher ou d'être résolues, ni ne masquent les alertes de déclenchement dans l'interface utilisateur. Un silence dure aussi longtemps que sa durée, qui peut être configurée en minutes, heures, jours, mois ou années.