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 de
****
**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)
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](v10-alerting-setup-alertmanager.md).
## 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 key/value paires 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 avoir`foo=baz`. Une alerte peut avoir plusieurs étiquettes, par exemple`foo=bar,bar=baz`, mais elle ne peut pas avoir deux fois la même étiquette, par exemple`foo=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 Grafana OnCall 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](v10-alerting-explore-notifications-policies-details.md).
### 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.
**Topics**
+ [Principes](#v10-alerting-overview-principles)
+ [Principes fondamentaux](#v10-alerting-overview-fundamentals)
+ [Sources de données et alertes Grafana](v10-alerting-overview-datasources.md)
+ [Alertes sur les données numériques](v10-alerting-overview-numeric.md)
+ [Étiquettes et annotations](v10-alerting-overview-labels.md)
+ [À propos des règles d'alerte](v10-alerting-explore-rules.md)
+ [Gestionnaire d'alertes](v10-alerting-explore-alertmanager.md)
+ [Points de contact](v10-alerting-explore-contacts.md)
+ [Notifications](v10-alerting-explore-notifications.md)
+ [Alerter la haute disponibilité](v10-alerting-explore-high-availability.md)
# Sources de données et alertes Grafana
****
**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)
Un certain nombre de sources de données sont compatibles avec Grafana Alerting. Chaque source de données est prise en charge par un plugin. Les alertes Grafana nécessitent que les plugins de source de données soient des plugins de *backend*, afin d'évaluer les règles à l'aide de la source de données, car le moteur d'évaluation s'exécute sur le backend. Les plugins doivent également spécifier qu'ils sont compatibles avec les alertes Grafana.
Les sources de données sont ajoutées et mises à jour au fil du temps. Les sources de données suivantes sont connues pour être compatibles avec les alertes Grafana.
+ [Connect à une source de CloudWatch données Amazon](using-amazon-cloudwatch-in-AMG.md)
+ [Connectez-vous à une source de données Azure Monitor](using-azure-monitor-in-AMG.md)
+ [Connectez-vous à une source OpenSearch de données Amazon Service](using-Amazon-OpenSearch-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 à 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 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)
Pour des informations plus détaillées sur les sources de données et les plug-ins de sources de données dans Amazon Managed Grafana, consultez. [Connexion aux sources de données](AMG-data-sources.md)
# Alertes sur les données numériques
****
**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)
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 d'une 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 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 é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](v10-alerting-overview-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](v10-alerting-overview-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](v10-alerting-overview-labels-templating.md).
**Topics**
+ [Étiquettes](#v10-alerting-overview-labels-labels)
+ [Annotations](#v10-alerting-overview-labels-annotations)
+ [Comment fonctionne la correspondance des étiquettes](v10-alerting-overview-labels-matching.md)
+ [Étiquettes dans Grafana Alerting](v10-alerting-overview-labels-alerting.md)
+ [Création de modèles d'étiquettes et d'annotations](v10-alerting-overview-labels-templating.md)
# Comment fonctionne la correspondance des étiquettes
****
**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)
Utilisez des étiquettes et des outils de comparaison 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 afin de lier une règle à une politique.
## Exemple
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.
## Exclure les étiquettes
Vous pouvez également écrire des correspondances d'étiquettes pour exclure des étiquettes.
Voici un exemple qui montre comment exclure l'étiquette`team`. Vous pouvez choisir l'une de ces valeurs pour exclure l'étiquette.
+ `team=""`
+ `team!~.+`
+ `team=~^$`
# Étiquettes dans Grafana Alerting
****
**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)
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](v10-alerting-configure.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_` elle sera 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 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)
Vous pouvez utiliser des modèles pour inclure des données issues de requêtes et d'expressions dans des étiquettes et des annotations. Par exemple, vous pouvez définir l'étiquette de gravité d'une alerte en fonction de la valeur de la requête, ou utiliser l'étiquette d'instance de la requête dans une annotation récapitulative afin de savoir quel serveur utilise beaucoup le processeur.
Tous les modèles doivent être écrits en [texte/modèle](https://pkg.go.dev/text/template). Que vous modélisiez une étiquette ou une annotation, vous devez écrire chaque modèle en ligne à l'intérieur de l'étiquette ou de l'annotation que vous modélisez. Cela signifie que vous ne pouvez pas partager de modèles entre les étiquettes et les annotations, mais que vous devez copier les modèles là où vous souhaitez les utiliser.
Chaque modèle est évalué chaque fois que la règle d'alerte est évaluée, et est évalué séparément pour chaque alerte. Par exemple, si votre règle d'alerte comporte un modèle d'annotation récapitulative et qu'elle comporte 10 alertes déclenchées, le modèle sera exécuté 10 fois, une fois pour chaque alerte. Vous devriez essayer d'éviter autant que possible d'effectuer des calculs coûteux dans vos modèles.
## Exemples
Plutôt que d'écrire un didacticiel complet, text/template, the following examples attempt to show the most common use-cases we have seen for templates. You can use these examples verbatim, or adapt them as necessary for your use case. For more information about how to write text/template consultez la documentation [texte/modèle](https://pkg.go.dev/text/template).
**Imprimer toutes les étiquettes, séparées par des virgules**
Pour imprimer toutes les étiquettes, séparées par des virgules, imprimez la `$labels` variable :
```
{{ $labels }}
```
Par exemple, si vous recevez une alerte avec les étiquettes `alertname=High CPU usage``instance=server1`, `grafana_folder=CPU alerts` cela imprimerait :
```
alertname=High CPU usage, grafana_folder=CPU alerts, instance=server1
```
**Note**
Si vous utilisez `$labels` des conditions classiques, la requête ne contiendra aucune étiquette. Reportez-vous à [la variable \$1labels](#v10-alerting-overview-labels-templating-the-labels-variable) pour plus d'informations.
**Imprimez toutes les étiquettes, une par ligne**
Pour imprimer toutes les étiquettes, une par ligne, utilisez a `range` pour itérer sur chaque key/value paire et imprimez-les individuellement. Ici `$k` fait référence au nom et `$v` à la valeur de l'étiquette actuelle :
```
{{ range $k, $v := $labels -}}
{{ $k }}={{ $v }}
{{ end }}
```
Par exemple, si vous recevez une alerte avec les étiquettes `alertname=High CPU usage``instance=server1`, `grafana_folder=CPU alerts` cela imprimerait :
```
alertname=High CPU usage
grafana_folder=CPU alerts
instance=server1
```
**Note**
Si vous utilisez `$labels` des conditions classiques, la requête ne contiendra aucune étiquette. Reportez-vous à [la variable \$1labels](#v10-alerting-overview-labels-templating-the-labels-variable) pour plus d'informations.
**Imprimer une étiquette individuelle**
Pour imprimer une étiquette individuelle, utilisez la `index` fonction avec la `$labels` variable :
```
The host {{ index $labels "instance" }} has exceeded 80% CPU usage for the last 5 minutes
```
Par exemple, étant donné une alerte avec l'étiquette`instance=server1`, cela imprimerait :
```
The host server1 has exceeded 80% CPU usage for the last 5 minutes
```
**Note**
Si vous utilisez `$labels` des conditions classiques, la requête ne contiendra aucune étiquette. Reportez-vous à [la variable \$1labels](#v10-alerting-overview-labels-templating-the-labels-variable) pour plus d'informations.
**Imprimer la valeur d'une requête**
Pour imprimer la valeur d'une requête instantanée, vous pouvez imprimer son ID de référence à l'aide de la `index` fonction et de la `$values` variable :
```
{{ index $values "A" }}
```
Par exemple, étant donné une requête instantanée qui renvoie la valeur 81,2345, ceci affichera :
```
81.2345
```
Pour imprimer la valeur d'une requête par plage, vous devez d'abord la réduire d'une série chronologique à un vecteur instantané avec une expression de réduction. Vous pouvez ensuite imprimer le résultat de l'expression de réduction en utilisant plutôt son ID de référence. Par exemple, si l'expression de réduction prend la moyenne de A et a l'ID de référence B, vous devez écrire :
```
{{ index $values "B" }}
```
**Imprimer la valeur humanisée d'une requête**
Pour imprimer la valeur humanisée d'une requête instantanée, utilisez la `humanize` fonction :
```
{{ humanize (index $values "A").Value }}
```
Par exemple, étant donné une requête instantanée qui renvoie la valeur 81,2345, ceci affichera :
```
81.234
```
Pour imprimer la valeur humanisée d'une requête par plage, vous devez d'abord la réduire d'une série chronologique à un vecteur instantané avec une expression de réduction. Vous pouvez ensuite imprimer le résultat de l'expression de réduction en utilisant plutôt son ID de référence. Par exemple, si l'expression de réduction prend la moyenne de A et a l'ID de référence B, vous devez écrire :
```
{{ humanize (index $values "B").Value }}
```
**Imprimer la valeur d'une requête sous forme de pourcentage**
Pour imprimer la valeur d'une requête instantanée sous forme de pourcentage, utilisez la `humanizePercentage` fonction :
```
{{ humanizePercentage (index $values "A").Value }}
```
Cette fonction s'attend à ce que la valeur soit un nombre décimal compris entre 0 et 1. Si la valeur est plutôt un nombre décimal compris entre 0 et 100, vous pouvez la diviser par 100 dans votre requête ou à l'aide d'une expression mathématique. Si la requête est une requête par plage, vous devez d'abord la réduire d'une série chronologique à un vecteur instantané avec une expression de réduction.
**Définir une sévérité à partir de la valeur d'une requête**
Pour définir une étiquette de gravité à partir de la valeur d'une requête, utilisez une instruction if et la fonction de comparaison supérieure à celle de comparaison. Assurez-vous d'utiliser des décimales (`80.0`,, `50.0``0.0`, etc.) lorsque vous effectuez des comparaisons avec `$values` car cela text/template ne prend pas en charge la coercition de type. Vous trouverez une liste de toutes les fonctions de comparaison prises en charge [ici](https://pkg.go.dev/text/template#hdr-Functions).
```
{{ if (gt $values.A.Value 80.0) -}}
high
{{ else if (gt $values.A.Value 50.0) -}}
medium
{{ else -}}
low
{{- end }}
```
**Imprimez toutes les étiquettes à partir d'un état classique**
Vous ne pouvez pas utiliser `$labels` pour imprimer des étiquettes à partir de la requête si vous utilisez des conditions classiques et vous devez les utiliser à la `$values` place. Cela s'explique par le fait que les conditions classiques suppriment ces étiquettes pour imposer un comportement unidimensionnel (au plus une alerte par règle d'alerte). Si les conditions classiques n'éliminaient pas ces étiquettes, les requêtes renvoyant de nombreuses séries chronologiques provoqueraient des interruptions entre le déclenchement et la résolution constante des alertes, car les étiquettes changeaient à chaque fois que la règle d'alerte était évaluée.
Au lieu de cela, la `$values` variable contient les valeurs réduites de toutes les séries chronologiques pour toutes les conditions qui se déclenchent. Par exemple, si vous avez une règle d'alerte avec une requête A qui renvoie deux séries chronologiques, et une condition B classique avec deux conditions, alors `$values` contiendrait `B0``B1`, `B2` et`B3`. Si la condition B classique ne comportait qu'une seule condition, `$values` elle contiendrait uniquement `B0` et`B1`.
Pour imprimer toutes les étiquettes de toutes les séries chronologiques de cuisson, utilisez le modèle suivant (assurez-vous de remplacer `B` l'expression régulière par l'ID de référence de la condition classique s'il est différent) :
```
{{ range $k, $v := $values -}}
{{ if (match "B[0-9]+" $k) -}}
{{ $k }}: {{ $v.Labels }}{{ end }}
{{ end }}
```
Par exemple, une condition classique pour deux séries chronologiques dépassant une seule condition imprimerait :
```
B0: instance=server1
B1: instance=server2
```
Si la condition classique comporte deux conditions ou plus et qu'une série chronologique dépasse plusieurs conditions en même temps, ses étiquettes seront dupliquées pour chaque condition dépassée :
```
B0: instance=server1
B1: instance=server2
B2: instance=server1
B3: instance=server2
```
Si vous devez imprimer des étiquettes uniques, vous devriez plutôt envisager de modifier vos règles d'alerte en les remplaçant par des règles unidimensionnelles par des règles multidimensionnelles. Vous pouvez le faire en remplaçant votre condition classique par des expressions de réduction et mathématiques.
**Imprimer toutes les valeurs d'une condition classique**
Pour imprimer toutes les valeurs d'une condition classique, prenez l'exemple précédent et remplacez-le `$v.Labels` par `$v.Value` :
```
{{ range $k, $v := $values -}}
{{ if (match "B[0-9]+" $k) -}}
{{ $k }}: {{ $v.Value }}{{ end }}
{{ end }}
```
Par exemple, une condition classique pour deux séries chronologiques dépassant une seule condition imprimerait :
```
B0: 81.2345
B1: 84.5678
```
Si la condition classique comporte au moins deux conditions et qu'une série chronologique dépasse plusieurs conditions en même temps, elle `$values` contiendra les valeurs de toutes les conditions :
```
B0: 81.2345
B1: 92.3456
B2: 84.5678
B3: 95.6789
```
## Variables
Les variables suivantes sont à votre disposition lors de la création de modèles d'étiquettes et d'annotations :
### La variable labels
La `$labels` variable contient tous les libellés de la requête. Supposons, par exemple, que vous ayez une requête qui renvoie l'utilisation du processeur pour tous vos serveurs, et que vous disposiez d'une règle d'alerte qui se déclenche lorsque l'un de vos serveurs a dépassé 80 % d'utilisation du processeur au cours des 5 dernières minutes. Vous souhaitez ajouter une annotation récapitulative à l'alerte qui indique quel serveur utilise beaucoup le processeur. Avec la `$labels` variable, vous pouvez écrire un modèle qui imprime une phrase lisible par l'homme, telle que :
```
CPU usage for {{ index $labels "instance" }} has exceeded 80% for the last 5 minutes
```
**Note**
Si vous utilisez une condition classique, `$labels` elle ne contiendra aucune étiquette provenant de la requête. Les conditions classiques suppriment ces étiquettes afin d'imposer un comportement unidimensionnel (au maximum une alerte par règle d'alerte). Si vous souhaitez utiliser les étiquettes de la requête dans votre modèle, suivez l'exemple précédent *Imprimer toutes les étiquettes à partir d'un exemple de condition classique*.
### La variable de valeur
La `$value` variable est une chaîne contenant les libellés et les valeurs de toutes les requêtes instantanées, les expressions de seuil, de réduction et mathématiques, ainsi que les conditions classiques de la règle d'alerte. Il ne contient pas les résultats des requêtes de plage, car celles-ci peuvent renvoyer de 10 à 10 000 lignes ou métriques. Si tel était le cas, pour des requêtes particulièrement volumineuses, une seule alerte pourrait utiliser des dizaines de secondes MBs de mémoire et Grafana manquerait de mémoire très rapidement.
Pour imprimer la `$value` variable dans le résumé, vous devez écrire quelque chose comme ceci :
```
CPU usage for {{ index $labels "instance" }} has exceeded 80% for the last 5 minutes: {{ $value }}
```
Et cela ressemblerait à ceci :
```
CPU usage for instance1 has exceeded 80% for the last 5 minutes: [ var='A' labels={instance=instance1} value=81.234 ]
```
Ici, il `var='A'` fait référence à la requête instantanée avec l'ID de `labels={instance=instance1}` référence A, aux étiquettes et `value=81.234` à l'utilisation moyenne du processeur au cours des 5 dernières minutes.
Si vous souhaitez imprimer une partie de la chaîne au lieu de la chaîne complète, utilisez la `$values` variable. Il contient les mêmes informations que`$value`, mais dans un tableau structuré, et il est beaucoup plus facile à utiliser que d'écrire une expression régulière correspondant exactement au texte souhaité.
### La variable de valeurs
La `$values` variable est une table contenant les étiquettes et les valeurs à virgule flottante de toutes les requêtes et expressions instantanées, indexées par leur référence. IDs
Pour imprimer la valeur de la requête instantanée avec l'ID de référence A :
```
CPU usage for {{ index $labels "instance" }} has exceeded 80% for the last 5 minutes: {{ index $values "A" }}
```
Par exemple, à partir d'une alerte avec les libellés `instance=server1` et d'une requête instantanée avec la valeur`81.2345`, ceci imprimerait :
```
CPU usage for instance1 has exceeded 80% for the last 5 minutes: 81.2345
```
Si la requête dans l'ID de référence A est une requête de plage plutôt qu'une requête instantanée, ajoutez une expression de réduction avec l'ID de référence B et remplacez-la par `(index $values "A")` `(index $values "B")` :
```
CPU usage for {{ index $labels "instance" }} has exceeded 80% for the last 5 minutes: {{ index $values "B" }}
```
## Fonctions
Les fonctions suivantes sont à votre disposition lors de la création de modèles 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.
```
{{define "x"}}{{.arg0}} {{.arg1}}{{end}}{{template "x" (args 1 "2")}}
```
```
1 2
```
**URL externe**
La `externalURL` fonction renvoie l'URL externe du serveur Grafana.
```
{{ externalURL }}
```
```
https://example.com/grafana
```
**GraphLink**
La `graphLink` fonction renvoie le chemin d'accès à la vue graphique [Explorez dans la version 10 de Grafana](v10-explore.md) pour l'expression et la source de données données.
```
{{ 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.
```
{{ humanize 1000.0 }}
```
```
1k
```
**humaniser 1024**
Il `humanize1024` fonctionne de manière similaire `humanize` mais utilise 1024 comme base au lieu de 1000.
```
{{ humanize1024 1024.0 }}
```
```
1ki
```
**Humaniser la durée**
La `humanizeDuration` fonction humanise une durée en secondes.
```
{{ humanizeDuration 60.0 }}
```
```
1m 0s
```
**Pourcentage d'humanisation**
La `humanizePercentage` fonction humanise une valeur de ratio par rapport à un pourcentage.
```
{{ humanizePercentage 0.2 }}
```
```
20%
```
**Humaniser l'horodatage**
La `humanizeTimestamp` fonction humanise un horodatage Unix.
```
{{ 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.
```
{{ match "a.*" "abc" }}
```
```
true
```
**Préfixe de chemin**
La `pathPrefix` fonction renvoie le chemin du serveur Grafana.
```
{{ pathPrefix }}
```
```
/grafana
```
**Tableau Link**
La `tableLink` fonction renvoie le chemin d'accès à la vue tabulaire [Explorez dans la version 10 de Grafana](v10-explore.md) pour l'expression et la source de données données.
```
{{ 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.
```
{{ title "hello, world!" }}
```
```
Hello, World!
```
**ToLower**
La `toLower` fonction renvoie tout le texte en minuscules.
```
{{ toLower "Hello, world!" }}
```
```
hello, world!
```
**ToupPper**
La `toUpper` fonction renvoie tout le texte en majuscules.
```
{{ toUpper "Hello, world!" }}
```
```
HELLO, WORLD!
```
**reReplaceAll**
La `reReplaceAll` fonction remplace le texte correspondant à l'expression régulière.
```
{{ reReplaceAll "localhost:(.*)" "example.com:$1" "localhost:8080" }}
```
```
example.com:8080
```
# À 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 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)
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 la durée pendant laquelle la condition doit être remplie pour commencer à se déclencher.
Alors que les requêtes et les expressions sélectionnent l'ensemble de données à évaluer, une *condition* définit le seuil que les données doivent 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](v10-alerting-explore-rules-types.md)
+ [Règles d'enregistrement](v10-alerting-explore-rule-recording.md)
+ [Requêtes et conditions](v10-alerting-explore-rules-queries.md)
+ [Instances d'alerte](v10-alerting-rules-instances.md)
+ [Espaces de noms, dossiers et groupes](v10-alerting-rules-grouping.md)
+ [Évaluation des règles d'alerte](v10-alerting-rules-evaluation.md)
+ [État et état des règles d'alerte](v10-alerting-explore-state.md)
+ [Modèle de notification](v10-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 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)
Grafana prend en charge plusieurs types de règles d'alerte. Apprenez-en davantage sur chacun des types de règles d'alerte, leur fonctionnement et déterminez celle qui convient le mieux à votre cas d'utilisation.
## Règles gérées par Grafana
Les règles gérées par Grafana sont 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.
Outre la prise en charge de plusieurs sources de données, vous pouvez ajouter [des expressions](v10-panels-query-xform-expressions.md) pour transformer vos données et exprimer les conditions d'alerte.
Dans Grafana, gestion des alertes :
+ Les règles d'alerte sont créées dans Grafana, sur la base d'une ou de plusieurs sources de données.
+ Les règles d'alerte sont évaluées par le moteur d'évaluation des règles d'alerte depuis Grafana.
+ Les alertes sont diffusées à l'aide du Grafana Alertmanager interne.
**Note**
Vous pouvez également configurer les alertes à diffuser à l'aide d'un gestionnaire d'alertes externe, ou utiliser à la fois des gestionnaires d'alertes internes et externes. Pour plus d'informations, voir [Ajouter un gestionnaire d'alertes externe](v10-alerting-setup-alertmanager.md).
## Règles de gestion des sources de données
Pour créer des règles d'alerte gérées par une source de données, 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 Ruler est prise en charge.
Dans les alertes gérées par les sources de données :
+ Les règles d'alerte sont créées et stockées dans la source de données elle-même.
+ Les règles d'alerte ne peuvent être créées que sur la base des données Prometheus.
+ L'évaluation et la diffusion des règles d'alerte sont réparties sur plusieurs nœuds pour garantir une haute disponibilité et une tolérance aux pannes.
## Choisissez un type de règle d'alerte
Lorsque vous choisissez le type de règle d'alerte à utiliser, considérez la comparaison suivante entre les règles d'alerte gérées par Grafana et les règles d'alerte gérées par les sources de données.
| Fonctionnalité | Règle d'alerte gérée par Grafana | Règle d'alerte gérée par Loki/Mimir |
| --- | --- | --- |
| Créez des règles d'alerte basées sur les données provenant de l'une de nos sources de données prises en charge | Oui | Non : vous pouvez uniquement créer des règles d'alerte basées sur les données Prometheus. L'API Ruler doit être activée dans la source de données. |
| Combinez et associez les sources de données | Oui | Non |
| Inclut la prise en charge des règles d'enregistrement | Non | Oui |
| Ajoutez des expressions pour transformer vos données et définir des conditions d'alerte | Oui | Non |
| Utiliser des images dans les notifications d'alerte | Oui | Non |
| Mise à l’échelle | Plus gourmands en ressources, dépendent de la base de données et sont susceptibles de présenter des erreurs transitoires. Ils ne sont redimensionnés que verticalement. | Stockez les règles d'alerte dans la source de données elle-même et permettez une mise à l'échelle « infinie ». Générez et envoyez des notifications d'alerte depuis l'emplacement de vos données. |
| Évaluation et diffusion des règles d'alerte | L'évaluation et la diffusion des règles d'alerte sont effectuées depuis Grafana, en utilisant un Alertmanager externe, ou les deux. | L'évaluation des règles d'alerte et la diffusion des alertes sont distribuées, ce qui signifie qu'il n'existe aucun point de défaillance unique. |
# Règles d'enregistrement
****
**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 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.
L'interrogation de cette nouvelle série chronologique est plus rapide, en particulier pour les tableaux de bord, car ils demandent la même expression à chaque actualisation des tableaux de bord.
En savoir plus sur les [règles d'enregistrement](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) dans Prometheus.
# Requêtes et conditions
****
**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)
Dans Grafana, les requêtes jouent un rôle essentiel dans la récupération et la transformation des données à partir de sources de données prises en charge, notamment des bases de données telles que MySQL et PostgreSQL, des bases de données de séries chronologiques telles que Prometheus, InfluxDB et Graphite, et des services tels qu'Amazon, Azure Monitor et Google Cloud Monitoring. OpenSearch CloudWatch
Pour plus d'informations sur les sources de données prises en charge, consultez[Sources de données et alertes Grafana](v10-alerting-overview-datasources.md).
Le processus d'exécution d'une requête implique de définir la source de données, de spécifier les données à récupérer et d'appliquer des filtres ou des transformations appropriés. Des langages de requête ou des syntaxes spécifiques à la source de données choisie sont utilisés pour construire ces requêtes.
Dans Alerting, vous définissez une requête pour obtenir les données que vous souhaitez mesurer et une condition qui doit être remplie avant qu'une règle d'alerte ne soit déclenchée.
Une règle d'alerte consiste en une ou plusieurs requêtes et expressions qui sélectionnent les données que vous souhaitez mesurer.
Pour plus d'informations sur les requêtes et les expressions, consultez[Interrogez et transformez les données](v10-panels-query-xform.md).
## Requêtes sur les sources de données
Les requêtes dans Grafana peuvent être appliquées de différentes manières, en fonction de la source de données et du langage de requête utilisés. L'éditeur de requêtes de chaque source de données fournit une interface utilisateur personnalisée qui vous permet de rédiger des requêtes qui tirent parti de ses fonctionnalités uniques.
En raison des différences entre les langages de requête, chaque éditeur de requêtes de source de données présente une apparence et un fonctionnement différents. En fonction de votre source de données, l'éditeur de requêtes peut fournir des fonctionnalités de saisie automatique, des noms de métriques, des suggestions de variables ou une interface visuelle de création de requêtes.
Parmi les types courants de composants de requête, on peut citer :
**Métriques ou champs de données** : spécifiez les métriques ou les champs de données spécifiques que vous souhaitez récupérer, tels que l'utilisation du processeur, le trafic réseau ou les relevés des capteurs.
**Plage de temps** : définissez la plage de temps pour laquelle vous souhaitez récupérer des données, telle que la dernière heure, un jour spécifique ou une plage horaire personnalisée.
**Filtres** : appliquez des filtres pour affiner les données en fonction de critères spécifiques, tels que le filtrage des données en fonction d'une balise, d'un hôte ou d'une application spécifique.
**Agrégations** : effectuez des agrégations sur les données pour calculer des indicateurs tels que des moyennes, des sommes ou des dénombrements sur une période donnée.
**Regroupement : regroupez** les données selon des dimensions ou des balises spécifiques pour créer des vues agrégées ou des ventilations.
**Note**
Grafana ne prend pas en charge les requêtes d'alerte avec des variables de modèle. Plus d'informations sont disponibles [ici](https://community.grafana.com/t/template-variables-are-not-supported-in-alert-queries-while-setting-up-alert/2514) dans les forums de Grafana Labs.
## Requêtes d'expression
Dans Grafana, une expression est utilisée pour effectuer des calculs, des transformations ou des agrégations sur les données demandées par la source de données. Il vous permet de créer des métriques personnalisées ou de modifier des métriques existantes en fonction d'opérations mathématiques, de fonctions ou d'expressions logiques.
En utilisant les requêtes d'expression, les utilisateurs peuvent effectuer des tâches telles que le calcul de la variation en pourcentage entre deux valeurs, l'application de fonctions telles que les fonctions logarithmiques ou trigonométriques, l'agrégation de données sur des plages de temps ou des dimensions spécifiques et la mise en œuvre d'une logique conditionnelle pour gérer différents scénarios.
Dans Alerting, vous ne pouvez utiliser des expressions que pour les règles d'alerte gérées par Grafana. Pour chaque expression, vous pouvez choisir entre les expressions mathématiques, réduire ou rééchantillonner. Ces règles sont appelées règles multidimensionnelles, car elles génèrent une alerte distincte pour chaque série.
Vous pouvez également utiliser une condition classique, qui crée une règle d'alerte qui déclenche une seule alerte lorsque sa condition est remplie. Grafana n'envoie donc qu'une seule alerte, même lorsque les conditions d'alerte sont remplies pour plusieurs séries.
**Note**
Les conditions classiques existent principalement pour des raisons de compatibilité et doivent être évitées dans la mesure du possible.
**Réduire**
Regroupe les valeurs des séries chronologiques dans la plage de temps sélectionnée en une seule valeur.
**Math**
Effectue des calculs de forme libre functions/operations sur les séries chronologiques et les données numériques. Peut être utilisé pour prétraiter des données de séries chronologiques ou pour définir une condition d'alerte pour les données numériques.
**Rééchantillonner**
Réaligne une plage de temps sur un nouvel ensemble d'horodatages, ce qui est utile lorsque vous comparez des données de séries chronologiques provenant de différentes sources de données où les horodatages ne seraient pas alignés autrement.
**Threshold**
Vérifie si des données de séries chronologiques correspondent à la condition de seuil.
L'expression de seuil vous permet de comparer deux valeurs uniques. Il est renvoyé `0` lorsque la condition est fausse et `1` si la condition est vraie. Les fonctions de seuil suivantes sont disponibles :
+ Est supérieur à (x > y)
+ Est inférieur à (x < y)
+ Se situe dans la plage (x > y1 ET x < y2)
+ Est hors de portée (x < y1 AND x > y2)
**État classique**
Vérifie si des données de séries chronologiques correspondent à la condition d'alerte.
**Note**
Les requêtes d'expression de condition classiques ne produisent toujours qu'une seule instance d'alerte, quel que soit le nombre de séries chronologiques répondant à la condition. Les conditions classiques existent principalement pour des raisons de compatibilité et doivent être évitées dans la mesure du possible.
## Agrégations
Grafana Alerting fournit les fonctions d'agrégation suivantes pour vous permettre d'affiner davantage votre requête.
Ces fonctions sont disponibles uniquement pour **les expressions de condition Reduce** **et Classic**.
| Fonction | Expression | Ce qu'il fait |
| --- | --- | --- |
| avg | Réduire/Classique | Affiche la moyenne des valeurs |
| min | Réduire/Classique | Affiche la valeur la plus faible |
| max | Réduire/Classique | Affiche la valeur la plus élevée |
| sum | Réduire/Classique | Affiche la somme de toutes les valeurs |
| count | Réduire/Classique | Compte le nombre de valeurs dans le résultat |
| last | Réduire/Classique | Affiche la dernière valeur |
| median | Réduire/Classique | Affiche la valeur médiane |
| diff | Classique | Affiche la différence entre la valeur la plus récente et la plus ancienne |
| diff\$1abs | Classique | Affiche la valeur absolue de diff |
| percent\$1diff | Classique | Affiche la valeur en pourcentage de la différence entre la valeur la plus récente et la plus ancienne |
| pourcent\$1diff\$1abs | Classique | Affiche la valeur absolue de percent\$1diff |
| count\$1non\$1null | Classique | Affiche le nombre de valeurs du jeu de résultats qui ne sont pas null |
## État d'alerte
Une condition d'alerte est la requête ou l'expression qui détermine si l'alerte se déclenchera ou non en fonction de la valeur qu'elle produit. Il ne peut y avoir qu'une seule condition qui déterminera le déclenchement de l'alerte.
Après avoir défini les and/or expressions de vos requêtes, choisissez l'une d'entre elles comme condition de règle d'alerte.
Lorsque les données demandées répondent à la condition définie, Grafana déclenche l'alerte associée, qui peut être configurée pour envoyer des notifications via différents canaux tels que le courrier électronique, Slack ou. PagerDuty Les notifications vous informent que la condition est remplie, vous permettant de prendre les mesures appropriées ou d'étudier le problème sous-jacent.
Par défaut, la dernière expression ajoutée est utilisée comme condition d'alerte.
## Seuil de récupération
Pour réduire le bruit des alertes, vous pouvez définir un seuil de récupération différent du seuil d'alerte.
Les alertes clignotantes se produisent lorsqu'une métrique passe au-dessus de la condition de seuil d'alerte et peuvent entraîner de fréquents changements d'état, entraînant la génération d'un trop grand nombre de notifications.
Les règles d'alerte gérées par Grafana sont évaluées pour un intervalle de temps spécifique. Lors de chaque évaluation, le résultat de la requête est vérifié par rapport au seuil défini dans la règle d'alerte. Si la valeur d'une métrique est supérieure au seuil, une règle d'alerte est déclenchée et une notification est envoyée. Lorsque la valeur passe en dessous du seuil et qu'une alerte est active pour cette métrique, l'alerte est résolue et une autre notification est envoyée.
Il peut être difficile de créer une règle d'alerte pour une métrique bruyante. C'est-à-dire lorsque la valeur d'une métrique passe continuellement au-dessus et en dessous d'un seuil. Ce phénomène, appelé battement, donne lieu à une série de notifications de déclenchement résolues et à un historique de l'état des alertes bruyantes.
Par exemple, si vous recevez une alerte de latence avec un seuil de 1 000 ms et que le nombre fluctue autour de 1 000 (disons 980 -> 1010 -> 990 -> 1020, etc.), chacune de ces alertes déclenchera une notification.
Pour résoudre ce problème, vous pouvez définir un seuil de récupération (personnalisé), ce qui signifie essentiellement avoir deux seuils au lieu d'un. Une alerte est déclenchée lorsque le premier seuil est franchi et n'est résolue que lorsque le second seuil est franchi.
Par exemple, vous pouvez définir un seuil de 1 000 ms et un seuil de récupération de 900 ms. Ainsi, une règle d'alerte ne cessera de se déclencher que lorsqu'elle passe en dessous de 900 ms et que les battements seront réduits.
# Instances d'alerte
****
**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)
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' CPUs alertes observées après la première évaluation, permettant ainsi à une seule règle de signaler l'état de chaque processeur.
# Espaces de noms, dossiers et groupes
****
**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)
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 et dossiers**
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.
Un espace de noms contient un ou plusieurs groupes. Les règles d'un groupe sont exécutées séquentiellement à intervalles réguliers. L'intervalle par défaut est d'une minute. Vous pouvez renommer les espaces de noms et les groupes de règles Grafana Mimi ou Loki, et modifier les intervalles d'évaluation des groupes.
**Groups** (Groupes)
Les règles d'un groupe sont exécutées séquentiellement à intervalles réguliers, ce qui signifie qu'aucune règle ne sera évaluée en même temps et par ordre d'apparition. L'intervalle par défaut est d'une minute. Vous pouvez renommer les espaces de noms de règles Grafana Mimir ou Loki ou les espaces de noms et groupes de règles Loki, et modifier les intervalles d'évaluation des groupes.
**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.
**Note**
Les règles d'alerte gérées par Grafana sont évaluées simultanément plutôt que séquentiellement.
# Évaluation des règles d'alerte
****
**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)
Utilisez l'évaluation des règles d'alerte pour déterminer à quelle fréquence une règle d'alerte doit être évaluée et à quelle vitesse elle doit changer d'état.
Pour ce faire, vous devez vous assurer que votre règle d'alerte se trouve dans le bon groupe d'évaluation et définir une période d'attente adaptée à votre cas d'utilisation.
## Groupe d'évaluation
Chaque règle d'alerte fait partie d'un groupe d'évaluation. Chaque groupe d'évaluation contient un intervalle d'évaluation qui détermine la fréquence à laquelle la règle d'alerte est vérifiée.
Les règles d'alerte **gérées par les sources de données** au sein d'un même groupe sont évaluées les unes après les autres, tandis que les règles d'alerte des différents groupes peuvent être évaluées simultanément. Cette fonctionnalité est particulièrement utile lorsque vous souhaitez vous assurer que les règles d'enregistrement sont évaluées avant toute règle d'alerte.
Les règles d'alerte **gérées par Grafana** sont évaluées en même temps, quel que soit le groupe de règles d'alerte. L'intervalle d'évaluation par défaut est fixé à 10 secondes, ce qui signifie que les règles d'alerte gérées par Grafana sont évaluées toutes les 10 secondes jusqu'à la fenêtre de 10 secondes la plus proche de l'horloge, par exemple 10:00:00, 10:00:10, 10:00:20, etc. Vous pouvez également configurer votre propre intervalle d'évaluation, si nécessaire.
**Note**
Les groupes d'évaluation et le regroupement des alertes dans les politiques de notification sont deux choses distinctes. Le regroupement dans les politiques de notification permet d'envoyer plusieurs alertes partageant les mêmes étiquettes dans le même message horaire.
## Période d'attente
En définissant une période d'attente, vous pouvez éviter les alertes inutiles en cas de problèmes temporaires.
Pendant la période d'attente, vous sélectionnez la période pendant laquelle une règle d'alerte peut ne pas respecter la condition jusqu'à ce qu'elle se déclenche.
**Exemple**
Imaginez que l'intervalle d'évaluation des règles d'alerte est défini toutes les 30 secondes et que la période d'attente est fixée à 90 secondes.
L'évaluation se déroulera comme suit :
[00:30] Première évaluation - condition non remplie.
[01:00] Deuxième évaluation : violation de la condition. En attente de démarrage du compteur. **L'alerte commence à être en attente.**
[01:30] Troisième évaluation : violation de la condition. Compteur en attente = 30 s. **État en attente.**
[02:00] Quatrième évaluation : violation de la condition. Compteur en attente = 60 s **État en attente.**
[02:30] Cinquième évaluation : violation de la condition. Compteur en attente = 90 s. **L'alerte commence à se déclencher**
Si la règle d'alerte comporte une condition qui doit être enfreinte pendant un certain temps avant d'agir, son état change comme suit :
+ Lorsque la condition est violée pour la première fois, la règle passe à l'état « en attente ».
+ La règle reste dans l'état « en attente » jusqu'à ce que la condition soit rompue pendant la durée requise (période d'attente).
+ Une fois le temps requis écoulé, la règle passe en état de « déclenchement ».
+ Si la condition n'est plus rompue pendant la période d'attente, la règle revient à son état normal.
**Note**
Si vous souhaitez ignorer l'état d'attente, vous pouvez simplement définir la période d'attente sur 0. Cela permet d'ignorer la période d'attente et votre règle d'alerte commence à se déclencher dès que la condition est violée.
Lorsqu'une règle d'alerte est déclenchée, des instances d'alerte sont produites, qui sont ensuite envoyées au gestionnaire d'alertes.
# É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 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)
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. |
**Conserver le dernier état**
Une règle d'alerte peut être configurée pour conserver le dernier état lorsque `NoData` ou le dernier `Error` état est rencontré. Cela empêchera à la fois le déclenchement des alertes, leur résolution et leur réactivation. Tout comme dans le cas d'une évaluation normale, la règle d'alerte passera de `Pending` à une `Firing` fois la période d'attente écoulée.
**É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.
# Modèle de notification
****
**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)
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](v10-alerting-manage-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.
# Gestionnaire d'alertes
****
**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)
Alertmanager vous permet de gérer les alertes et d'y répondre rapidement et efficacement. Il reçoit les alertes, gère les mutings, l'inhibition, le regroupement et le routage en envoyant des notifications via le canal de votre choix, par exemple par e-mail ou Slack.
Dans Grafana, vous pouvez utiliser le Grafana Alertmanager ou un Alertmanager externe. Vous pouvez également exécuter plusieurs gestionnaires d'alertes ; votre décision dépend de votre configuration et de l'endroit où vos alertes sont générées.
**Responsable des alertes Grafana**
Grafana Alertmanager est un gestionnaire d'alertes interne préconfiguré et disponible à la sélection par défaut.
Le Grafana Alertmanager peut recevoir des alertes de Grafana, mais il ne peut pas recevoir d'alertes provenant de l'extérieur de Grafana, par exemple de Mimir ou de Loki.
**Note**
Les règles d'inhibition ne sont pas prises en charge dans le Grafana Alertmanager.
**Gestionnaire d'alertes externe**
Si vous souhaitez utiliser un seul gestionnaire d'alertes pour recevoir toutes vos alertes Grafana, Loki, Mimir et Prometheus, vous pouvez configurer Grafana pour qu'il utilise un Alertmanager externe. Ce gestionnaire d'alertes externe peut être configuré et administré depuis Grafana même.
Voici deux exemples de situations dans lesquelles vous pouvez configurer votre propre gestionnaire d'alertes externe et y envoyer vos alertes au lieu du gestionnaire d'alertes Grafana :
1. Vous disposez déjà de gestionnaires d'alertes sur site dans votre propre infrastructure cloud que vous avez configurée et que vous souhaitez toujours utiliser, car vous disposez d'autres générateurs d'alertes, tels que Prometheus.
1. Vous souhaitez utiliser Prometheus sur site et Grafana hébergé pour envoyer des alertes au même gestionnaire d'alertes qui s'exécute dans votre infrastructure cloud.
Les gestionnaires d'alertes sont visibles dans le menu déroulant des pages Alerte, Points de contact et Politiques de notification.
Si vous approvisionnez votre source de données, définissez l'indicateur `handleGrafanaManagedAlerts` dans le `jsonData` champ sur pour envoyer des alertes gérées par Grafana `true` à ce gestionnaire d'alertes.
# Points de contact
****
**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 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 Pagerduty, une intégration Amazon SNS et Slack, ou une intégration Pagerduty, 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.
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 [Configuration des points de contact](v10-alerting-configure-contactpoints.md) aux sections et[Personnaliser les notifications](v10-alerting-manage-notifications.md).
# 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
# Alerter la haute disponibilité
****
**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)
Amazon Managed Grafana est configuré pour une haute disponibilité, notamment pour exécuter plusieurs instances dans plusieurs zones de disponibilité pour chaque espace de travail que vous créez.
Grafana Alerting utilise le modèle Prometheus qui permet de séparer l'évaluation des règles d'alerte de l'envoi des notifications. Dans ce modèle, l'évaluation des règles d'alerte est effectuée dans le générateur d'alertes et l'envoi des notifications est effectué dans le récepteur d'alertes. Dans Grafana Alerting, le générateur d'alertes est le planificateur et le récepteur est le gestionnaire d'alertes.
Avec les configurations de haute disponibilité, toutes les règles d'alerte sont évaluées sur toutes les instances. Vous pouvez considérer que l'évaluation des règles d'alerte est dupliquée. C'est ainsi que Grafana Alerting garantit que tant qu'au moins une instance Grafana fonctionne, les règles d'alerte seront toujours évaluées et les notifications d'alertes seront toujours envoyées. Vous verrez cette duplication dans l'historique des états, et c'est un bon moyen de savoir si vous utilisez la haute disponibilité.