View a markdown version of this page

Connecter DataDog - AWS DevOps Agent

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

  1. Accédez à la page Capability Providers (accessible depuis la navigation latérale)

  2. Trouvez Datadog dans la section Fournisseurs disponibles sous Télémétrie et choisissez Register

  3. 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

  4. Choisissez Next (Suivant)

  5. 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

  1. 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)

  2. Sélectionnez l'onglet Fonctionnalités

  3. Faites défiler la page jusqu'à la section Télémétrie

  4. Appuyez sur Ajouter

  5. Sélectionnez Datadog

  6. Suivant

  7. Vérifiez et appuyez sur Enregistrer

  8. 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

  1. Dans Datadog, ouvrez Integrations, recherchez Webhooks et ouvrez la vignette d'intégration. Pour plus d'informations, consultez Webhooks dans la documentation de Datadog.

  2. Sous Webhooks, choisissez Nouveau.

  3. Dans Nom, entrez un nom tel quedevops-agent. Vous faites référence à ce nom comme @webhook-devops-agent dans les messages du moniteur.

  4. 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).

  5. Pour Charge utile, remplacez la charge utile par défaut par le modèle de l'étape 3.2.

  6. 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.

  7. 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.

  8. 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 (P1P5), 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 :

  1. 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.

  2. 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 une priority valeur non littérale (voir le tableau de mappage précédent) et un doublon incidentId d'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

  1. Sur la page des espaces d'agent, sélectionnez un espace d'agent et appuyez sur Afficher les détails

  2. Sélectionnez l'onglet Fonctionnalités

  3. Faites défiler la page jusqu'à la section Télémétrie

  4. Sélectionnez Datadog

  5. Appuyez sur Supprimer

Étape 2 : Désenregistrer du compte

  1. Accédez à la page Capability Providers (accessible depuis la navigation latérale)

  2. Accédez à la section Actuellement enregistré.

  3. 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)

  4. Sélectionnez Datadog, puis choisissez Désenregistrer dans le menu Actions.