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 10.x de Grafana.**
Pour les espaces de travail Grafana compatibles avec la version 9.x de Grafana, voir. [Travailler dans la version 9 de Grafana](using-grafana-v9.md)
Pour les espaces de travail Grafana compatibles avec la version 8.x de Grafana, voir. [Travailler dans la version 8 de Grafana](using-grafana-v8.md)
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](v10-alerting-explore-contacts.md), 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.](https://prometheus.io/docs/alerting/latest/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, consultez[Politiques de notification](v10-alerting-explore-notifications-policies-details.md).
## 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](https://pkg.go.dev/text/template) 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, consultez[Personnaliser les notifications](v10-alerting-manage-notifications.md).
## 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, consultez[Désactiver les notifications d'alerte](v10-alerting-silences.md).
# Politiques de notification
****
**Cette rubrique de documentation est conçue pour les espaces de travail Grafana qui prennent en charge la version 10.x de Grafana.**
Pour les espaces de travail Grafana compatibles avec la version 9.x de Grafana, voir. [Travailler dans la version 9 de Grafana](using-grafana-v9.md)
Pour les espaces de travail Grafana compatibles avec la version 8.x de Grafana, voir. [Travailler dans la version 8 de Grafana](using-grafana-v8.md)
Les politiques de notification vous offrent un moyen flexible d'acheminer les alertes vers différents destinataires. À l'aide des analyseurs d'étiquettes, vous pouvez modifier la diffusion des notifications d'alerte sans avoir à mettre à jour chaque règle d'alerte individuelle.
Dans cette section, vous en apprendrez davantage sur le fonctionnement et la structure des politiques de notification, afin de tirer le meilleur parti de la configuration de vos politiques de notification.
## Arborescence des politiques
Les politiques de notification *ne sont pas* une liste, mais sont structurées selon une structure arborescente. Cela signifie que chaque politique peut comporter des politiques relatives aux enfants, etc. La racine de l'arborescence des politiques de notification s'appelle la **stratégie de notification par défaut**.
Chaque politique consiste en un ensemble de correspondants d'étiquettes (0 ou plus) qui spécifient les étiquettes qu'elles souhaitent ou ne souhaitent pas gérer.
Pour plus d'informations sur la correspondance des étiquettes, consultez[Comment fonctionne la correspondance des étiquettes](v10-alerting-overview-labels-matching.md).
**Note**
Si vous n'avez configuré aucun outil de correspondance d'étiquettes pour votre politique de notification, celle-ci correspondra à *toutes les* instances d'alerte. Cela peut empêcher l'évaluation des politiques relatives aux enfants, sauf si vous avez activé l'option **Continuer à associer les frères et sœurs** dans la politique de notification.
## Routage
Pour déterminer quelle politique de notification gérera quelles instances d'alerte, vous devez commencer par examiner l'ensemble de politiques de notification existant, en commençant par la politique de notification par défaut.
Si aucune politique autre que la stratégie par défaut n'est configurée, la stratégie par défaut gérera l'instance d'alerte.
Si des politiques autres que la politique par défaut sont définies, il évaluera ces politiques de notification dans l'ordre dans lequel elles sont affichées.
Si une politique de notification comporte des indicateurs d'étiquettes qui correspondent aux libellés de l'instance d'alerte, elle passe aux politiques relatives aux enfants et, le cas échéant, continue à rechercher les politiques relatives aux enfants susceptibles d'avoir des critères de correspondance permettant de restreindre davantage le jeu d'étiquettes, et ainsi de suite jusqu'à ce qu'aucune autre politique relative aux enfants ne soit trouvée.
Si aucune politique enfant n'est définie dans une stratégie de notification ou si aucune des politiques enfant ne possède de correspondance d'étiquettes correspondant aux étiquettes de l'instance d'alerte, la stratégie de notification parent est utilisée.
Dès qu'une politique correspondante est trouvée, le système ne continue pas à rechercher d'autres politiques correspondantes. Si vous souhaitez continuer à rechercher d'autres politiques susceptibles de correspondre, activez **Continuer à associer les frères et sœurs à** cette politique en particulier.
Enfin, si aucune des politiques de notification n'est sélectionnée, la politique de notification par défaut est utilisée.
### Exemple de routage
Voici un exemple d'arborescence de politiques de notification relativement simple et de quelques instances d'alerte.
![\[Image illustrant un ensemble de politiques de notification dans une arborescence, ainsi qu'un ensemble d'instances d'alerte avec différentes étiquettes correspondant aux politiques.\]](http://docs.aws.amazon.com/fr_fr/grafana/latest/userguide/images/notification-routing.png)
Voici un aperçu de la manière dont ces politiques sont sélectionnées :
**Pod stuck in CrashLoop** ne possède pas d'`severity`étiquette, donc aucune de ses politiques relatives aux enfants ne correspond. Il possède une `team=operations` étiquette, de sorte que la première politique correspond.
La `team=security` politique n'est pas évaluée car nous avons déjà trouvé une correspondance et l'option **Continuer à faire correspondre les frères et sœurs** n'a pas été configurée pour cette politique.
**Utilisation du disque : 80 %** possèdent à la fois une `severity` étiquette `team` et et correspondent à une politique relative aux enfants définie par l'équipe des opérations.
Une **entrée de journal non autorisée** possède une `team` étiquette mais ne correspond pas à la première politique (`team=operations`) car les valeurs ne sont pas les mêmes. La recherche sera donc poursuivie et correspondra à la `team=security` politique. Il n'a aucune politique relative aux enfants, de sorte que l'`severity=high`étiquette supplémentaire est ignorée.
## Héritage
Outre le fait que les politiques enfants constituent un concept utile pour le routage des instances d'alerte, elles héritent également des propriétés de leur politique parent. Cela s'applique également à toutes les politiques qui sont des politiques secondaires de la politique de notification par défaut.
Les propriétés suivantes sont héritées par les politiques relatives aux enfants :
+ Point de contact
+ Options de regroupement
+ Options de chronométrage
+ Horaire du mode muet
Chacune de ces propriétés peut être remplacée par une politique individuelle si vous souhaitez remplacer les propriétés héritées.
Pour hériter d'un point de contact de la politique parent, laissez ce champ vide. Pour annuler les options de regroupement héritées, activez l'option **Remplacer** le regroupement. Pour annuler les options de chronométrage héritées, activez l'option Annuler **les horaires généraux**.
### Exemple d'héritage
L'exemple ci-dessous montre comment l'arborescence des politiques de notification de notre exemple précédent permet aux politiques enfants du d'`team=operations`hériter de son point de contact.
De cette façon, nous pouvons éviter d'avoir à spécifier plusieurs fois le même point de contact pour chaque politique relative aux enfants.
![\[Image illustrant un ensemble de politiques de notification dans une arborescence, avec des points de contact affectés à certaines politiques, mais certaines politiques relatives aux enfants héritant des points de contact de leurs parents au lieu de définir les leurs.\]](http://docs.aws.amazon.com/fr_fr/grafana/latest/userguide/images/notification-inheritance.png)
## Options de configuration supplémentaires
### Regroupement
Le regroupement est une fonctionnalité importante de Grafana Alerting car il vous permet de regrouper les alertes pertinentes en un plus petit nombre de notifications. Cela est particulièrement important si les notifications sont envoyées aux premiers intervenants, tels que les ingénieurs de garde, où la réception d'un grand nombre de notifications en peu de temps peut être accablante et, dans certains cas, peut avoir un impact négatif sur la capacité des premiers intervenants à répondre à un incident. Par exemple, imaginez une panne importante au cours de laquelle un grand nombre de vos systèmes sont en panne. Dans ce cas, le regroupement peut faire la différence entre la réception d'un appel téléphonique et de 100 appels téléphoniques.
Vous choisissez la manière dont les alertes sont regroupées à l'aide de l'option Regrouper par dans une politique de notification. Par défaut, les politiques de notification de Grafana regroupent les alertes par règle d'alerte en utilisant les `grafana_folder` étiquettes `alertname` et (car les noms des alertes ne sont pas uniques dans plusieurs dossiers). Si vous souhaitez regrouper les alertes selon une autre méthode que la règle d'alerte, remplacez le regroupement par une autre combinaison d'étiquettes.
#### Désactiver le regroupement
Si vous souhaitez recevoir chaque alerte sous forme de notification séparée, vous pouvez le faire en les regroupant par une étiquette spéciale appelée`...`. Cela est utile lorsque vos alertes sont transmises à un système automatisé plutôt qu'à un premier intervenant.
#### Un seul groupe pour toutes les alertes
Si vous souhaitez recevoir toutes les alertes dans une seule notification, vous pouvez le faire en laissant le champ Groupe vide.
### Options de chronométrage
Les options de synchronisation déterminent la fréquence d'envoi des notifications pour chaque groupe d'alertes. Il existe trois minuteries que vous devez connaître : l'attente de groupe, l'intervalle de groupe et l'intervalle de répétition.
#### Attente en groupe
L'attente de groupe est le temps que Grafana attend avant d'envoyer la première notification pour un nouveau groupe d'alertes. Plus l'attente du groupe est longue, plus vous avez de temps pour que les autres alertes arrivent. Plus l'attente du groupe est courte, plus la première notification sera envoyée tôt, mais au risque d'envoyer des notifications incomplètes. Vous devez toujours choisir l'attente de groupe la plus adaptée à votre cas d'utilisation.
**Par défaut** : 30 secondes
#### Intervalle de groupe
Une fois que la première notification a été envoyée pour un nouveau groupe d'alertes, Grafana lance le chronomètre de groupe. Il s'agit du temps que Grafana attend avant d'envoyer des notifications concernant les modifications apportées au groupe. Par exemple, une autre alerte de déclenchement vient peut-être d'être ajoutée au groupe alors qu'une alerte existante a peut-être été résolue. Si une alerte est arrivée trop tard pour être incluse dans la première notification en raison de l'attente du groupe, elle sera incluse dans les notifications suivantes après l'intervalle de groupe. Une fois l'intervalle de groupe écoulé, Grafana réinitialise le temporisateur d'intervalle de groupe. Cela se répète jusqu'à ce qu'il n'y ait plus d'alertes dans le groupe, après quoi le groupe est supprimé.
**Par défaut** : 5 minutes
#### Intervalle de répétition
L'intervalle de répétition détermine la fréquence à laquelle les notifications sont répétées si le groupe n'a pas changé depuis la dernière notification. Vous pouvez les considérer comme des rappels indiquant que certaines alertes sont toujours en cours de déclenchement. L'intervalle de répétition est étroitement lié à l'intervalle de groupe, ce qui signifie que votre intervalle de répétition doit non seulement être supérieur ou égal à l'intervalle de groupe, mais également être un multiple de l'intervalle de groupe. Si l'intervalle de répétition n'est pas un multiple de l'intervalle de groupe, il sera réduit à un. Par exemple, si votre intervalle de groupe est de 5 minutes et que votre intervalle de répétition est de 9 minutes, l'intervalle de répétition sera arrondi au multiple de 5 le plus proche, soit 10 minutes.
**Par défaut** : 4 heures