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.
# Découvrir les alertes
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
Que vous commenciez ou étendiez votre implémentation de Grafana Alerting, découvrez les concepts clés et les fonctionnalités disponibles qui vous aident à créer, gérer et agir sur vos alertes et à améliorer la capacité de votre équipe à résoudre rapidement les problèmes.
Tout d'abord, examinons les différents types de règles d'alerte proposés par Grafana Alerting.
## Types de règles d'alerte
**Règles gérées par Grafana**
Les règles gérées par Grafana constituent le type de règle d'alerte le plus flexible. Ils vous permettent de créer des alertes qui peuvent agir sur les données provenant de l'une de nos sources de données prises en charge. Outre la prise en charge de plusieurs sources de données, vous pouvez également ajouter des expressions pour transformer vos données et définir des conditions d'alerte. Il s'agit du seul type de règle qui permet d'émettre des alertes à partir de plusieurs sources de données dans une seule définition de règle.
**Règles de Mimir et Loki**
Pour créer des alertes Mimir ou Loki, vous devez disposer d'une source de données Prometheus ou Loki compatible. Vous pouvez vérifier si votre source de données prend en charge la création de règles via Grafana en testant la source de données et en observant si l'API des règles est prise en charge.
**Règles d'enregistrement**
Les règles d'enregistrement ne sont disponibles que pour les sources de données Prometheus ou Loki compatibles. Une règle d'enregistrement vous permet de précalculer des expressions fréquemment nécessaires ou coûteuses en termes de calcul et d'enregistrer leur résultat sous la forme d'un nouvel ensemble de séries chronologiques. Cela est utile si vous souhaitez exécuter des alertes sur des données agrégées ou si vous disposez de tableaux de bord qui interrogent à plusieurs reprises des expressions coûteuses en termes de calcul.
## Concepts et fonctionnalités clés
Le tableau suivant inclut une liste des concepts clés, des fonctionnalités et de leurs définitions, conçus pour vous aider à tirer le meilleur parti de Grafana Alerting.
| Concept ou fonctionnalité clé | Définition |
| --- | --- |
| Sources de données pour les alertes | Sélectionnez les sources de données que vous souhaitez interroger et visualisez les métriques, les journaux et les traces à partir desquelles vous souhaitez effectuer des recherches. |
| Provisionnement pour les alertes | Gérez vos ressources d'alerte et approvisionnez-les dans votre système Grafana à l'aide du provisionnement de fichiers ou de Terraform. |
| Gestionnaire d'alertes | Gère le routage et le regroupement des instances d'alerte. |
| Règle d'alerte | Ensemble de critères d'évaluation indiquant à quel moment une règle d'alerte doit être déclenchée. Une règle d'alerte comprend une ou plusieurs requêtes et expressions, une condition, la fréquence d'évaluation et la durée pendant laquelle la condition est remplie. Une règle d'alerte peut produire plusieurs instances d'alerte. |
| Instance d'alerte | Une instance d'alerte est une instance d'une règle d'alerte. Une règle d'alerte unidimensionnelle possède une instance d'alerte. Une règle d'alerte multidimensionnelle comporte une ou plusieurs instances d'alerte. Une seule règle d'alerte qui correspond à plusieurs résultats, tels que le nombre de processeurs par rapport à 10 VMs, est comptée comme plusieurs instances d'alerte (dans ce cas 10). Ce nombre peut varier au fil du temps. Par exemple, une règle d'alerte qui surveille l'utilisation du processeur pour tous les VMs membres d'un système comporte davantage d'instances d'alerte au fur et à mesure qu' VMs elles sont ajoutées. Pour plus d'informations sur les quotas d'instance d'alerte, consultez. [Erreurs liées au quota atteint](v9-alerting-managerules-grafana.md#v9-alerting-rule-quota-reached) |
| Groupe d'alertes | L'Alertmanager regroupe les instances d'alerte par défaut en utilisant les étiquettes de la politique de notification racine. Cela permet de contrôler la déduplication et les groupes d'instances d'alerte, qui sont envoyés aux points de contact. |
| Point de contact | Définissez la manière dont vos contacts sont avertis lorsqu'une règle d'alerte est déclenchée. |
| Modélisation de messages | Créez des modèles personnalisés réutilisables et utilisez-les dans les points de contact. |
| Politique de notification | Ensemble de règles indiquant où, quand et comment les alertes sont regroupées et acheminées vers les points de contact. |
| Étiquettes et dispositifs d'appariement | Les étiquettes identifient de manière unique les règles d'alerte. Ils relient les règles d'alerte aux politiques de notification et aux silences, afin de déterminer quelle politique doit les gérer et quelles règles d'alerte doivent être réduites au silence. |
| Silences | Arrêtez les notifications provenant d'une ou de plusieurs instances d'alerte. La différence entre un temps de silence et un temps de sourdine est qu'un silence ne dure que pendant une période spécifiée, alors qu'un temps de silence est censé être récurrent selon un calendrier. Utilise des analyseurs d'étiquettes pour désactiver les instances d'alerte. |
| Horaire du mode muet | Spécifiez un intervalle de temps pendant lequel vous ne souhaitez pas que de nouvelles notifications soient générées ou envoyées. Vous pouvez également geler les notifications d'alerte pour des périodes récurrentes, par exemple pendant une période de maintenance. Doit être lié à une politique de notification existante. |
# Sources de données
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
Un certain nombre de [sources de données](AMG-data-sources-builtin.md) sont compatibles avec Grafana Alerting. Chaque source de données est prise en charge par un plugin. Vous pouvez utiliser l'une des sources de données intégrées répertoriées ci-dessous.
Il s'agit des sources de données compatibles et prises en charge par Amazon Managed Grafana.
+ [Se connecter à une source de données Alertmanager](data-source-alertmanager.md)
+ [Connect à une source de CloudWatch données Amazon](using-amazon-cloudwatch-in-AMG.md)
+ [Connectez-vous à une source OpenSearch de données Amazon Service](using-Amazon-OpenSearch-in-AMG.md)
+ [Se connecter à une source AWS IoT SiteWise de données](using-iotsitewise-in-AMG.md)
+ [Se connecter à une source AWS IoT TwinMaker de données](AMG-iot-twinmaker.md)
+ [Connectez-vous à Amazon Managed Service for Prometheus et aux sources de données open source Prometheus](prometheus-data-source.md)
+ [Connectez-vous à une source de données Amazon Timestream](timestream-datasource.md)
+ [Connectez-vous à une source de données Amazon Athena](AWS-Athena.md)
+ [Connectez-vous à une source de données Amazon Redshift](AWS-Redshift.md)
+ [Se connecter à une source AWS X-Ray de données](x-ray-data-source.md)
+ [Connectez-vous à une source de données Azure Monitor](using-azure-monitor-in-AMG.md)
+ [Connectez-vous à une source de données Google Cloud Monitoring](using-google-cloud-monitoring-in-grafana.md)
+ [Connectez-vous à une source de données Graphite](using-graphite-in-AMG.md)
+ [Connect à une source de données InfluxDB](using-influxdb-in-AMG.md)
+ [Se connecter à une source de données Loki](using-loki-in-AMG.md)
+ [Connectez-vous à une source de données Microsoft SQL Server](using-microsoft-sql-server-in-AMG.md)
+ [Connect à une source de données MySQL](using-mysql-in-AMG.md)
+ [Connectez-vous à une source de données OpenTSDB](using-opentsdb-in-AMG.md)
+ [Connect à une source de données PostgreSQL](using-postgresql-in-AMG.md)
+ [Connectez-vous à une source de données Jaeger](jaeger-data-source.md)
+ [Connect à une source de données Zipkin](zipkin-data-source.md)
+ [Connectez-vous à une source de données Tempo](tempo-data-source.md)
+ [Configuration d'une source TestData de données à des fins de test](testdata-data-source.md)
# À propos des règles d'alerte
****
**Cette rubrique de documentation est conçue pour les espaces de travail Grafana qui prennent en charge la version 9.x de Grafana.**
Pour les espaces de travail Grafana compatibles avec la version 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
Une règle d'alerte est un ensemble de critères d'évaluation qui déterminent si une instance d'alerte va se déclencher. La règle comprend une ou plusieurs requêtes et expressions, une condition, la fréquence d'évaluation et, éventuellement, la durée pendant laquelle la condition est remplie.
Alors que les requêtes et les expressions sélectionnent l'ensemble de données à évaluer, une condition définit le seuil qu'une alerte doit atteindre ou dépasser pour créer une alerte.
Un intervalle indique la fréquence à laquelle une règle d'alerte est évaluée. La durée, lorsqu'elle est configurée, indique la durée pendant laquelle une condition doit être remplie. Les règles d'alerte peuvent également définir le comportement des alertes en l'absence de données.
**Topics**
+ [Types de règles d'alerte](v9-alerting-explore-rules-types.md)
+ [Instances d'alerte](v9-alerting-rules-instances.md)
+ [Espaces de noms et groupes](v9-alerting-rules-grouping.md)
+ [Modèle de notification](v9-alerting-rules-notification-templates.md)
# Types de règles d'alerte
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
Grafana prend en charge plusieurs types de règles d'alerte. Les sections suivantes expliqueront leurs avantages et leurs inconvénients et vous aideront à choisir le type d'alerte adapté à votre cas d'utilisation.
Règles gérées par Grafana
Les règles gérées par Grafana constituent le type de règle d'alerte le plus flexible. Ils vous permettent de créer des alertes qui peuvent agir sur les données provenant de n'importe laquelle de vos sources de données existantes.
En plus de prendre en charge n'importe quelle source de données, vous pouvez ajouter [des expressions](v9-panels-query-xform-expressions.md) pour transformer vos données et exprimer les conditions d'alerte.
Règles de Mimir, Loki et Cortex
Pour créer des alertes Mimir, Loki ou Cortex, vous devez disposer d'une source de données Prometheus compatible. Vous pouvez vérifier si votre source de données est compatible en la testant et en vérifiant dans les détails si l'API Ruler est prise en charge.
Règles d'enregistrement
Les règles d'enregistrement ne sont disponibles que pour les sources de données Prometheus compatibles telles que Mimir, Loki et Cortex.
Une règle d'enregistrement vous permet d'enregistrer le résultat d'une expression dans un nouvel ensemble de séries chronologiques. Cela est utile si vous souhaitez exécuter des alertes sur des données agrégées ou si vous avez des tableaux de bord qui demandent la même expression à plusieurs reprises.
En savoir plus sur les [règles d'enregistrement](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) dans Prometheus.
# Instances d'alerte
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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 alertes gérées par Grafana prennent en charge les alertes multidimensionnelles. Chaque règle d'alerte peut créer plusieurs instances d'alerte. C'est très utile si vous observez plusieurs séries dans une seule expression.
Considérez l'expression ProMQL suivante :
```
sum by(cpu) (
rate(node_cpu_seconds_total{mode!="idle"}[1m])
)
```
Une règle utilisant cette expression créera autant d'instances d'alerte que le nombre d'alertes CPUs observé lors de l'évaluation, permettant à une seule règle de signaler l'état de chaque processeur.
# Espaces de noms et groupes
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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 alertes peuvent être organisées à l'aide de dossiers pour les règles gérées par Grafana et d'espaces de noms pour les règles et les noms de groupes Mimir, Loki ou Prometheus.
**Espaces de noms**
Lors de la création de règles gérées par Grafana, le dossier peut être utilisé pour contrôler l'accès et accorder ou refuser l'accès à toutes les règles d'un dossier spécifique.
**Groups** (Groupes)
Toutes les règles d'un groupe sont évaluées au même **intervalle**.
Les règles d'alerte et les règles d'enregistrement au sein d'un groupe seront toujours évaluées de **manière séquentielle**, ce qui signifie qu'aucune règle ne sera évaluée en même temps et par ordre d'apparition.
**Astuce**
Si vous souhaitez que les règles soient évaluées simultanément et à des intervalles différents, pensez à les stocker dans différents groupes.
# Modèle de notification
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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 notifications envoyées via les points de contact sont créées à l'aide de modèles de notification. Les modèles par défaut de Grafana sont basés sur le [système de modèles Go dans](https://golang.org/pkg/text/template) lequel certains champs sont évalués sous forme de texte, tandis que d'autres sont évalués sous forme de HTML (ce qui peut affecter l'évasion).
Le modèle par défaut [default\$1template.go](https://github.com/grafana/alerting/blob/main/templates/default_template.go) est une référence utile pour les modèles personnalisés.
Comme la plupart des champs des points de contact peuvent être modélisés, vous pouvez créer des modèles personnalisés réutilisables et les utiliser dans plusieurs points de contact. Pour en savoir plus sur les notifications personnalisées à l'aide de modèles, consultez[Personnaliser les notifications](v9-alerting-notifications.md).
**Modèles imbriqués**
Vous pouvez intégrer des modèles dans d'autres modèles.
Par exemple, vous pouvez définir un fragment de modèle à l'aide du `define` mot clé.
```
{{ define "mytemplate" }}
{{ len .Alerts.Firing }} firing. {{ len .Alerts.Resolved }} resolved.
{{ end }}
```
Vous pouvez ensuite intégrer des modèles personnalisés dans ce fragment à l'aide du `template` mot clé. Par exemple :
```
Alert summary:
{{ template "mytemplate" . }}
```
Vous pouvez utiliser l'une des options de modèle intégrées suivantes pour intégrer des modèles personnalisés.
| Nom | Remarques |
| --- | --- |
| `default.title` | Affiche des informations d'état de haut niveau. |
| `default.message` | Fournit un résumé formaté des alertes déclenchées et résolues. |
| `teams.default.message` | Similaire à`default.messsage`, formaté pour Microsoft Teams. |
**HTML dans les modèles de notification**
Le code HTML des modèles de notification d'alerte est évité. Nous ne prenons pas en charge le rendu du code HTML dans la notification qui en résulte.
Certains notificateurs proposent d'autres méthodes pour modifier l'apparence de la notification qui en résulte. Par exemple, Grafana installe le modèle de base pour envoyer des alertes aux e-mails. `/public/emails/ng_alert_notification.html` Vous pouvez modifier ce fichier pour modifier l'apparence de tous les e-mails d'alerte.
# Alertes sur les données numériques
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
Cette rubrique décrit comment Grafana gère les alertes basées sur des données numériques plutôt que sur des séries chronologiques.
Parmi certaines sources de données, les données numériques qui ne sont pas des séries chronologiques peuvent être directement alertées ou transmises aux expressions côté serveur (SSE). Cela permet d'améliorer le traitement et l'efficacité qui en résulte au sein de la source de données, tout en simplifiant les règles d'alerte. Lorsque vous lancez une alerte sur des données numériques plutôt que sur des données de séries chronologiques, il n'est pas nécessaire de réduire chaque série chronologique étiquetée en un seul chiffre. Au lieu de cela, les numéros étiquetés sont renvoyés à Grafana.
**Données tabulaires**
Cette fonctionnalité est prise en charge par les sources de données principales qui interrogent des données tabulaires :
+ Sources de données SQL telles que MySQL, Postgres, MSSQL et Oracle.
+ Les services basés sur Azure Kusto : Azure Monitor (Logs), Azure Monitor (Azure Resource Graph) et Azure Data Explorer.
Une requête avec des alertes gérées par Grafana ou SSE est considérée comme numérique avec ces sources de données, si :
+ L'option « Format AS » est définie sur « Table » dans la requête de source de données.
+ La réponse de table renvoyée à Grafana par la requête inclut une seule colonne numérique (par exemple int, double, float) et éventuellement des colonnes de chaîne supplémentaires.
S'il existe des colonnes de chaînes, ces colonnes deviennent des étiquettes. Le nom de la colonne devient le nom de l'étiquette, et la valeur de chaque ligne devient la valeur de l'étiquette correspondante. Si plusieurs lignes sont renvoyées, chaque ligne doit être identifiée de manière unique avec son étiquette.
**Exemple**
Pour une table MySQL appelée « DiskSpace » :
| Heure | Host (Hôte) | Disk | PercentFree |
| --- | --- | --- | --- |
| 7 juin 2021 | web1 | /etc | 3 |
| 7 juin 2021 | web2 | /var | 4 |
| 7 juin 2021 | web3 | /var | 8 |
| ... | ... | ... | ... |
Vous pouvez interroger le filtrage des données à temps, mais sans renvoyer les séries chronologiques à Grafana. Par exemple, une alerte qui se déclencherait par hôte et par disque lorsqu'il y a moins de 5 % d'espace libre :
```
SELECT Host , Disk , CASE WHEN PercentFree < 5.0 THEN PercentFree ELSE 0 END FROM (
SELECT
Host,
Disk,
Avg(PercentFree)
FROM DiskSpace
Group By
Host,
Disk
Where __timeFilter(Time)
```
Cette requête renvoie la réponse de table suivante à Grafana :
| Host (Hôte) | Disk | PercentFree |
| --- | --- | --- |
| web1 | /etc | 3 |
| web2 | /var | 4 |
| web3 | /var | 0 |
Lorsque cette requête est utilisée comme **condition** dans une règle d'alerte, une valeur différente de zéro sera signalée. Par conséquent, trois instances d'alerte sont produites :
| Étiquettes | Statut |
| --- | --- |
| \$1Host=Web1, disk=/etc\$1 | Alerte |
| \$1Host=Web2, disk=/var\$1 | Alerte |
| \$1Host=Web3, disk=/var\$1 | Normal |
# Étiquettes et annotations
****
**Cette rubrique de documentation est conçue pour les espaces de travail Grafana qui prennent en charge la version 9.x de Grafana.**
Pour les espaces de travail Grafana compatibles avec la version 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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 étiquettes et les annotations contiennent des informations sur une alerte. Les étiquettes et les annotations ont la même structure : un ensemble de valeurs nommées, mais leurs utilisations prévues sont différentes. Un exemple d'étiquette, ou d'annotation équivalente, pourrait être`alertname="test"`.
La principale différence entre une étiquette et une annotation est que les étiquettes sont utilisées pour différencier une alerte de toutes les autres alertes, tandis que les annotations sont utilisées pour ajouter des informations supplémentaires à une alerte existante.
Par exemple, considérez deux alertes de niveau élevé du processeur : une pour `server1` et une autre pour`server2`. Dans un tel exemple, nous pourrions avoir une étiquette appelée `server` où la première alerte possède l'étiquette `server="server1"` et la deuxième alerte possède l'étiquette`server="server2"`. Cependant, nous souhaiterons peut-être également ajouter une description à chaque alerte`"The CPU usage for server1 is above 75%."`, par exemple où `server1` et où `75%` sont remplacés par le nom et l'utilisation du processeur du serveur (veuillez consulter la documentation [Création de modèles d'étiquettes et d'annotations](v9-alerting-explore-labels-templating.md) pour savoir comment procéder). Ce type de description serait plus approprié sous forme d'annotation.
## Étiquettes
Les étiquettes contiennent des informations qui identifient une alerte. Un exemple d'étiquette pourrait être`server=server1`. Chaque alerte peut avoir plusieurs étiquettes, et l'ensemble complet d'étiquettes d'une alerte est appelé son ensemble d'étiquettes. C'est ce jeu d'étiquettes qui identifie l'alerte.
Par exemple, une alerte peut avoir l'étiquette définie `{alertname="High CPU usage",server="server1"}` alors qu'une autre alerte peut avoir l'étiquette définie`{alertname="High CPU usage",server="server2"}`. Il s'agit de deux alertes distinctes, car même si leurs `alertname` étiquettes sont identiques, elles sont différentes. `server`
L'étiquette définie pour une alerte est une combinaison des étiquettes de la source de données, des étiquettes personnalisées de la règle d'alerte et d'un certain nombre d'étiquettes réservées telles que`alertname`.
**Étiquettes personnalisées**
Les libellés personnalisés sont des libellés supplémentaires issus de la règle d'alerte. Tout comme les annotations, les étiquettes personnalisées doivent avoir un nom, et leur valeur peut contenir une combinaison de texte et de code modèle qui est évalué lorsqu'une alerte est déclenchée. La documentation sur la façon de modéliser des étiquettes personnalisées est disponible [ici](v9-alerting-explore-labels-templating.md).
Lorsque vous utilisez des étiquettes personnalisées avec des modèles, il est important de veiller à ce que la valeur de l'étiquette ne change pas entre les évaluations consécutives de la règle d'alerte, car cela finira par créer un grand nombre d'alertes distinctes. Cependant, le modèle peut générer différentes valeurs d'étiquette pour différentes alertes. Par exemple, ne mettez pas la valeur de la requête dans une étiquette personnalisée car cela finira par créer un nouvel ensemble d'alertes chaque fois que la valeur change. Utilisez plutôt des annotations.
Il est également important de s'assurer que l'étiquette définie pour une alerte ne comporte pas deux étiquettes ou plus portant le même nom. Si une étiquette personnalisée porte le même nom qu'une étiquette de la source de données, elle remplacera cette étiquette. Toutefois, si une étiquette personnalisée porte le même nom qu'une étiquette réservée, l'étiquette personnalisée sera omise de l'alerte.
## Annotations
Les annotations sont des paires nommées qui ajoutent des informations supplémentaires aux alertes existantes. Il existe un certain nombre d'annotations suggérées dans Grafana`summary`, `description` telles que,`runbook_url`, `dashboardUId` et. `panelId` Tout comme les étiquettes personnalisées, les annotations doivent avoir un nom, et leur valeur peut contenir une combinaison de texte et de code modèle qui est évalué lorsqu'une alerte est déclenchée. Si une annotation contient un code de modèle, le modèle est évalué une seule fois lorsque l'alerte est déclenchée. Elle n'est pas réévaluée, même lorsque l'alerte est résolue. La documentation sur la façon de modéliser des annotations est disponible [ici](v9-alerting-explore-labels-templating.md).
# Comment fonctionne la correspondance des étiquettes
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
Utilisez des étiquettes et des marqueurs d'étiquettes pour lier les règles d'alerte aux politiques de notification et aux silences. Cela permet de gérer vos instances d'alerte de manière très flexible, de spécifier la politique qui doit les gérer et les alertes à désactiver.
Un analyseur d'étiquettes se compose de 3 parties distinctes : l'**étiquette**, la **valeur** et l'**opérateur**.
+ Le champ **Label** est le nom de l'étiquette à associer. Il doit correspondre exactement au nom de l'étiquette.
+ Le champ **Valeur** correspond à la valeur correspondante pour le nom d'**étiquette** spécifié. La correspondance dépend de la valeur de l'**opérateur**.
+ Le champ **Opérateur** est l'opérateur à comparer à la valeur de l'étiquette. Les opérateurs disponibles sont les suivants :
| Opérateur | Description |
| --- | --- |
| `=` | Sélectionnez des étiquettes exactement égales à la valeur. |
| `!=` | Sélectionnez des étiquettes qui ne sont pas égales à la valeur. |
| `=~` | Sélectionnez les libellés qui correspondent à la valeur par regex. |
| `!~` | Sélectionnez les libellés qui ne correspondent pas à la valeur par regex. |
Si vous utilisez plusieurs correspondants d'étiquettes, ils sont combinés à l'aide de l'opérateur logique AND. Cela signifie que tous les matchers doivent correspondre pour lier une règle à une politique.
**Exemple de scénario**
Si vous définissez le jeu d'étiquettes suivant pour votre alerte :
```
{ foo=bar, baz=qux, id=12 }
```
puis :
+ Un comparateur d'étiquettes défini comme `foo=bar` correspond à cette règle d'alerte.
+ Un comparateur d'étiquettes défini comme `foo!=bar` ne correspond *pas* à cette règle d'alerte.
+ Un comparateur d'étiquettes défini comme `id=~[0-9]+` correspond à cette règle d'alerte.
+ Un comparateur d'étiquettes défini comme `baz!~[0-9]+` correspond à cette règle d'alerte.
+ Deux marqueurs d'étiquettes définis `foo=bar` et conformes à `id=~[0-9]+` cette règle d'alerte.
# Étiquettes dans Grafana Alerting
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
Cette rubrique explique pourquoi les étiquettes sont un élément fondamental des alertes.
+ L'ensemble complet d'étiquettes pour une alerte est ce qui identifie de manière unique une alerte dans les alertes Grafana.
+ Le gestionnaire d'alertes utilise des étiquettes pour faire correspondre les alertes relatives aux silences et aux groupes d'alertes dans les politiques de notification.
+ L'interface utilisateur d'alerte affiche des étiquettes pour chaque instance d'alerte générée lors de l'évaluation de cette règle.
+ Les points de contact peuvent accéder aux étiquettes pour générer dynamiquement des notifications contenant des informations spécifiques à l'alerte qui entraîne une notification.
+ Vous pouvez ajouter des libellés à une [règle d'alerte](v9-alerting-managerules.md). Les étiquettes sont configurables manuellement, utilisent des fonctions de modèle et peuvent faire référence à d'autres étiquettes. Les étiquettes ajoutées à une règle d'alerte ont priorité en cas de collision entre étiquettes (sauf dans le cas des étiquettes réservées Grafana, voir ci-dessous pour plus d'informations).
**Compatibilité avec Alertmanager externe**
Le gestionnaire d'alertes intégré de Grafana prend en charge à la fois les clés et les valeurs d'étiquette Unicode. [Si vous utilisez un Prometheus Alertmanager externe, les clés d'étiquette doivent être compatibles avec leur modèle de données.](https://prometheus.io/docs/concepts/data_model/#metric-names-and-labels) Cela signifie que les clés d'étiquette ne doivent contenir que des **lettres ASCII, des** **chiffres** et des traits de **soulignement** et correspondre à l'expression régulière. `[a-zA-Z_][a-zA-Z0-9_]*` Tout caractère non valide sera supprimé ou remplacé par le moteur d'alerte Grafana avant d'être envoyé au gestionnaire d'alertes externe conformément aux règles suivantes :
+ `Whitespace`sera supprimé.
+ `ASCII characters`sera remplacé par`_`.
+ `All other characters`seront remplacés par leur représentation hexadécimale en minuscules. S'il s'agit du premier caractère, il sera préfixé par`_`.
**Note**
Si plusieurs clés d'étiquette sont nettoyées à la même valeur, les doublons porteront un court hachage de l'étiquette d'origine ajouté en tant que suffixe.
**Étiquettes réservées Grafana**
**Note**
Les étiquettes préfixées par `grafana_` sont réservées par Grafana pour un usage spécial. Si une étiquette configurée manuellement est ajoutée en commençant par `grafana_` celle-ci, elle peut être remplacée en cas de collision.
Les étiquettes réservées Grafana peuvent être utilisées de la même manière que les étiquettes configurées manuellement. La liste actuelle des labels réservés disponibles est la suivante :
| Étiquette | Description |
| --- | --- |
| dossier grafana | Titre du dossier contenant l'alerte. |
# Création de modèles d'étiquettes et d'annotations
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
Dans Grafana, vous modélisez des étiquettes et des annotations comme vous le feriez dans Prometheus. Si vous avez déjà utilisé Prometheus, vous devez connaître les variables `$value` et, qui contiennent `$labels` les libellés et la valeur de l'alerte. Vous pouvez utiliser les mêmes variables dans Grafana, même si l'alerte n'utilise pas de source de données Prometheus. Si vous n'avez jamais utilisé Prometheus auparavant, ne vous inquiétez pas, car chacune de ces variables et la façon de les modéliser seront expliquées dans le reste de cette page.
## Le langage de modélisation de Go
[Les modèles d'étiquettes et d'annotations sont écrits dans le langage de création de modèles de Go, texte/modèle.](https://pkg.go.dev/text/template)
**Étiquettes d'ouverture et de fermeture**
Dans le texte/le modèle, les modèles commencent par `{{` et se terminent par`}}`, qu'ils impriment une variable ou exécutent des structures de contrôle telles que des instructions if. Ceci est différent des autres langages de modélisation tels que Jinja où l'impression d'une variable utilise `{{` et et où les structures de contrôle utilisent `}}` `{%` et. `%}`
**Print**
Pour imprimer la valeur d'un élément, utilisez `{{` et`}}`. Vous pouvez imprimer le résultat d'une fonction ou la valeur d'une variable. Par exemple, pour imprimer la `$labels` variable, vous devez écrire ce qui suit :
```
{{ $labels }}
```
**Répéter sur les étiquettes**
Pour effectuer une itération sur chaque étiquette, `$labels` vous pouvez utiliser un`range`. Ici `$k` fait référence au nom et `$v` à la valeur de l'étiquette actuelle. Par exemple, si votre requête renvoyait une `instance=test` étiquette, `$k` elle `$v` serait `instance` et serait`test`.
```
{{ range $k, $v := $labels }}
{{ $k }}={{ $v }}
{{ end }}
```
## Les labels, les valeurs et les variables de valeurs
**La variable labels**
La `$labels` variable contient les libellés de la requête. Par exemple, une requête qui vérifie si une instance est en panne peut renvoyer une étiquette d'instance avec le nom de l'instance indisponible. Supposons, par exemple, que vous disposiez d'une règle d'alerte qui se déclenche lorsque l'une de vos instances est en panne depuis plus de 5 minutes. Vous souhaitez ajouter un résumé à l'alerte indiquant quelle instance est hors service. Avec la `$labels` variable, vous pouvez créer un résumé qui imprime l'étiquette de l'instance dans le résumé :
```
Instance {{ $labels.instance }} has been down for more than 5 minutes
```
**Étiquettes à points**
Si l'étiquette que vous souhaitez imprimer contient un point (point ou point) dans son nom, l'utilisation du même point dans le modèle ne fonctionnera pas :
```
Instance {{ $labels.instance.name }} has been down for more than 5 minutes
```
Cela est dû au fait que le modèle tente d'utiliser un champ inexistant appelé `name` in`$labels.instance`. Vous devriez plutôt utiliser la `index` fonction qui imprime l'étiquette `instance.name` dans la `$labels` variable :
```
Instance {{ index $labels "instance.name" }} has been down for more than 5 minutes
```
**La variable de valeur**
La `$value` variable fonctionne différemment de Prometheus. Dans `$value` Prometheus, un nombre à virgule flottante contient la valeur de l'expression, mais dans Grafana, il s'agit d'une chaîne contenant les libellés et les valeurs de toutes les expressions Threshold, Reduce et Math, ainsi que les conditions classiques pour cette règle d'alerte. Il ne contient pas les résultats des requêtes, car celles-ci peuvent renvoyer entre 10 et 10 000 lignes ou métriques.
Si vous deviez utiliser la `$value` variable dans le résumé d'une alerte :
```
{{ $labels.service }} has over 5% of responses with 5xx errors: {{ $value }})
```
Le résumé peut ressembler à ce qui suit :
```
api has an over 5% of responses with 5xx errors: [ var='B' labels={service=api} value=6.789 ]
```
Ici, il `var='B'` fait référence à l'expression avec le RefID B. Dans Grafana, toutes les requêtes et expressions sont identifiées par un RefID qui identifie chaque requête et expression dans une règle d'alerte. `labels={service=api}`Fait également référence aux étiquettes et `value=6.789` à la valeur.
Vous avez peut-être remarqué qu'il n'existe pas de RefID A. Cela est dû au fait que dans la plupart des règles d'alerte, le RefID A fait référence à une requête et que les requêtes peuvent renvoyer de nombreuses lignes ou séries chronologiques auxquelles elles ne sont pas incluses. `$value`
**La variable de valeurs**
Si la `$value` variable contient plus d'informations que ce dont vous avez besoin, vous pouvez plutôt imprimer les étiquettes et la valeur des expressions individuelles à l'aide de`$values`. À la différence`$value`, la `$values` variable est une table d'objets contenant les étiquettes et les valeurs à virgule flottante de chaque expression, indexées par leur RefID.
Si vous deviez imprimer la valeur de l'expression avec RefID `B` dans le résumé de l'alerte :
```
{{ $labels.service }} has over 5% of responses with 5xx errors: {{ $values.B }}%
```
Le résumé contiendra uniquement la valeur :
```
api has an over 5% of responses with 5xx errors: 6.789%
```
Cependant, lors de l'`{{ $values.B }}`impression du numéro 6,789, il s'agit en fait d'une chaîne lorsque vous imprimez l'objet qui contient à la fois les étiquettes et la valeur du RefID B, et non la valeur à virgule flottante de B. Pour utiliser la valeur à virgule flottante du RefID B, vous devez utiliser le champ de. `Value` `$values.B` Si vous deviez humaniser la valeur à virgule flottante dans le résumé d'une alerte :
```
{{ $labels.service }} has over 5% of responses with 5xx errors: {{ humanize $values.B.Value }}%
```
**Aucune donnée, aucune erreur d'exécution et aucun délai d'attente**
Si la requête de votre règle d'alerte ne renvoie aucune donnée ou échoue en raison d'une erreur de source de données ou d'un délai d'attente, les expressions Threshold, Reduce ou Math qui utilisent cette requête ne renverront également aucune donnée ou une erreur. Lorsque cela se produit, ces expressions seront absentes de`$values`. Il est recommandé de vérifier la présence d'un RefID avant de l'utiliser, sinon votre modèle se cassera si votre requête ne renvoie aucune donnée ou une erreur. Vous pouvez le faire à l'aide d'une instruction if :
```
{{ if $values.B }}{{ $labels.service }} has over 5% of responses with 5xx errors: {{ humanizePercentage $values.B.Value }}{{ end }}
```
## Conditions classiques
Si la règle utilise des conditions classiques au lieu des expressions Threshold, Reduce et Math, la `$values` variable est indexée à la fois par l'ID de référence et par la position de la condition dans la condition classique. Par exemple, si vous avez une condition classique dont le RefID B contient deux conditions, elle `$values` contiendra deux conditions `B0` et`B1`.
```
The first condition is {{ $values.B0 }}, and the second condition is {{ $values.B1 }}
```
## Fonctions
Les fonctions suivantes sont également disponibles lors de l'extension d'étiquettes et d'annotations :
**args**
La `args` fonction traduit une liste d'objets en une carte avec les clés arg0, arg1, etc. Cela a pour but de permettre la transmission de plusieurs arguments aux modèles.
**Exemple**
```
{{define "x"}}{{.arg0}} {{.arg1}}{{end}}{{template "x" (args 1 "2")}}
```
```
1 2
```
**URL externe**
La `externalURL` fonction renvoie l'URL externe du serveur Grafana telle que configurée dans le ou les fichiers ini.
**Exemple**
```
{{ externalURL }}
```
```
https://example.com/grafana
```
**GraphLink**
La `graphLink` fonction renvoie le chemin d'accès à la vue graphique [Explorez dans la version 9 de Grafana](v9-explore.md) pour l'expression et la source de données données.
**Exemple**
```
{{ graphLink "{\"expr\": \"up\", \"datasource\": \"gdev-prometheus\"}" }}
```
```
/explore?left=["now-1h","now","gdev-prometheus",{"datasource":"gdev-prometheus","expr":"up","instant":false,"range":true}]
```
**humaniser**
La `humanize` fonction humanise les nombres décimaux.
**Exemple**
```
{{ humanize 1000.0 }}
```
```
1k
```
**humaniser 1024**
Il `humanize1024` fonctionne de manière similaire `humanize` mais utilise 1024 comme base au lieu de 1000.
**Exemple**
```
{{ humanize1024 1024.0 }}
```
```
1ki
```
**Humaniser la durée**
La `humanizeDuration` fonction humanise une durée en secondes.
**Exemple**
```
{{ humanizeDuration 60.0 }}
```
```
1m 0s
```
**Pourcentage d'humanisation**
La `humanizePercentage` fonction humanise une valeur de ratio par rapport à un pourcentage.
**Exemple**
```
{{ humanizePercentage 0.2 }}
```
```
20%
```
**Humaniser l'horodatage**
La `humanizeTimestamp` fonction humanise un horodatage Unix.
**Exemple**
```
{{ humanizeTimestamp 1577836800.0 }}
```
```
2020-01-01 00:00:00 +0000 UTC
```
**match**
La `match` fonction compare le texte à un modèle d'expression régulière.
**Exemple**
```
{{ match "a.*" "abc" }}
```
```
true
```
**Préfixe de chemin**
La `pathPrefix` fonction renvoie le chemin du serveur Grafana tel que configuré dans le ou les fichiers ini.
**Exemple**
```
{{ pathPrefix }}
```
```
/grafana
```
**Tableau Link**
La `tableLink` fonction renvoie le chemin d'accès à la vue tabulaire [Explorez dans la version 9 de Grafana](v9-explore.md) pour l'expression et la source de données données.
**Exemple**
```
{{ tableLink "{\"expr\": \"up\", \"datasource\": \"gdev-prometheus\"}" }}
```
```
/explore?left=["now-1h","now","gdev-prometheus",{"datasource":"gdev-prometheus","expr":"up","instant":true,"range":false}]
```
**title**
La `title` fonction met en majuscule le premier caractère de chaque mot.
**Exemple**
```
{{ title "hello, world!" }}
```
```
Hello, World!
```
**ToLower**
La `toLower` fonction renvoie tout le texte en minuscules.
**Exemple**
```
{{ toLower "Hello, world!" }}
```
```
hello, world!
```
**ToupPper**
La `toUpper` fonction renvoie tout le texte en majuscules.
**Exemple**
```
{{ toUpper "Hello, world!" }}
```
```
HELLO, WORLD!
```
**reReplaceAll**
La `reReplaceAll` fonction remplace le texte correspondant à l'expression régulière.
**Exemple**
```
{{ reReplaceAll "localhost:(.*)" "example.com:$1" "localhost:8080" }}
```
```
example.com:8080
```
# État et état des règles d'alerte
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
L'état et l'état des règles d'alerte vous aident à comprendre plusieurs indicateurs clés relatifs à l'état de vos alertes.
Il existe trois éléments clés : l'état de la *règle d'alerte, l'état* de *l'instance d'alerte et l'état* de *la règle d'alerte*. Bien que lié, chaque composant transmet des informations subtilement différentes.
**État de la règle d'alerte**
Une règle d'alerte peut avoir l'un des états suivants :
| State | Description |
| --- | --- |
| Normal | Aucune des séries chronologiques renvoyées par le moteur d'évaluation n'est à `Firing` l'état `Pending` or. |
| En attente | Au moins une série chronologique renvoyée par le moteur d'évaluation est`Pending`. |
| Mise à feu | Au moins une série chronologique renvoyée par le moteur d'évaluation est`Firing`. |
**Note**
Les alertes passeront d'abord à `pending` puis`firing`, il faudra donc au moins deux cycles d'évaluation avant qu'une alerte ne soit déclenchée.
**État de l'instance d'alerte**
Une instance d'alerte peut se trouver dans l'un des états suivants :
| State | Description |
| --- | --- |
| Normal | L'état d'une alerte qui n'est ni en cours ni en attente indique que tout fonctionne correctement. |
| En attente | État d'une alerte active pendant une durée inférieure au seuil configuré. |
| Alerte | État d'une alerte active pendant une durée supérieure au seuil configuré. |
| NoData | Aucune donnée n'a été reçue pour la fenêtre horaire configurée. |
| Erreur | Erreur survenue lors de la tentative d'évaluation d'une règle d'alerte. |
**État des règles d'alerte**
Une règle d'alerte peut avoir l'un des états de santé suivants :
| State | Description |
| --- | --- |
| Ok | Aucune erreur lors de l'évaluation d'une règle d'alerte. |
| Erreur | Une erreur s'est produite lors de l'évaluation d'une règle d'alerte. |
| NoData | Absence de données dans au moins une série chronologique renvoyée lors de l'évaluation d'une règle. |
**Alertes spéciales pour `NoData` et `Error`**
Lorsque l'évaluation d'une règle d'alerte produit un état `NoData``Error`, Grafana Alerting génère des instances d'alerte portant les étiquettes supplémentaires suivantes :
| Étiquette | Description |
| --- | --- |
| nom de l'alerte | Soit, `DatasourceNoData` soit `DatasourceError` selon l'État. |
| dataource\$1uid | L'UID de la source de données à l'origine de l'état. |
Vous pouvez gérer ces alertes de la même manière que les alertes classiques en ajoutant un silence, un itinéraire vers un point de contact, etc.
# Points de contact
****
**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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
Utilisez les points de contact pour définir la manière dont vos contacts sont avertis lorsqu'une règle d'alerte est déclenchée. Un point de contact peut avoir un ou plusieurs types de points de contact, par exemple, e-mail, Slack, webhook, etc. Lorsqu'une règle d'alerte est déclenchée, une notification est envoyée à tous les types de points de contact répertoriés pour un point de contact. Les points de contact peuvent être configurés pour le Grafana Alertmanager ainsi que pour les alertmanagers externes.
Vous pouvez également utiliser des modèles de notification pour personnaliser les messages de notification en fonction des types de points de contact.
**Types de points de contact pris en charge**
Le tableau suivant répertorie les types de points de contact pris en charge par Grafana.
| Name | Type |
| --- | --- |
| Amazon SNS | `sns` |
| OpsGenie | `opsgenie` |
| Devoir de téléavertisseur | `pagerduty` |
| Slack | `slack` |
| VictorOps | `victorops` |
Pour plus d'informations sur les points de contact, reportez-vous [Travailler avec les points de contact](v9-alerting-contact-points.md) aux sections et[Personnaliser les notifications](v9-alerting-notifications.md).
# 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 10.x de Grafana, voir. [Travailler dans la version 10 de Grafana](using-grafana-v10.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)
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 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, consultez[Points de contact](v9-alerting-explore-contacts.md).
## 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](https://pkg.go.dev/text/template) et se trouvent dans l'onglet Points de contact de la page Alertes.
## 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.