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

Choisir comment, quand et où envoyer vos notifications d'alerte est un élément important de la configuration de votre système d'alerte. Ces décisions auront un impact direct sur votre capacité à résoudre les problèmes rapidement et à ne rien manquer d'important.

Dans un premier temps, définissez vos points de contact, qui définissent où envoyer vos notifications d'alerte. Un point de contact est un ensemble d'une ou de plusieurs intégrations utilisées pour envoyer des notifications. Ajoutez des modèles de notification aux points de contact afin de les réutiliser et de diffuser des messages cohérents dans vos notifications.

Créez ensuite une politique de notification qui est un ensemble de règles indiquant où, quand et comment vos alertes sont acheminées vers les points de contact. Dans une politique de notification, vous définissez où envoyer vos notifications d'alerte en choisissant l'un des points de contact que vous avez créés.

Gestionnaires d'alertes

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. Le Grafana Alertmanager utilise des politiques de notification et des points de contact pour configurer comment et où une notification est envoyée, à quelle fréquence une notification doit être envoyée et si les alertes doivent toutes être envoyées dans la même notification, envoyées dans des notifications groupées basées sur un ensemble d'étiquettes ou sous forme de notifications distinctes.

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 par défaut. Il ne peut y avoir qu'une seule stratégie par défaut et la stratégie par défaut 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 imbriquée peut avoir ses propres politiques imbriquées, ce qui permet une correspondance supplémentaire des alertes. Par exemple, une politique imbriquée peut être l'envoi d'alertes relatives à l'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 par défaut. Toutefois, lorsque la stratégie par défaut reçoit une alerte, elle examine chaque stratégie imbriquée et envoie l'alerte à la première stratégie imbriquée qui correspond à l'alerte. Si la stratégie imbriquée comporte d'autres politiques imbriquées, 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 stratégie elle-même est la stratégie correspondante. S'il n'existe aucune politique imbriquée ou si aucune politique imbriquée ne correspond à l'alerte, la stratégie par défaut est la stratégie correspondante.

Pour des informations plus détaillées sur les politiques de notification, consultezPolitiques de notification.

Modèles de notification

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 et se trouvent dans l'onglet Points de contact de la page Alertes.

Pour des informations plus détaillées sur la personnalisation des notifications, consultezPersonnaliser les notifications.

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.

Pour des informations plus détaillées sur l'utilisation des silences, consultezDésactiver les notifications d'alerte pour les sources de données Prometheus.