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.
Connecter DataDog
Built-in, intégration unidirectionnelle
À l'heure actuelle, AWS DevOps l'Agent prend en charge les utilisateurs de Datadog grâce à une intégration unidirectionnelle intégrée, qui permet ce qui suit :
Déclenchement automatique des enquêtes : les événements Datadog peuvent être configurés pour déclencher AWS DevOps des enquêtes de résolution d'incidents par le biais des webhooks des AWS DevOps agents.
Introspection de la télémétrie : l' AWS DevOps agent peut examiner la télémétrie Datadog lorsqu'il étudie un problème via le serveur MCP distant de chaque fournisseur.
Intégration
Étape 1 : Connect
Établissez une connexion à votre point de terminaison MCP distant Datadog à l'aide des identifiants d'accès au compte
Configuration
Accédez à la page Capability Providers (accessible depuis la navigation latérale)
Trouvez Datadog dans la section Fournisseurs disponibles sous Télémétrie et choisissez Register
Entrez les détails de votre serveur Datadog MCP :
Nom du serveur : identifiant unique (par exemple, my-datadog-server)
URL du point de terminaison : le point de terminaison de votre serveur MCP Datadog. L'URL du point de terminaison varie en fonction de votre site Datadog. Consultez le tableau des points de terminaison du site Datadog ci-dessous.
Description : description facultative du serveur
Choisissez Next (Suivant)
Vérification et soumission
Points de terminaison du site Datadog
L'URL du point de terminaison MCP varie en fonction de votre site Datadog. Pour identifier votre site, vérifiez l'URL dans votre navigateur lorsque vous êtes connecté à Datadog, ou consultez Accéder au site Datadog
| Site Datadog | Domaine du site | URL du point de terminaison MCP |
|---|---|---|
| US1 (par défaut) | datadoghq.com |
https://mcp.datadoghq.com/api/unstable/mcp-server/mcp |
| US3 | us3.datadoghq.com |
https://mcp.us3.datadoghq.com/api/unstable/mcp-server/mcp |
| US5 | us5.datadoghq.com |
https://mcp.us5.datadoghq.com/api/unstable/mcp-server/mcp |
| EU1 | datadoghq.eu |
https://mcp.datadoghq.eu/api/unstable/mcp-server/mcp |
| AP 1 | ap1.datadoghq.com |
https://mcp.ap1.datadoghq.com/api/unstable/mcp-server/mcp |
| AP 2 | ap2.datadoghq.com |
https://mcp.ap2.datadoghq.com/api/unstable/mcp-server/mcp |
Autorisation
Complétez l'autorisation OAuth en :
Autorisation en tant qu'utilisateur sur la page OAuth de Datadog
Si vous n'êtes pas connecté, choisissez Autoriser, connectez-vous, puis autorisez
Une fois configuré, Datadog est disponible dans tous les espaces Agent.
Étape 2 : activer
Activez DataDog dans un espace d'agent spécifique et configurez le scoping approprié
Configuration
Sur la page des espaces d'agent, sélectionnez un espace d'agent et appuyez sur Afficher les détails (si vous n'avez pas encore créé d'espace d'agent, voirCréation d'un espace d'agents)
Sélectionnez l'onglet Fonctionnalités
Faites défiler la page jusqu'à la section Télémétrie
Appuyez sur Ajouter
Sélectionnez Datadog
Suivant
Vérifiez et appuyez sur Enregistrer
Copiez l'URL du webhook et la clé d'API (affichées une fois lors de la sauvegarde ; la clé d'API ne pourra pas être consultée ultérieurement. Si vous la perdez, régénérez-la à partir des détails du webhook dans l'onglet Capabilities, ce qui invalide la clé précédente)
Étape 3 : Configuration des webhooks
À l'aide de l'URL du webhook et de la clé d'API indiquées à l'étape 2, vous pouvez configurer Datadog pour qu'il envoie des événements qui déclenchent une enquête, par exemple lorsqu'un moniteur émet une alerte.
Les webhooks Datadog utilisent l'authentification par jeton porteur. Pour le format général de demande de webhook et le schéma de charge utile, voir. Invocation de DevOps l'agent via Webhook Les sections suivantes fournissent une configuration Datadog prête à l'emploi ; vous n'avez pas besoin de créer vous-même la charge utile.
Étape 3.1 : Création du webhook dans Datadog
Dans Datadog, ouvrez Integrations, recherchez Webhooks et ouvrez la vignette d'intégration. Pour plus d'informations, consultez Webhooks
dans la documentation de Datadog. Sous Webhooks, choisissez Nouveau.
Dans Nom, entrez un nom tel que
devops-agent. Vous faites référence à ce nom comme@webhook-devops-agentdans les messages du moniteur.Pour l'URL, collez l'URL du webhook de l'étape 2 (visible à nouveau depuis l'entrée Datadog de l'onglet Capabilities de votre espace agent).
Pour Charge utile, remplacez la charge utile par défaut par le modèle de l'étape 3.2.
Laissez la méthode d'authentification non configurée, sélectionnez plutôt les en-têtes personnalisés et entrez l'en-tête illustré dans l'exemple suivant, en le
<API_KEY_FROM_STEP_2>remplaçant par la clé API de l'étape 2.Laissez Encode comme formulaire effacé. Le point de terminaison du webhook nécessite un corps JSON brut ; le codage du formulaire entraîne l'échec du traitement de la charge utile.
Enregistrez le webhook.
Valeur d'en-tête personnalisée pour l'étape 6 :
{"Authorization": "Bearer <API_KEY_FROM_STEP_2>"}
Pour éviter de stocker la clé en clair, définissez une variable personnalisée (par exemple,$DEVOPS_AGENT_API_KEY) dans la vignette du webhook en sélectionnant Masquer de la vue, et référencez plutôt la variable dans la valeur d'en-tête.
Étape 3.2 : Modèle de charge utile pour les alertes déclenchées par le moniteur
Le modèle suivant fonctionne pour les alertes de surveillance standard, notamment les moniteurs métriques, log, APM et Synthetics. Datadog remplace les $VARIABLE espaces réservés lorsqu'il envoie le webhook ; laissez-les tels quels.
{ "eventType": "incident", "incidentId": "datadog-$ALERT_CYCLE_KEY", "action": "created", "priority": "HIGH", "title": "$ALERT_TITLE", "description": "$TEXT_ONLY_MSG", "service": "datadog", "data": { "monitorId": "$ALERT_ID", "eventType": "$EVENT_TYPE", "alertQuery": "$ALERT_QUERY", "alertScope": "$ALERT_SCOPE", "alertMetric": "$ALERT_METRIC", "alertTransition": "$ALERT_TRANSITION", "alertPriority": "$ALERT_PRIORITY", "tags": "$TAGS", "eventUrl": "$LINK", "hostname": "$HOSTNAME" } }
Comment les variables Datadog sont mappées au schéma du webhook
| Champ Webhook | Valeur à utiliser | Remarques |
|---|---|---|
eventType |
La chaîne littérale incident |
Constante requise. |
incidentId |
datadog-$ALERT_CYCLE_KEY |
$ALERT_CYCLE_KEYreste identique entre le moment où un moniteur se déclenche et celui où il est résolu, de sorte que les nouvelles notifications sont dédupliquées en une seule enquête. Utilisez plutôt $ID (l'ID par événement) uniquement si vous souhaitez que chaque notification lance une enquête distincte. |
action |
La chaîne littérale created |
Ne pas $ALERT_TRANSITION mapper vers ce champ. Ses valeurs (telles que Triggered etRecovered) ne sont pas action des valeurs valides. Contrôlez plutôt le moment où le webhook se déclenche à partir du message du moniteur (voir Étape 3.3). |
priority |
L'une des chaînes littéralesCRITICAL,HIGH, MEDIUMLOW, ou MINIMAL |
Ne pas utiliser $ALERT_PRIORITY ici. Elle s'étend aux priorités de monitoring de Datadog (P1—P5), qui ne sont pas des valeurs valides pour ce champ. Le webhook renvoie une réponse de 200, mais aucune enquête ne démarre. Pour envoyer différentes priorités, créez un webhook par niveau de priorité (par exemple, devops-agent-critical etdevops-agent-high) et référencez le webhook approprié pour chaque moniteur. |
title |
$ALERT_TITLE |
Titre de l'alerte du moniteur. |
description |
$TEXT_ONLY_MSG |
Le texte de l'événement avec Markdown supprimé. Préférez cette solution à $EVENT_MSG celle dont le formatage Markdown ajoute du bruit. |
service |
Un nom de service littéral | Facultatif. Chaîne statique identifiant la source, telle que le datadog nom de votre service. |
timestamp |
Omettre | Facultatif. Les variables de date ($DATE,$DATE_POSIX) de Datadog sont des valeurs d'époque, et non le format ISO 8601 attendu par ce champ. Par conséquent, omettez le champ. |
data |
Variables de contexte Datadog | Facultative mais recommandée. Tout ce qui data est introduit est transmis à l'agent en tant qu'événement d'origine, ce qui donne à l'enquête la requête de surveillance, le champ d'application, les balises et un lien renvoyant vers l'événement Datadog. |
Étape 3.3 : Référencez le webhook depuis vos moniteurs
Dans chaque moniteur dont les alertes devraient déclencher une enquête, ajoutez la mention du webhook au message du moniteur, de manière à ce que seule la transition d'alerte le déclenche :
{{#is_alert}} @webhook-devops-agent {{/is_alert}}
Sans les {{#is_alert}} conditions, les notifications d'avertissement et de restauration envoient également le webhook. Les événements de restauration sont dédupliqués par rapport à l'enquête ouverte$ALERT_CYCLE_KEY, mais les avertissements déclenchent des enquêtes pour des seuils que vous ne souhaitez peut-être pas examiner.
Vérifiez la configuration
Envoyez une notification de test depuis un moniteur (notifications de test dans l'éditeur de moniteur) et confirmez les points suivants :
Le webhook renvoie une réponse de 200. Vous pouvez consulter le statut de livraison dans le flux d'événements de l'intégration du webhook Datadog. Une réponse 4xx signifie que l'
Authorizationen-tête est incorrect. Re-check la clé API et confirmez que l'option Encoder en tant que formulaire est désactivée.Une enquête commence dans votre espace d'agents. (L'enquête relative à une notification de test se termine sans cause première, c'est normal.) Une réponse 200 sans enquête signifie que la charge utile n'a pas été validée après son acceptation. Vérifiez le corps de la réponse du webhook dans le flux d'événements Datadog : une charge utile non valide renvoie une réponse 200 dont le corps répertorie les erreurs de validation (par exemple,
'P2' is not one of ['CRITICAL', 'HIGH', ...]), tandis qu'une charge utile valide est renvoyée.{"message": "Webhook received"}Les causes les plus courantes sont unepriorityvaleur non littérale (voir le tableau de mappage précédent) et un doublonincidentIdd'un test antérieur au cours du même cycle d'alerte.
Pour la résolution générale des problèmes liés aux webhooks, consultezInvocation de DevOps l'agent via Webhook.
Pour en savoir plus : Serveur MCP distant Datadog
Enlèvement
La source de télémétrie est connectée à deux niveaux, au niveau de l'espace agent et au niveau du compte. Pour le supprimer complètement, vous devez d'abord le supprimer de tous les espaces d'agent où il est utilisé, puis il peut être désenregistré.
Étape 1 : Supprimer de l'espace agent
Sur la page des espaces d'agent, sélectionnez un espace d'agent et appuyez sur Afficher les détails
Sélectionnez l'onglet Fonctionnalités
Faites défiler la page jusqu'à la section Télémétrie
Sélectionnez Datadog
Appuyez sur Supprimer
Étape 2 : Désenregistrer du compte
Accédez à la page Capability Providers (accessible depuis la navigation latérale)
Accédez à la section Actuellement enregistré.
Vérifiez que le nombre d'espaces d'agent est nul (sinon, répétez l'étape 1 ci-dessus dans vos autres espaces d'agent)
Sélectionnez Datadog, puis choisissez Désenregistrer dans le menu Actions.