Pour utiliser votre webhook, ajoutez @webhook-<NOM_WEBHOOK> dans le texte de l’alerte de métrique qui déclenchera le webhook. Une requête POST sera envoyée à l’URL que vous avez spécifiée avec le contenu suivant au format JSON. Toutes les requêtes individuelles expirent au bout de 15 secondes. Datadog n’effectue une nouvelle tentative qu’en cas d’erreur interne (message de notification incorrect) ou en cas de réception d’une réponse 5XX de la part de l’endpoint du webhook. Si un échec de connexion se produit, 5 nouvelles tentatives sont effectuées.
Remarque : les en-têtes personnalisés doivent être au format JSON.
Pour ajouter vos propres champs personnalisés à la requête, vous pouvez également spécifier votre propre charge utile dans le champ Payload. Si vous souhaitez encoder votre charge utile pour une URL, cochez la case Encode as form et indiquez votre charge utile au format JSON. Utilisez les variables de la section suivante.
ID permettant d’agréger des événements connexes. Exemple : 9bd4ac313a4d1e8fae2482df7b77628
$ALERT_CYCLE_KEY
ID permettant d’associer des événements depuis le déclenchement d’une alerte jusqu’à sa résolution.
$ALERT_ID
ID de l’alerte. Exemple : 1234
$ALERT_METRIC
Nom de la métrique s’il s’agit d’une alerte. Exemple : system.load.1
$ALERT_PRIORITY
Priorité du monitor envoyant l’alerte. Exemple : P1, P2
$ALERT_QUERY
Requête du monitor qui a déclenché le webhook.
$ALERT_SCOPE
Liste des tags déclenchant l’alerte séparés par des virgules. Exemple : availability-zone:us-east-1a, role:computing-node
$ALERT_STATUS
Résumé du statut d’alerte. Exemple : system.load.1 over host:my-host was > 0 at least once during the last 1mRemarque : pour ajouter cette variable dans des charges utiles de webhook depuis des alertes de monitor de log, vous devez ajouter manuellement $ALERT_STATUS au carré de l’intégration Webhook.
$ALERT_TITLE
Titre de l’alerte. Exemple : error, warning, success, info
$ALERT_TRANSITION
Type de notification de l’alerte. Exemple : Recovered, Triggered/Re-Triggered, No Data/Re-No Data, Warn/Re-Warn, Renotify
$ALERT_TYPE
Type de l’alerte.
$DATE
Date (epoch) à laquelle l’événement s’est produit. Exemple : 1406662672000
$EMAIL
Adresse e-mail de l’utilisateur publiant l’événement qui a déclenché le webhook.
$EVENT_MSG
Texte de l’événement. Exemple : @webhook-url Sending to the webhook
$EVENT_TITLE
Titre de l’événement. Exemple : [Triggered] [Memory Alert]
$EVENT_TYPE
Type de l’événement. Exemple : metric_alert_monitor, event_alert ou service_check.
$HOSTNAME
Hostname du serveur associé à l’événement (le cas échéant).
$ID
ID de l’événement. Exemple : 1234567
$INCIDENT_ATTACHMENTS
Liste d’objets JSON comportant les pièces jointes de l’incident, notamment les analyses post-mortem et les documents associés. Exemple : [{"attachment_type": "postmortem", "attachment": {"url": "https://app.datadoghq.com/notebook/123","title": "Postmortem IR-1"}}]
$INCIDENT_COMMANDER
Objet JSON comportant le handle, l’uuid, le nom, l’adresse e-mail et l’icône du responsable de l’incident.
$INCIDENT_CUSTOMER_IMPACT
Objet JSON comportant le statut de l’impact client, la durée et la portée de l’incident. Exemple : {"customer_impacted": true, "customer_impact_duration": 300 ,"customer_impact_scope": "scope here"}
$INCIDENT_FIELDS
Objet JSON mappant chaque champ de l’incident à sa valeur respective. Exemple : {"state": "active", "datacenter": ["eu1", "us1"]}
$INCIDENT_PUBLIC_ID
ID public de l’incident associé. Exemple : 123
$INCIDENT_TITLE
Titre de l’incident.
$INCIDENT_SEVERITY
Gravité de l’incident
$INCIDENT_STATUS
Statut de l’incident
$INCIDENT_URL
URL de l’incident. Exemple : https://app.datadoghq.com/incidents/1
$INCIDENT_MSG
Message de la notification de l’incident.
$LAST_UPDATED
Date de la dernière mise à jour de l’événement.
$LINK
URL de l’événement. Exemple : https://app.datadoghq.com/event/jump_to?event_id=123456
$LOGS_SAMPLE
Échantillon de logs provenant d’alertes de log monitor.
$METRIC_NAMESPACE
Espace de nommage de la métrique s’il s’agit d’une alerte.
$ORG_ID
ID de votre organisation. Exemple : 11023
$ORG_NAME
Nom de votre organisation. Exemple : Datadog
$PRIORITY
Priorité de l’événement. Exemple : normal or low
$SECURITY_RULE_NAME
Nom de la règle de sécurité.
$SECURITY_SIGNAL_ID
Identifiant unique du signal. Exemple : AAAAA-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
$SECURITY_SIGNAL_SEVERITY
Gravité du signal de sécurité. Exemple : medium
$SECURITY_SIGNAL_TITLE
Titre du signal de sécurité.
$SECURITY_SIGNAL_MSG
Message du signal de sécurité.
$SECURITY_SIGNAL_ATTRIBUTES
Attributs du signal de sécurité. Exemple : {"network":{"client":{"ip":"1.2.3.4"}}, "service": ["agent"]}
$SECURITY_RULE_ID
ID de la règle de sécurité. Exemple : aaa-aaa-aaa
$SECURITY_RULE_QUERY
Requête(s) associée(s) à la règle de sécurité. Exemple : ["@evt.name:authentication"]
$SECURITY_RULE_GROUP_BY_FIELDS
Groupe de sécurité en fonction des paires key/value. Exemple : {"@usr.name":"john.doe@your_domain.com"}
$SECURITY_RULE_TYPE
Type de règle de sécurité. Exemple : log_detection
$SNAPSHOT
URL de l’image si l’événement contient un snapshot. Exemple : https://p.datadoghq.com/path-to-snapshot
$SYNTHETICS_TEST_NAME
Nom du test Synthetic.
$SYNTHETICS_FIRST_FAILING_STEP_NAME
Nom de la première étape qui échoue du test Synthetic.
$SYNTHETICS_SUMMARY
Synthèse des informations sur le test Synthetic. Exemple :
Liste des tags associés à l’événement séparés par des virgules. Exemple : monitor, name:myService, role:computing-node
$TAGS[key]
Valeur du tag key tag. S’il n’y a pas de tag key, ou s’il ne possède aucune valeur, cette expression renvoie une chaîne vide.
Exemple : si $TAGS inclut role:computing-node, alors $TAGS[role] renvoie computing-node.
$TEXT_ONLY_MSG
Texte de l’événement sans mise en forme markdown.
$USER
Utilisateur publiant l’événement qui a déclenché le webhook. Exemple : rudy
$USERNAME
Nom de l’utilisateur publiant l’événement qui a déclenché le webhook.
Si vous souhaitez envoyer vos webhooks vers un service nécessitant une authentification, vous pouvez utiliser l’authentification HTTP standard en remplaçant votre URL https://mon.service.example.com par https://<NOMUTILISATEUR>:<MOTDEPASSE>@mon.service.example.com.
Dans une alerte de monitor, si au moins 2 endpoints de webhook sont notifiés, une file d’attente de webhooks est alors créée pour chaque service. Cela signifie que si vous communiquez avec Pagerduty et Slack (par exemple), une nouvelle tentative sur le webhook Slack n’affectera pas le webhook Pagerduty.
Néanmoins, dans le contexte Pagerduty, certains événements passent toujours avant les autres. En particulier, une charge utile « Acknowledge » passe toujours avant « Resolution ». De cette manière, si un ping « Acknowledge » échoue, le ping « Resolution » sera mis en attente conformément à la logique de nouvelle tentative.
{"fields":{"project":{"key":"VOTRE-CLÉ-PROJET"},"issuetype":{"name":"Task"},"description":"Une erreur s'est produite. Consultez le graphique $SNAPSHOT ainsi que l'événement $LINK","summary":"$EVENT_TITLE"}}