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
Actuellement, AWS DevOps l'Agent prend en charge les utilisateurs de Datadog grâce à une intégration unidirectionnelle intégrée, qui permet de :
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 via les webhooks de AWS DevOps l'agent.
Introspection télémétrique : l' AWS DevOps agent peut effectuer une introspection de la télémétrie Datadog lorsqu'il étudie un problème via le serveur MCP distant de chaque fournisseur.
Intégration
Étape 1 : Connexion
Établissez une connexion à votre endpoint MCP distant Datadog à l'aide des informations 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, puis choisissez Enregistrer
Entrez les informations relatives à votre serveur Datadog MCP :
Nom du serveur : identifiant unique (par exemple, my-datadog-server)
URL du point de terminaison : point de terminaison de votre serveur Datadog MCP. 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 de votre navigateur lorsque vous êtes connecté à Datadog, ou consultez la section 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 |
| NOUS3 | us3.datadoghq.com |
https://mcp.us3.datadoghq.com/api/unstable/mcp-server/mcp |
| NOUS5 | us5.datadoghq.com |
https://mcp.us5.datadoghq.com/api/unstable/mcp-server/mcp |
| UE-1 | datadoghq.eu |
https://mcp.datadoghq.eu/api/unstable/mcp-server/mcp |
| AP1 | ap1.datadoghq.com |
https://mcp.ap1.datadoghq.com/api/unstable/mcp-server/mcp |
| AP2 | 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 devient disponible dans tous les espaces d'agent.
Chaque inscription permet de se connecter à une organisation Datadog. Pour connecter d'autres organisations Datadog, répétez cette procédure pour chacune d'entre elles et attribuez à chaque enregistrement son propre nom de serveur.
Étape 2 : activer
Activez DataDog dans un espace d'agent spécifique et configurez la portée appropriée
Configuration
Sur la page des espaces agents, sélectionnez un espace agent et appuyez sur Afficher les détails (si vous n'avez pas encore créé d'espace agent, voirCréation d'un espace d'agents)
Sélectionnez l'onglet Capacités
Faites défiler la page jusqu'à la section Télémétrie
Appuyez sur Ajouter
Choisissez l'enregistrement Datadog que vous souhaitez activer.
Suivant
Vérifiez et appuyez sur Enregistrer
Copiez l'URL du Webhook et la clé API (affichées une fois lors de la sauvegarde ; la clé API ne peut 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)
Un seul espace d'agent peut utiliser plusieurs enregistrements Datadog. Pour ajouter un autre enregistrement, répétez ces étapes.
Étape 3 : Configuration des webhooks
À l'aide de l'URL du Webhook et de la clé d'API de 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 du porteur. Pour le format général de demande de webhook et le schéma de charge utile, consultez. Invoquer un DevOps 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 Intégrations, recherchez Webhooks et ouvrez la vignette d'intégration. Pour plus d'informations, consultez la section Webhooks
dans la documentation Datadog. Sous Webhooks, choisissez Nouveau.
Dans le champ 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 (consultable à nouveau depuis l'entrée Datadog de l'onglet Capabilities de votre espace agent).
Pour la 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 et sélectionnez à la place des 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 le formulaire Encode as a été désactivé. 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 faites plutôt référence à 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 moniteur standard, y compris les moniteurs métriques, journaux, APM et synthétiques. Datadog remplace les $VARIABLE espaces réservés lorsqu'il envoie le webhook ; conservez-les tels qu'ils sont écrits.
{ "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 sa résolution, de sorte que les renotifications sont dédupliquées en une seule enquête. Utilisez plutôt $ID (l'identifiant par événement) uniquement si vous souhaitez que chaque notification déclenche une enquête distincte. |
action |
La chaîne littérale created |
Ne $ALERT_TRANSITION mappez pas 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 moniteur 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 n'est lancée. 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é sur 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 celui-ci$EVENT_MSG, dont le formatage Markdown ajoute du bruit. |
service |
Un nom de service littéral | Facultatif. Chaîne statique identifiant la source, par exemple 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, donc omettez ce champ. |
data |
Variables de contexte Datadog | Facultative mais recommandée. Tout ce qui data est saisi est transmis à l'agent en tant qu'événement d'origine, fournissant à l'enquête la requête du monitor, la portée, les balises et un lien 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, en veillant à ce que seule la transition d'alerte la 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 lancent des enquêtes pour les 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 ce qui suit :
Le webhook renvoie une réponse 200. Vous pouvez consulter l'état de diffusion dans le flux d'événements de l'intégration du webhook Datadog. Une réponse 4xx signifie que l'
Authorizationen-tête est erroné. 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 agent. (L'enquête sur 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 renvoie.{"message": "Webhook received"}Les causes les plus courantes sont unepriorityvaleur non littérale (voir le tableau de mappage précédent) et une duplicationincidentIdd'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, consultezInvoquer un DevOps agent via Webhook.
Pour en savoir plus : Datadog Remote MCP Server
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 vous pouvez le désenregistrer.
É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 Capacité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 égal à zéro (si ce n'est pas le cas, répétez l'étape 1 ci-dessus dans vos autres espaces d'agent)
Sélectionnez Datadog, puis cliquez sur Désenregistrer dans le menu Actions.