Présentation
Pour commencer à configurer le monitor, complétez les sections suivantes :
- Define the search query : Construisez une requête pour compter les événements, mesurer des métriques, grouper par une ou plusieurs dimensions, et plus encore.
- Set alert conditions : Définissez des seuils d’alerte et d’avertissement, des délais d’évaluation, et configurez des options d’alerte avancées.
- Configure notifications and automations : Rédigez un titre et un message de notification personnalisés avec des variables. Choisissez comment les notifications sont envoyées à vos équipes (e-mail, Slack ou PagerDuty). Incluez des automatisations de workflow ou des cas dans la notification d’alerte.
- Define permissions and audit notifications : Configurez des contrôles d’accès granulaires et désignez des rôles et des utilisateurs spécifiques pouvant modifier un monitor. Activez les notifications d’audit pour être alerté si un monitor est modifié.
Définissez la requête de recherche
Pour savoir comment construire la requête de recherche, consultez les pages des types de monitor individuels.
Prévisualisez les graphiques
À mesure que vous créez ou modifiez votre requête, le graphique de prévisualisation en haut de la configuration se met à jour dynamiquement pour refléter les résultats en temps réel.
Le graphique Evaluated Data montre comment votre monitor aurait évalué les données en utilisant votre requête et vos seuils actuels. Avec la prévisualisation de l’évaluation, vous pouvez
- Voir les transitions d’état historiques (par exemple,
OK → ALERT). - Comprendre comment votre monitor se serait comporté.
- Prévisualiser qui aurait été notifié (y compris à partir des règles de notification)
- Repérez rapidement les erreurs de configuration avant d’enregistrer.
Cette fonctionnalité est prise en charge pour les monitors Metrics, Logs, APM, RUM, Events, Audit, Database, Agent Observability et Deployment.
Le graphique Source Data affiche les séries temporelles brutes ou le résultat de la requête pour votre monitor, sans aucune évaluation de seuil ni logique d’alerte appliquée. Cela vous permet de :
- Visualisez les données sous-jacentes que votre monitor évalue.
- Corrélez les changements d’état d’alerte avec les tendances réelles des données.
- Identifiez les anomalies, les lacunes ou les modèles inattendus dans vos données avant de configurer les conditions d’alerte.
Utilisez le graphique Source Data pour vous assurer que votre requête renvoie les résultats attendus et pour aider à affiner vos seuils d’alerte et vos fenêtres d’évaluation.
Définissez les conditions d’alerte
Les conditions d’alerte varient en fonction du type de monitor. Configurez les monitors pour qu’ils se déclenchent si la valeur de la requête dépasse un seuil, ou si un certain nombre de checks consécutifs ont échoué.
- Déclenchez lorsque la average, max, min ou sum de la métrique est
- above, above or equal to, below ou below or equal to le seuil
- au cours des 5 minutes, 15 minutes, 1 hour ou custom pour définir une valeur comprise entre 1 minute et 48 heures (1 mois pour les monitors de métriques)
Méthode d’agrégation
La requête renvoie une série de points, mais une valeur unique est nécessaire pour comparer au seuil. Le monitor doit réduire les données de la fenêtre d’évaluation à une valeur unique.
| Option | Description |
|---|
| average | La série est moyennée pour produire une valeur unique qui est comparée au seuil. Elle ajoute la fonction avg() à votre requête de monitor. |
| max | Si une seule valeur dans la série générée dépasse le seuil, alors une alerte est déclenchée. Elle ajoute la fonction max() à votre requête de monitor.* |
| min | Si tous les points de la fenêtre d’évaluation de votre requête dépassent le seuil, alors une alerte est déclenchée. Elle ajoute la fonction min() à votre requête de monitor.* |
| sum | Si la somme de chaque point de la série dépasse le seuil, alors une alerte est déclenchée. Elle ajoute la fonction sum() à votre requête de monitor. |
* Ces descriptions de max et min supposent que le monitor envoie une alerte lorsque la métrique passe au-dessus du seuil. Pour les monitors qui envoient une alerte lorsque la métrique passe en dessous du seuil, le comportement de max et min est inversé.
Remarque : Il existe des comportements différents lors de l’utilisation de as_count(). Voir as_count() dans les évaluations de monitor pour plus de détails.
Fenêtre d’évaluation
Un monitor peut être évalué en utilisant des fenêtres temporelles cumulatives ou des fenêtres temporelles glissantes. Les fenêtres temporelles cumulatives sont mieux adaptées aux questions qui nécessitent un contexte historique, telles que « Quelle est la somme de toutes les données disponibles jusqu’à ce moment précis ? » Les fenêtres temporelles glissantes sont mieux adaptées pour répondre aux questions qui ne nécessitent pas ce contexte, telles que « Quelle est la moyenne des N derniers points de données ? »
Le schéma ci-dessous illustre la différence entre les périodes cumulées et les périodes mobiles.
Fenêtres temporelles glissantes
Une fenêtre temporelle glissante a une taille fixe et déplace son point de départ au fil du temps. Les monitors peuvent examiner les 5 minutes, 15 minutes, 1 hour derniers, ou une fenêtre temporelle personnalisée allant jusqu’à 1 mois.
Remarque : Les monitors de logs ont une fenêtre temporelle glissante maximale de 2 days.
Fenêtres temporelles cumulatives
Une fenêtre temporelle cumulative a un point de départ fixe et s’étend au fil du temps. Les monitors prennent en charge trois fenêtres temporelles cumulatives différentes :
Current hour : Une fenêtre temporelle d’une heure maximum commençant à une minute configurable de l’heure. Par exemple, surveillez le nombre d’appels qu’un endpoint HTTP reçoit en une heure commençant à la minute 0.
Current day : Une fenêtre temporelle de 24 heures maximum commençant à une heure et une minute configurables de la journée. Par exemple, surveillez un quota d’index de logs quotidien en utilisant la fenêtre temporelle Current day et en la faisant commencer à 14h00 UTC.
Current month : Examine le mois en cours en commençant à un jour du mois, une heure et une minute configurables. Cette option représente une fenêtre temporelle du début du mois à aujourd’hui et n’est disponible que pour les monitors de métriques.
Une fenêtre temporelle cumulative est réinitialisée une fois sa durée maximale atteinte. Par exemple, une fenêtre temporelle cumulative examinant le Current month se réinitialise le premier de chaque mois à minuit UTC. Alternativement, une fenêtre temporelle cumulative de Current hour, qui commence à la minute 30, se réinitialise toutes les heures. Par exemple, à 6h30, 7h30, 8h30.
Fréquence d’évaluation
La fréquence d’évaluation définit la fréquence à laquelle Datadog exécute la requête du monitor. Pour la plupart des configurations, la fréquence d’évaluation est de 1 minute, ce qui signifie que chaque minute, le monitor interroge les données sélectionnées sur la fenêtre d’évaluation sélectionnée et compare la valeur agrégée aux seuils définis.
Par défaut, les fréquences d’évaluation dépendent de la fenêtre d’évaluation utilisée. Une fenêtre plus longue entraîne des fréquences d’évaluation plus faibles. Le tableau suivant illustre comment la fréquence d’évaluation est contrôlée par des fenêtres temporelles plus larges :
| Plages de fenêtres d’évaluation | Fréquence d’évaluation |
|---|
| fenêtre < 24 heures | 1 minute |
| 24 heures <= fenêtre < 48 heures | 10 minutes |
| fenêtre >= 48 heures | 30 minutes |
La fréquence d’évaluation peut également être configurée de manière à ce que la condition d’alerte du monitor soit vérifiée sur une base quotidienne, hebdomadaire ou mensuelle. Dans cette configuration, la fréquence d’évaluation ne dépend plus de la fenêtre d’évaluation, mais du planning configuré.
Pour plus d’informations, consultez le guide sur la manière de personnaliser la fréquence d’évaluation des monitors.
Seuils
Utilisez des seuils pour définir une valeur numérique permettant de déclencher une alerte. Selon la métrique choisie, l’éditeur affiche l’unité utilisée (byte, kibibyte, gibibyte, etc.).
Datadog propose deux types de notifications (alerte et avertissement). Les monitors se rétablissent automatiquement en fonction du seuil d’alerte ou d’avertissement, mais des conditions supplémentaires peuvent être spécifiées. Pour plus d’informations sur les seuils de rétablissement, consultez Qu’est-ce que les seuils de rétablissement ?. Par exemple, si un monitor envoie une alerte lorsque la métrique est supérieure à 3 et qu’aucun seuil de rétablissement n’est spécifié, le monitor se rétablit une fois que la valeur de la métrique repasse en dessous de 3.
| Option | Description |
|---|
| Alert threshold (requis) | La valeur utilisée pour déclencher une notification d’alerte. |
| Warning threshold | La valeur utilisée pour déclencher une notification d’avertissement. |
| Alert recovery threshold | Un seuil facultatif pour indiquer une condition supplémentaire pour le rétablissement de l’alerte. |
| Warning recovery threshold | Un seuil facultatif pour indiquer une condition supplémentaire pour le rétablissement de l’avertissement. |
Lorsque vous modifiez un seuil, l’aperçu du graphique dans l’éditeur affiche un marqueur qui indique le point limite.
Remarque : Lors de la saisie de valeurs décimales pour les seuils, si votre valeur est <1, ajoutez un 0 au début du nombre. Par exemple, utilisez 0.5, pas .5.
Une alerte de check récupère les statuts consécutifs envoyés pour chaque groupe de checks et les compare à vos seuils. Configurez l’alerte de check pour :
Déclenchez l’alerte après le nombre sélectionné d’échecs consécutifs : <NUMBER>
Chaque exécution de check soumet un statut unique de OK, WARN ou CRITICAL. Choisissez combien d’exécutions consécutives avec le statut WARN et CRITICAL déclenchent une notification. Par exemple, votre processus peut connaître une interruption momentanée lorsque la connexion échoue. Si vous définissez cette valeur sur > 1, l’interruption momentanée est ignorée, mais un problème avec plus d’un échec consécutif déclenche une notification.
Résolvez l’alerte après le nombre sélectionné de succès consécutifs : <NUMBER>
Choisissez combien d’exécutions consécutives avec le statut OK résout l’alerte.
Consultez la documentation sur les monitors de check de processus, check d’intégration et check personnalisé pour en savoir plus sur la configuration des alertes des checks.
Conditions d’alerte avancées
Aucune donnée
Les notifications pour les données manquantes sont utiles si vous attendez d’une métrique qu’elle rapporte toujours des données dans des circonstances normales. Par exemple, si un host avec l’Agent doit être opérationnel en continu, vous pouvez vous attendre à ce que la métrique system.cpu.idle rapporte toujours des données.
Dans ce cas, vous devez activer les notifications pour les données manquantes. Les sections ci-dessous expliquent comment accomplir cela avec chaque option.
Remarque : Le monitor doit être capable d’évaluer les données avant d’alerter sur des données manquantes. Par exemple, si vous créez un monitor pour service:abc et que les données de ce service ne sont pas transmises, le monitor n’envoie pas d’alertes.
Si des données sont manquantes pendant N minutes, sélectionnez une option dans le menu déroulant :
- Evaluate as zero / Show last known status
- Show NO DATA
- Show NO DATA and notify
- Show OK.
Le comportement sélectionné est appliqué lorsqu’une requête de monitor ne renvoie aucune donnée. Contrairement à l’option Do not notify, la fenêtre de données manquantes n’est pas configurable.
| Option | État du monitor et notification |
|---|
| Evaluate as zero | Le résultat vide est remplacé par zéro et est comparé aux seuils d’alerte/avertissement. Par exemple, si le seuil d’alerte est défini sur > 10, un zéro ne déclencherait pas cette condition, et l’état du monitor est défini sur OK. |
| Show last known status | Le dernier état connu du groupe ou du monitor est défini. |
| Show NO DATA | L’état du monitor est défini sur NO DATA. |
| Show NO DATA and notify | L’état du monitor est défini sur NO DATA et une notification est envoyée. |
| Show OK | Le monitor est résolu et l’état est défini sur OK. |
L’utilisation de default_zero() dans une requête verrouille le comportement en cas de données manquantes sur la valeur par défaut de ce type de requête et désactive les autres options :
- Pour les requêtes avec
default_zero(), les données manquantes sont toujours évaluées à zéro, et les autres comportements en cas de données manquantes ne sont pas disponibles. - Pour les requêtes sans
default_zero(), les requêtes Count utilisent Evaluate as zero par défaut, tandis que les autres types de requêtes utilisent Show last known status par défaut. Tous les comportements en cas de données manquantes restent disponibles.
Résolution automatique
[Never], After 1 hour, After 2 hours et ainsi de suite. résoudre automatiquement cet événement à partir d’un état déclenché.
La résolution automatique fonctionne lorsque les données ne sont plus soumises. Les monitors ne se résolvent pas automatiquement à partir d’un état ALERT ou WARN si des données sont toujours rapportées. Si des données sont toujours soumises, la fonctionnalité renotify peut être utilisée pour informer votre équipe lorsqu’un problème n’est pas résolu.
Pour certaines métriques qui sont rapportées périodiquement, il peut être judicieux que les alertes déclenchées se résolvent automatiquement après une certaine période. Par exemple, si vous avez un compteur qui ne rapporte que lorsqu’une erreur est enregistrée, l’alerte ne se résout jamais car la métrique ne rapporte jamais 0 comme nombre d’erreurs. Dans ce cas, configurez votre alerte pour qu’elle se résolve après une certaine durée d’inactivité de la métrique. Remarque : Si un monitor se résout automatiquement et que la valeur de la requête n’atteint pas le seuil de rétablissement lors de l’évaluation suivante, le monitor déclenche à nouveau une alerte.
Dans la plupart des cas, ce paramètre n’est pas utile car vous souhaitez qu’une alerte ne se résolve qu’une fois le problème réellement corrigé. Par conséquent, en général, il est logique de laisser ce paramètre sur [Never] afin que les alertes ne se résolvent que lorsque la métrique est au-dessus ou en dessous du seuil défini.
Durée de rétention du groupe
La rétention de groupe contrôle la durée pendant laquelle un groupe de monitors est conservé dans le statut du monitor après l’arrêt de la transmission des données. Une fois la période de rétention écoulée, le groupe expire et est supprimé du statut du monitor.
Par défaut, un groupe conserve son statut pendant 24 heures avant d’être supprimé. Les monitors de hosts et les checks de service qui notifient en cas de données manquantes conservent le statut pendant 48 heures.
Pour les monitors comportant de nombreux groupes, la rétention dynamique des groupes est activée par défaut. Datadog raccourcit automatiquement la période de rétention pour les groupes qui cessent de transmettre des données. Plus les groupes apparaissent et disparaissent fréquemment, plus la période de rétention devient courte, ce qui permet de maintenir la rapidité et l’efficacité du monitor. Ce comportement affecte uniquement les groupes qui ont cessé de transmettre des données ; les groupes qui transmettent activement des données ne sont jamais supprimés.
Pour les types de monitors multi-alertes qui prennent en charge la rétention personnalisée, vous pouvez définir une valeur comprise entre 1 heure et 72 heures. Sélectionnez Remove the non-reporting group after N (length of time).
Similaire à l’option de résolution automatique, la rétention de groupe fonctionne lorsque les données ne sont plus transmises. L’heure de début de la rétention de groupe et l’option de résolution automatique sont identiques dès que la requête du monitor ne renvoie aucune donnée.
Voici quelques cas d’utilisation pour définir une durée de rétention de groupe personnalisée :
- Lorsque vous souhaitez supprimer le groupe immédiatement ou peu de temps après l’arrêt de la transmission des données
- Lorsque vous souhaitez conserver le groupe dans le statut pendant la durée habituelle de votre dépannage
Remarque : L’option de durée de rétention de groupe personnalisée nécessite un monitor multi-alertes qui prend en charge l’option On missing data. Ces types de monitors sont les monitors APM Trace Analytics, Audit Logs, CI Pipelines, Error Tracking, Events, Logs et RUM.
Délai de nouveau groupe
Retardez le début de l’évaluation de N secondes pour les nouveaux groupes.
Le temps (en secondes) à attendre avant de commencer l’alerte, pour permettre aux nouveaux groupes créés de démarrer et aux applications de se lancer complètement. Il doit s’agir d’un entier non négatif.
Par exemple, si vous utilisez une architecture conteneurisée, la définition d’un délai de groupe empêche les groupes de monitors basés sur des conteneurs de se déclencher en raison d’une utilisation élevée des ressources ou d’une latence élevée lorsqu’un nouveau conteneur est créé. Le délai est appliqué à chaque nouveau groupe (qui n’a pas été vu au cours des dernières 24 heures) et est défini par défaut sur 60 secondes.
Cette option est disponible pour les monitors à alertes multiples.
Délai d’évaluation
Datadog recommande un délai de 15 minutes pour les métriques cloud, qui sont complétées a posteriori par les fournisseurs de services. De plus, lors de l'utilisation d'une formule de division, un délai de 60 secondes est utile pour garantir que votre monitor évalue des valeurs complètes. Consultez la page
Cloud Metric Delay pour connaître les délais estimés.
Différer l’évaluation de N secondes.
Le temps (en secondes) pour différer l’évaluation. Il doit s’agir d’un entier non négatif. Ainsi, si le délai est réglé sur 900 secondes (15 minutes), que l’évaluation du monitor a lieu pendant les 5 minutes dernières, et qu’il est 7h00, le monitor évalue les données de 6h40 à 6h45. Le délai d’évaluation configurable maximal est de 86400 secondes (24 heures).
Configurez vos messages de notification de façon à inclure les informations qui vous intéressent le plus. Indiquez les équipes auxquelles ces alertes doivent être envoyées, ainsi que les attributs pour lesquels les alertes doivent se déclencher.
Message
Utilisez cette section pour configurer les notifications envoyées à votre équipe et la façon dont elles sont envoyées :
Pour en savoir plus sur les options de configuration du message de notification, consultez la section Notifications Alerting.
Les tags de monitor sont indépendants des tags envoyés par l'Agent ou les intégrations. Consultez la documentation
Gérer les monitors.
- Utilisez le menu déroulant Tags pour associer des tags à votre monitor.
- Utilisez le menu déroulant Teams pour associer des équipes à votre monitor.
- Choisissez un Priority.
Définissez l’agrégation des alertes
Les alertes sont regroupées automatiquement en fonction de votre sélection de l’agrégation choisie pour votre requête (par exemple, avg by service). Si la requête ne comporte aucun regroupement, elle utilise Simple Alert par défaut. Si la requête est regroupée par une dimension quelconque, le regroupement passe à Multi Alert.
Alerte simple
Simple AlertLe mode déclenche une notification en agrégeant toutes les sources de rapport. Vous recevez une alerte lorsque la valeur agrégée remplit les conditions définies. Par exemple, vous pourriez configurer un monitor pour vous avertir si l’utilisation moyenne du processeur de tous les serveurs dépasse un certain seuil. Si ce seuil est atteint, vous recevrez une notification unique, quel que soit le nombre de serveurs individuels ayant atteint le seuil. Cela peut être utile pour surveiller les tendances ou les comportements généraux du système.
Alerte multiple
Un Multi Alert monitor déclenche des notifications individuelles pour chaque entité de votre monitor qui atteint le seuil d’alerte.
Par exemple, lors de la configuration d’un monitor pour vous avertir si la latence P99, agrégée par service, dépasse un certain seuil, vous recevriez une alerte distincte pour chaque service individuel dont la latence P99 a dépassé le seuil d’alerte. Cela peut être utile pour identifier et traiter des instances spécifiques de problèmes système ou d’application. Cela vous permet de suivre les problèmes à un niveau plus granulaire.
Regroupement des notifications
Lors de la surveillance d’un grand groupe d’entités, les alertes multiples peuvent entraîner des monitors bruyants. Pour atténuer cela, personnalisez les dimensions qui déclenchent les alertes. Cela réduit le bruit et vous permet de vous concentrer sur les alertes les plus importantes. Par exemple, vous surveillez l’utilisation moyenne du processeur de tous vos hosts. Si vous regroupez votre requête par service et host mais que vous souhaitez uniquement que des alertes soient envoyées une fois pour chaque attribut service atteignant le seuil, supprimez l’attribut host de vos options d’alerte multiple et réduisez le nombre de notifications qui sont envoyées.
Lors de l’agrégation des notifications en mode Multi Alert, les dimensions sur lesquelles l’agrégation n’est pas effectuée deviennent Sub Groups dans l’interface utilisateur.
Remarque : Si votre métrique ne fait l’objet de rapports que par host sans tag service, elle n’est pas détectée par le monitor. Les métriques avec les tags host et service sont détectées par le monitor.
Si vous configurez des tags ou des dimensions dans votre requête, ces valeurs sont disponibles pour chaque groupe évalué dans l’alerte multiple afin de remplir dynamiquement les notifications avec un contexte utile. Consultez Variables d’attribut et de tag pour savoir comment référencer les valeurs de tag dans le message de notification.
| Regrouper par | Mode alerte simple | Mode alerte multiple |
|---|
| (tout) | Un seul groupe déclenchant une notification | N/A |
| 1 dimension ou plus | Une notification si un ou plusieurs groupes remplissent les conditions d’alerte | Une notification par groupe remplissant les conditions d’alerte |
Autorisations
Tous les utilisateurs peuvent voir tous les monitors, quelle que soit l’équipe ou le rôle auquel ils sont associés. Par défaut, seuls les utilisateurs rattachés à des rôles disposant de l’autorisation d’écriture sur les monitors peuvent modifier les monitors. Les rôles Datadog Admin et Datadog standard disposent par défaut de l’autorisation d’écriture sur les monitors. Si votre organisation utilise des rôles personnalisés, d’autres rôles personnalisés peuvent disposer de l’autorisation d’écriture sur les monitors. Pour plus d’informations sur la configuration du RBAC pour Monitors et la migration des Monitors du paramètre verrouillé vers l’utilisation de restrictions de rôle, consultez le guide sur How to set up RBAC for Monitors.
Vous pouvez restreindre davantage votre monitor en spécifiant une liste d’équipes, de rôles ou d’utilisateurs autorisés à le modifier. Le créateur du monitor dispose par défaut des droits de modification sur celui-ci. Il est notamment possible de modifier la configuration du monitor, de supprimer le monitor et de désactiver ses notifications pendant la durée souhaitée.
Remarque : Les limitations s’appliquent à la fois dans l’interface utilisateur et dans l’API.
Contrôles d’accès granulaires
Utilisez les contrôles d’accès granulaires pour limiter les équipes, rôles ou utilisateurs autorisés à modifier un monitor :
- Lors de la modification ou de la configuration d’un monitor, recherchez la section Define permissions and audit notifications.
- Cliquez sur Edit Access.
- Cliquez sur Restrict Access.
- La boîte de dialogue se met à jour pour indiquer que les membres de votre organisation ont un accès Viewer par défaut.
- Utilisez le menu déroulant pour sélectionner une ou plusieurs équipes, rôles ou utilisateurs pouvant modifier le monitor.
- Cliquez sur Add.
- La boîte de dialogue se met à jour pour indiquer que le rôle que vous avez sélectionné dispose de l’autorisation Editor.
- Cliquez sur Done.
Remarque : Pour conserver votre accès en modification au monitor, le système exige que vous incluiez au moins un rôle ou une équipe dont vous êtes membre avant d’enregistrer.
Pour rétablir les autorisations globales d’un monitor restreint, procédez comme suit :
- Lors de la consultation d’un monitor, cliquez sur le menu déroulant More.
- Sélectionnez Permissions.
- Cliquez sur Restore Full Access.
- Cliquez sur Save.
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles:
