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, 1-Wege-Integration
Derzeit unterstützt AWS DevOps Agent Datadog-Benutzer mit einer integrierten 1-Wege-Integration, die Folgendes ermöglicht:
Automatisierte Auslösung von Ermittlungen — Datadog-Ereignisse können so konfiguriert werden, dass sie Untersuchungen zur Behebung von AWS DevOps Agentenvorfällen über Agent-Webhooks 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.
Onboarding
Schritt 1: Connect
Stellen Sie mit den Zugangsdaten für Ihr Konto eine Verbindung zu Ihrem DataDog-Remote-MCP-Endpunkt her
Konfiguration
Gehen Sie zur Seite Capability Providers (zugänglich über die Seitennavigation)
Suchen Sie Datadog im Bereich Verfügbare Anbieter unter Telemetrie und wählen Sie Registrieren
Geben Sie Ihre Datadog MCP-Serverdetails ein:
Servername — Eindeutiger Bezeichner (z. B. my-datadog-server)
Endpunkt-URL — Ihr Datadog MCP-Serverendpunkt. Die Endpunkt-URL variiert je nach Ihrer Datadog-Site. Die Endpunkttabelle der Datadog-Site finden Sie unten.
Beschreibung — Optionale Serverbeschreibung
Wählen Sie Weiter
Überprüfen und Einreichen
Endpunkte der Datadog-Site
Die MCP-Endpunkt-URL variiert je nach Ihrer Datadog-Site. Um Ihre Site zu identifizieren, überprüfen Sie die URL in Ihrem Browser, wenn Sie bei Datadog angemeldet sind, oder lesen Sie auf die Datadog-Website zugreifen.
| Datadog-Seite | Domäne der Website | MCP-Endpunkt-URL |
|---|---|---|
| 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 |
| 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 |
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, Anmelden und dann Autorisieren
Nach der Konfiguration ist Datadog in allen Agentenbereichen verfügbar.
Schritt 2: Aktivieren
Aktivieren Sie es DataDog in einem bestimmten Agentbereich 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 die Registerkarte Funktionen
Scrollen Sie nach unten zum Abschnitt Telemetrie
Drücken Sie auf Hinzufügen
Wählen Sie Datadog
Next
Überprüfe und drücke 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. Wenn Sie ihn verlieren, generieren Sie ihn anhand der Webhook-Details auf der Registerkarte Funktionen neu, wodurch der vorherige Schlüssel ungültig wird)
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 Payload-Schema finden Sie unter. DevOps Agent über Webhook aufrufen Die folgenden Abschnitte bieten eine sofort einsatzbereite 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 für Name einen Namen ein, z. B.
devops-agentSie verweisen auf diesen Namen wie@webhook-devops-agentin Monitornachrichten.Fügen Sie als URL die Webhook-URL aus Schritt 2 ein (auch hier sichtbar im Datadog-Eintrag auf der Registerkarte Funktionen Ihres Agentenbereichs).
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 Benutzerdefinierte Header aus und geben Sie den im folgenden Beispiel gezeigten Header ein.
<API_KEY_FROM_STEP_2>Ersetzen Sie ihn durch den API-Schlüssel aus Schritt 2.Lassen Sie Encode as form leer. Der Webhook-Endpunkt benötigt einen rohen JSON-Hauptteil. Die Formularkodierung führt dazu, dass die Payload nicht verarbeitet werden kann.
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 einfachen Ansicht gespeichert wird, definieren Sie eine benutzerdefinierte Variable (z. B.$DEVOPS_AGENT_API_KEY) in der Webhook-Kachel, wobei die Option Vor 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 Warnmeldungen
Die folgende Vorlage funktioniert für Standardmonitorwarnungen, einschließlich Metrik-, Protokoll-, APM- und Synthetics-Monitoren. Datadog ersetzt die $VARIABLE Platzhalter, wenn es den Webhook sendet. Lassen Sie sie unverändert.
{ "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 wörtliche Zeichenfolge incident |
Erforderliche Konstante. |
incidentId |
datadog-$ALERT_CYCLE_KEY |
$ALERT_CYCLE_KEYbleibt vom Zeitpunkt der Auslösung eines Monitors bis zur Auflösung unverändert, sodass erneute Benachrichtigungen zu einer einzigen Untersuchung dedupliziert werden. Verwenden Sie stattdessen $ID (die ID pro Ereignis) nur, wenn Sie möchten, dass jede Benachrichtigung eine separate Untersuchung einleitet. |
action |
Die wörtliche Zeichenfolge created |
Ordnen Sie dieses Feld nicht $ALERT_TRANSITION zu. Seine Werte (wie Triggered undRecovered) sind keine gültigen action Werte. Steuern Sie stattdessen von der Monitornachricht aus, wann der Webhook ausgelöst wird (siehe Schritt 3.3). |
priority |
Eine der literalen ZeichenkettenCRITICAL,, HIGHMEDIUM, oder LOW MINIMAL |
Verwenden Sie es $ALERT_PRIORITY hier nicht. Es erweitert sich auf Datadog Monitorprioritäten (P1—P5), 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 unterschiedliche Prioritäten zu senden, erstellen Sie einen Webhook pro Prioritätsstufe (z. B. devops-agent-critical unddevops-agent-high) und verweisen Sie auf jedem Monitor auf den entsprechenden Webhook. |
title |
$ALERT_TITLE |
Der Titel der Warnung des Monitors. |
description |
$TEXT_ONLY_MSG |
Der Ereignistext, bei dem Markdown entfernt wurde. Ziehen Sie diesen Text vor$EVENT_MSG, dessen Markdown-Formatierung Rauschen verursacht. |
service |
Ein wörtlicher Dienstname | Optional. Eine statische Zeichenfolge, die die Quelle identifiziert, z. datadog B. 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. Lassen Sie das Feld also weg. |
data |
Datadog-Kontextvariablen | Optional, aber empfohlen. Alle Eingaben data werden als ursprüngliches Ereignis an den Agenten übergeben, 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 Alerts eine Untersuchung auslösen sollen, der Monitornachricht die Webhook-Erwähnung hinzu, und zwar so, dass sie nur durch den Warnungsübergang ausgelöst wird:
{{#is_alert}} @webhook-devops-agent {{/is_alert}}
Ohne die {{#is_alert}} Bedingung wird der Webhook auch mit Warn- und Wiederherstellungsbenachrichtigungen gesendet. Wiederherstellungsereignisse werden anhand der laufenden Untersuchung dedupliziert$ALERT_CYCLE_KEY, aber mit Warnungen werden Untersuchungen für Schwellenwerte gestartet, die Sie möglicherweise nicht untersuchen möchten.
Überprüfen Sie die Konfiguration
Senden Sie eine Testbenachrichtigung von einem Monitor aus (Testbenachrichtigungen im Monitoreditor) und bestätigen Sie Folgendes:
Der Webhook gibt eine Antwort von 200 zurück. Sie können den Lieferstatus im Eventstream der Datadog-Webhook-Integration sehen. Eine 4xx-Antwort bedeutet, dass der
AuthorizationHeader falsch ist. Re-check geben Sie den API-Schlüssel ein und vergewissern Sie sich, dass die Option Als Formular codieren gelöscht ist.Eine Untersuchung beginnt in Ihrem Agentenbereich. (Die Untersuchung einer Testbenachrichtigung wird ohne Grundursachen abgeschlossen — das ist zu erwarten.) Eine Antwort von 200 ohne Untersuchung bedeutet, dass die Payload nicht validiert wurde, nachdem sie akzeptiert wurde. Prüfen Sie den Webhook-Antworttext im Datadog-Eventstream: Eine ungültige Payload gibt eine 200-Antwort zurück, deren Hauptteil die Validierungsfehler auflistet (zum Beispiel
'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 gleichen Alert-Zyklus.
Informationen zur allgemeinen Problembehandlung bei Webhooks finden Sie unter. DevOps Agent über Webhook aufrufen
Erfahren Sie mehr: Datadog
Entfernung
Die Telemetriequelle ist auf zwei Ebenen miteinander verbunden, auf der Ebene des Agentenbereichs und auf der 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 Agentbereich aus und klicken Sie auf „Details anzeigen“
Wählen Sie die Registerkarte 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 (falls nicht, wiederholen Sie Schritt 1 oben in Ihren anderen Agentenbereichen)
Wählen Sie Datadog und anschließend im Aktionsmenü die Option Abmelden aus.