Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Verbindung herstellen DataDog
Built-in, Einweg-Integration
Derzeit unterstützt AWS DevOps Agent Datadog-Benutzer mit einer integrierten 1-Wege-Integration, die Folgendes ermöglicht:
Automatisches Auslösen von Ermittlungen — Datadog-Ereignisse können so konfiguriert werden, dass sie mithilfe von Agenten-Webhooks Untersuchungen zur Behebung von AWS DevOps Agentenvorfällen auslösen. AWS DevOps
Telemetrie-Introspektion — AWS DevOps Der Agent kann die Datadog-Telemetrie überprüfen, während er ein Problem über den Remote-MCP-Server jedes Anbieters untersucht.
Einarbeitung
Schritt 1: Verbinden
Stellen Sie mit den Zugangsdaten für den Kontozugriff eine Verbindung zu Ihrem Datadog-Remote-MCP-Endpunkt her
Konfiguration
Gehen Sie zur Seite Capability Providers (zugänglich über die Seitennavigation)
Suchen Sie im Abschnitt Verfügbare Anbieter unter Telemetrie nach Datadog und wählen Sie Registrieren aus
Geben Sie Ihre Datadog MCP-Serverdetails ein:
Servername — Eindeutige Kennung (z. B. my-datadog-server)
Endpunkt-URL — Ihr Datadog MCP-Serverendpunkt. Die Endpunkt-URL variiert je nach Ihrer Datadog-Website. Weitere Informationen finden Sie in der Tabelle mit den Endpunkten der Datadog-Site unten.
Beschreibung — Optionale Serverbeschreibung
Wählen Sie Weiter
Überprüfen und Einreichen
Endpunkte der Datadog-Site
Die URL des MCP-Endpunkts variiert je nach Ihrer Datadog-Website. Um Ihre Website zu identifizieren, überprüfen Sie die URL in Ihrem Browser, wenn Sie bei Datadog angemeldet sind, oder lesen Sie den Abschnitt Zugriff auf die Datadog-Website.
| Datadog-Website | Domäne der Website | URL des MCP-Endpunkts |
|---|---|---|
| US1 (Standard) | 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 |
| UNS 5 | 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 |
| AP1 | 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 |
Autorisierung
Vollständige OAuth-Autorisierung durch:
Autorisieren Sie sich als Ihr Benutzer auf der Datadog OAuth-Seite
Wenn Sie nicht angemeldet sind, wählen Sie Zulassen, melden Sie sich an und autorisieren Sie
Nach der Konfiguration ist Datadog in allen Agentenbereichen verfügbar.
Jede Registrierung stellt eine Verbindung zu einer Datadog-Organisation her. Um weitere Datadog-Organisationen zu verbinden, wiederholen Sie diesen Vorgang für jede einzelne und geben Sie jeder Registrierung einen eigenen Servernamen.
Schritt 2: Aktivieren
Aktivieren Sie die Option DataDog in einem bestimmten Agentenbereich und konfigurieren Sie den entsprechenden Geltungsbereich
Konfiguration
Wählen Sie auf der Seite Agentenbereiche einen Agentenbereich aus und klicken Sie auf Details anzeigen (falls Sie noch keinen Agentenbereich erstellt haben, siehe) Einen Agentenbereich erstellen
Wählen Sie den Tab „Funktionen“
Scrollen Sie nach unten zum Abschnitt Telemetrie
Drücken Sie Hinzufügen
Wählen Sie die Datadog-Registrierung aus, die Sie aktivieren möchten.
Next
Überprüfen Sie und klicken Sie auf Speichern
Kopieren Sie die Webhook-URL und den API-Schlüssel (werden beim Speichern einmal angezeigt; der API-Schlüssel kann später nicht mehr angezeigt werden — falls Sie ihn verlieren, regenerieren Sie ihn anhand der Webhook-Details auf der Registerkarte „Funktionen“, wodurch der vorherige Schlüssel ungültig wird)
Ein einzelner Agent Space kann mehr als eine Datadog-Registrierung verwenden. Um eine weitere Registrierung hinzuzufügen, wiederholen Sie diese Schritte.
Schritt 3: Webhooks konfigurieren
Mithilfe der Webhook-URL und des API-Schlüssels aus Schritt 2 können Sie Datadog so konfigurieren, dass Ereignisse gesendet werden, die eine Untersuchung auslösen, z. B. wenn ein Monitor eine Warnung auslöst.
Datadog-Webhooks verwenden die Bearer-Token-Authentifizierung. Das allgemeine Webhook-Anforderungsformat und das Nutzlastschema finden Sie unter. DevOps Agent über Webhook aufrufen Die folgenden Abschnitte enthalten eine gebrauchsfertige Datadog-Konfiguration. Sie müssen die Payload nicht selbst erstellen.
Schritt 3.1: Erstellen Sie den Webhook in Datadog
Öffnen Sie in Datadog Integrations, suchen Sie nach Webhooks und öffnen Sie die Integrationskachel. Weitere Informationen finden Sie unter Webhooks
in der Datadog-Dokumentation. Wählen Sie unter Webhooks die Option Neu aus.
Geben Sie unter Name einen Namen wie
devops-agentein. Sie verweisen auf diesen Namen wie@webhook-devops-agentin Monitormeldungen.Fügen Sie als URL die Webhook-URL aus Schritt 2 ein (diese ist auch im Datadog-Eintrag auf der Registerkarte „Funktionen“ Ihres Agentenbereichs sichtbar).
Ersetzen Sie für Payload die Standard-Payload durch die Vorlage in Schritt 3.2.
Lassen Sie die Authentifizierungsmethode unkonfiguriert und wählen Sie stattdessen Custom Headers aus und geben Sie den Header ein, der im folgenden Beispiel gezeigt wird, und
<API_KEY_FROM_STEP_2>ersetzen Sie ihn durch den API-Schlüssel aus Schritt 2.Lassen Sie Encode unverändert, wenn das Formular leer ist. Für den Webhook-Endpunkt ist ein unformatierter JSON-Text erforderlich. Bei der Formularkodierung schlägt die Verarbeitung der Nutzdaten fehl.
Speichern Sie den Webhook.
Benutzerdefinierter Header-Wert für Schritt 6:
{"Authorization": "Bearer <API_KEY_FROM_STEP_2>"}
Um zu vermeiden, dass der Schlüssel in der Normalansicht gespeichert wird, definieren Sie eine benutzerdefinierte Variable (z. B.$DEVOPS_AGENT_API_KEY) in der Webhook-Kachel, wobei die Option Aus Ansicht ausblenden ausgewählt ist, und verweisen Sie stattdessen im Header-Wert auf die Variable.
Schritt 3.2: Payload-Vorlage für vom Monitor ausgelöste Warnungen
Die folgende Vorlage eignet sich für Standard-Monitorwarnungen, einschließlich Metrik-, Log-, APM- und Synthetics-Monitoren. Datadog ersetzt die $VARIABLE Platzhalter, wenn es den Webhook sendet. Belassen Sie sie so, wie sie geschrieben sind.
{ "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" } }
Wie Datadog-Variablen dem Webhook-Schema zugeordnet werden
| Webhook-Feld | Zu verwendender Wert | Hinweise |
|---|---|---|
eventType |
Die literale Zeichenfolge incident |
Erforderliche Konstante. |
incidentId |
datadog-$ALERT_CYCLE_KEY |
$ALERT_CYCLE_KEYbleibt vom Zeitpunkt des Auslösens eines Monitors bis zur Auflösung unverändert, sodass erneute Benachrichtigungen in einer einzigen Untersuchung zusammengefasst werden. Verwenden Sie stattdessen $ID (die ID pro Ereignis) nur, wenn Sie möchten, dass jede Benachrichtigung eine separate Untersuchung einleitet. |
action |
Die literale Zeichenfolge created |
Ordnen Sie diesem Feld nicht $ALERT_TRANSITION zu. Seine Werte (wie Triggered undRecovered) sind keine gültigen action Werte. Steuern Sie stattdessen anhand der Monitormeldung, wann der Webhook ausgelöst wird (siehe Schritt 3.3). |
priority |
Eine der LiteralzeichenfolgenCRITICAL,, HIGHMEDIUM, oder LOW MINIMAL |
Nicht $ALERT_PRIORITY hier verwenden. Es wird um Datadog-Monitor-Prioritäten (P1—P5) erweitert, die keine gültigen Werte für dieses Feld sind. Der Webhook gibt eine Antwort von 200 zurück, aber es wird keine Untersuchung gestartet. Um verschiedene Prioritäten zu senden, erstellen Sie einen Webhook pro Prioritätsstufe (z. B. devops-agent-critical unddevops-agent-high) und verweisen Sie von jedem Monitor aus auf den entsprechenden Webhook. |
title |
$ALERT_TITLE |
Der Titel der Warnung des Monitors. |
description |
$TEXT_ONLY_MSG |
Der Veranstaltungstext ohne Markdown. Bevorzugen Sie diesen Text$EVENT_MSG, dessen Markdown-Formatierung für mehr Rauschen sorgt. |
service |
Ein wörtlicher Dienstname | Optional. Eine statische Zeichenfolge, die die Quelle identifiziert, z. B. datadog oder den Namen Ihres Dienstes. |
timestamp |
Auslassen | Optional. Die Datumsvariablen ($DATE,$DATE_POSIX) von Datadog sind Epochenwerte, nicht das ISO 8601-Format, das dieses Feld erwartet, also lassen Sie das Feld weg. |
data |
Datadog-Kontextvariablen | Optional, aber empfohlen. Alles, was darin enthalten data ist, wird als ursprüngliches Ereignis an den Agenten weitergegeben, sodass die Untersuchung die Monitorabfrage, den Umfang, die Tags und einen Link zurück zum Datadog-Ereignis erhält. |
Schritt 3.3: Verweisen Sie von Ihren Monitoren aus auf den Webhook
Fügen Sie in jedem Monitor, dessen Warnungen eine Untersuchung auslösen sollen, der Monitornachricht die Webhook-Erwähnung hinzu, wobei der Umfang so festgelegt ist, dass nur der Warnungsübergang ihn auslöst:
{{#is_alert}} @webhook-devops-agent {{/is_alert}}
Ohne die {{#is_alert}} Bedingungs-, Warn- und Wiederherstellungsbenachrichtigungen wird auch der Webhook gesendet. Bei Wiederherstellungsereignissen wird der Vorgang während der laufenden Untersuchung zwar dedupliziert$ALERT_CYCLE_KEY, aber bei Warnungen werden Untersuchungen nach Schwellenwerten eingeleitet, die Sie möglicherweise nicht untersuchen möchten.
Überprüfen Sie die Konfiguration
Senden Sie eine Testbenachrichtigung von einem Monitor (Testbenachrichtigungen im Monitor-Editor) und bestätigen Sie Folgendes:
Der Webhook gibt eine Antwort von 200 zurück. Sie können den Lieferstatus im Event-Stream der Datadog-Webhook-Integration sehen. Eine 4xx-Antwort bedeutet, dass der
AuthorizationHeader falsch ist. Re-check Geben Sie den API-Schlüssel ein und bestätigen Sie, dass die Option Als Formular kodieren deaktiviert ist.Eine Untersuchung beginnt in Ihrem Agentenbereich. (Die Untersuchung einer Testbenachrichtigung wird ohne die eigentliche Ursache abgeschlossen — das ist zu erwarten.) Wenn 200 Antworten ohne Untersuchung vorliegen, bedeutet dies, dass die Payload nach ihrer Annahme nicht validiert wurde. Prüfen Sie den Webhook-Antworttext im Datadog-Event-Stream: Eine ungültige Nutzlast gibt eine 200-Antwort zurück, deren Text die Validierungsfehler auflistet (z. B.
'P2' is not one of ['CRITICAL', 'HIGH', ...]), während eine gültige Payload zurückgegeben wird.{"message": "Webhook received"}Die häufigsten Ursachen sind ein nicht literalerpriorityWert (siehe vorherige Zuordnungstabelle) und ein DuplikatincidentIdaus einem früheren Test im selben Warnzyklus.
Informationen zur allgemeinen Fehlerbehebung bei Webhooks finden Sie unter. DevOps Agent über Webhook aufrufen
Erfahren Sie mehr: Datadog Remote MCP Server
Entfernung
Die Telemetriequelle ist auf zwei Ebenen miteinander verbunden: auf Ebene des Agentenbereichs und auf Kontoebene. Um sie vollständig zu entfernen, müssen Sie sie zunächst aus allen Agentenbereichen entfernen, in denen sie verwendet wird. Anschließend kann die Registrierung aufgehoben werden.
Schritt 1: Aus dem Agentenbereich entfernen
Wählen Sie auf der Seite „Agentenbereiche“ einen Agentenbereich aus und klicken Sie auf „Details anzeigen“
Wählen Sie den Tab „Funktionen“
Scrollen Sie nach unten zum Abschnitt Telemetrie
Wählen Sie Datadog
Drücken Sie auf Entfernen
Schritt 2: Vom Konto abmelden
Gehen Sie zur Seite Capability Providers (zugänglich über die Seitennavigation)
Scrollen Sie zum Abschnitt Aktuell registriert.
Vergewissern Sie sich, dass die Anzahl der Agentenplätze Null ist (wenn nicht, wiederholen Sie Schritt 1 oben in Ihren anderen Agentenbereichen)
Wählen Sie Datadog aus und wählen Sie dann im Menü „Aktionen“ die Option „Abmelden“.