翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
DataDog の接続
組み込みの 1 方向統合
現在、 AWS DevOps Agent は、組み込みの 1 方向統合で Datadog ユーザーをサポートし、以下を有効にします。
自動調査トリガー - Datadog イベントは、 AWS DevOps エージェントウェブフックを介して AWS DevOps エージェントインシデント解決調査をトリガーするように設定できます。
テレメトリイントロスペクション - AWS DevOps Agent は、各プロバイダーのリモート MCP サーバーを介して問題を調査する際に、Datadog テレメトリをイントロスペクションできます。
オンボーディング
ステップ 1: 接続する
アカウントアクセス認証情報を使用して Datadog リモート MCP エンドポイントへの接続を確立する
設定
機能プロバイダーページに移動する (サイドナビゲーションからアクセス可能)
テレメトリの「利用可能なプロバイダー」セクションで Datadog を検索し、登録を選択します
Datadog MCP サーバーの詳細を入力します。
サーバー名 - 一意の識別子 (例: my-datadog-server)
エンドポイント URL - Datadog MCP サーバーエンドポイント。エンドポイント URL は、Datadog サイトによって異なります。以下の Datadog サイトエンドポイント表を参照してください。
説明 - オプションのサーバーの説明
[次へ] を選択します。
レビューして送信
Datadog サイトエンドポイント
MCP エンドポイント URL は、Datadog サイトによって異なります。サイトを識別するには、Datadog にログインしたときにブラウザの URL を確認するか、「Datadog サイトへのアクセス
| Datadog サイト | サイトドメイン | MCP エンドポイント URL |
|---|---|---|
| US1 (デフォルト) | 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 |
| 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 |
Authorization
次の方法で OAuth 認可を完了します。
Datadog OAuth ページでユーザーとして を承認する
ログインしていない場合は、許可、ログイン、認可を選択します。
設定すると、Datadog はすべてのエージェントスペースで使用可能になります。
ステップ 2: を有効にする
特定のエージェントスペースで DataDog をアクティブ化し、適切なスコープを設定する
設定
エージェントスペースページからエージェントスペースを選択し、ビューの詳細を押します (エージェントスペースをまだ作成していない場合は、「」を参照してくださいエージェントスペースの作成)。
機能タブを選択する
Telemetry セクションまで下にスクロールします。
追加を押す
Datadog を選択する
次へ
確認して保存を押します
ウェブフック URL と API キーをコピーします (保存時に 1 回表示。API キーは後で表示できません。紛失した場合は、機能タブのウェブフックの詳細から再生成すると、前のキーが無効になります)。
ステップ 3: ウェブフックを設定する
ステップ 2 の Webhook URL と API キーを使用して、モニタリングアラート時など、調査をトリガーするイベントを送信するように Datadog を設定できます。
Datadog ウェブフックはベアラートークン認証を使用します。一般的なウェブフックリクエスト形式とペイロードスキーマについては、「」を参照してくださいWebhook による DevOps エージェントの呼び出し。以下のセクションでは、ready-to-use Datadog 設定について説明します。ペイロードを自分で構築する必要はありません。
ステップ 3.1: Datadog でウェブフックを作成する
Datadog で、統合を開き、ウェブフックを検索して、統合タイルを開きます。詳細については、Datadog ドキュメントの「Webhooks
」を参照してください。 Webhooks で、New を選択します。
Name には、 などの名前を入力します
devops-agent。この名前はモニターメッセージ@webhook-devops-agentで として参照します。URL の場合は、ステップ 2 の Webhook URL を貼り付けます (エージェントスペースの Capabilities タブの Datadog エントリから再度表示可能)。
ペイロードの場合、デフォルトのペイロードをステップ 3.2 の テンプレートに置き換えます。
認証メソッドを設定せずに、代わりにカスタムヘッダーを選択し、次の例に示すヘッダーを入力し、 をステップ 2 の API キー
<API_KEY_FROM_STEP_2>に置き換えます。エンコードはフォームをクリアのままにします。ウェブフックエンドポイントには raw JSON 本文が必要です。フォームエンコーディングにより、ペイロードの処理が失敗します。
ウェブフックを保存します。
ステップ 6 のカスタムヘッダー値:
{"Authorization": "Bearer <API_KEY_FROM_STEP_2>"}
キーをプレーンビューに保存しないようにするには、ビューから非表示を選択した状態でウェブフックタイルにカスタム変数 ( など$DEVOPS_AGENT_API_KEY) を定義し、代わりにヘッダー値で変数を参照します。
ステップ 3.2: モニターがトリガーするアラートのペイロードテンプレート
次のテンプレートは、メトリクス、ログ、APM、Synthetics モニターなどの標準モニターアラートで機能します。Datadog は、ウェブフックを送信するときに$VARIABLEプレースホルダーを置き換え、書き込みのままにします。
{ "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" } }
Datadog 変数がウェブフックスキーマにマッピングされる方法
| Webhook フィールド | 使用する値 | 注意事項 |
|---|---|---|
eventType |
リテラル文字列 incident |
必須の定数。 |
incidentId |
datadog-$ALERT_CYCLE_KEY |
$ALERT_CYCLE_KEY は、モニターがトリガーされてから解決されるまで同じままであるため、再通知は 1 つの調査に重複排除されます。すべての通知で個別の調査を開始する場合にのみ、代わりに $ID (イベントごとの ID) を使用します。 |
action |
リテラル文字列 created |
このフィールド$ALERT_TRANSITIONにはマッピングしないでください。その値 ( Triggeredや などRecovered) は有効なaction値ではありません。代わりにウェブフックがモニターメッセージから起動されるタイミングを制御します (ステップ 3.3 を参照)。 |
priority |
リテラル文字列の 1 つ CRITICAL、HIGH、MEDIUMLOW、、または MINIMAL |
ここでは を使用しないでください$ALERT_PRIORITY。このフィールドの有効な値ではない Datadog モニターの優先順位 (P1–P5) に拡張されます。ウェブフックは 200 レスポンスを返しますが、調査は開始されません。異なる優先順位を送信するには、優先順位レベルごとに 1 つのウェブフック ( devops-agent-criticalや などdevops-agent-high) を作成し、各モニターから適切なウェブフックを参照します。 |
title |
$ALERT_TITLE |
モニターのアラートタイトル。 |
description |
$TEXT_ONLY_MSG |
Markdown が削除されたイベントテキスト。Markdown 形式$EVENT_MSGがノイズを追加する よりもこれを優先します。 |
service |
リテラルサービス名 | オプション。datadog やサービスの名前など、ソースを識別する静的文字列。 |
timestamp |
省略 | オプション。Datadog の日付変数 ($DATE、$DATE_POSIX) はエポック値であり、このフィールドが想定する ISO 8601 形式ではないため、 フィールドは省略します。 |
data |
Datadog コンテキスト変数 | オプションですが、推奨します。のすべてが元のイベントとしてエージェントに渡dataされ、調査にモニタークエリ、スコープ、タグ、Datadog イベントへのリンクが渡されます。 |
ステップ 3.3: モニターからウェブフックを参照する
アラートが調査をトリガーする各モニターで、ウェブフックのメンションをモニターメッセージに追加します。これは、アラート移行のみがそれを起動するようにスコープされています。
{{#is_alert}} @webhook-devops-agent {{/is_alert}}
{{#is_alert}} 条件付き通知、警告通知、復旧通知がないと、ウェブフックも送信されます。復旧イベントは、 を通じてオープン調査と重複排除されますが$ALERT_CYCLE_KEY、警告は調査したくないしきい値の調査を開始します。
設定を確認する
モニターからテスト通知を送信し (モニターエディタのテスト通知)、以下を確認します。
ウェブフックは 200 レスポンスを返します。Datadog ウェブフック統合のイベントストリームで配信ステータスを確認できます。4xx レスポンスは、
Authorizationヘッダーが間違っていることを意味します。API キーを再確認し、フォームとしてのエンコードがクリアされていることを確認します。エージェントスペースで調査が開始されます。(テスト通知の調査は根本原因なしで終了します。これは予想されます) 調査を行わない 200 件のレスポンスは、ペイロードが受け入れられた後に検証に失敗したことを意味します。Datadog イベントストリームでウェブフックレスポンス本文を確認します。無効なペイロードは 200 レスポンスを返します。本文には検証エラー (例:
'P2' is not one of ['CRITICAL', 'HIGH', ...]) が一覧表示され、有効なペイロードは を返します{"message": "Webhook received"}。最も一般的な原因は、非リテラルpriority値 (前述のマッピング表を参照) と、同じアラートサイクル内の以前のテストincidentIdからの重複です。
一般的なウェブフックのトラブルシューティングについては、「」を参照してくださいWebhook による DevOps エージェントの呼び出し。
削除
テレメトリソースは、エージェントスペースレベルとアカウントレベルで 2 つのレベルで接続されます。これを完全に削除するには、まずそれを使用するすべてのエージェントスペースから削除してから、登録を解除する必要があります。
ステップ 1: エージェントスペースから削除する
エージェントスペースページからエージェントスペースを選択し、詳細の表示を押します。
機能タブを選択する
Telemetry セクションまで下にスクロールします。
Datadog を選択する
削除を押す
ステップ 2: アカウントから登録解除する
機能プロバイダーページに移動する (サイドナビゲーションからアクセス可能)
現在登録されているセクションまでスクロールします。
エージェントスペース数がゼロであることを確認します (他のエージェントスペースで上記のステップ 1 を繰り返しない場合)。
Datadog を選択し、アクションメニューから登録解除を選択します。