DataDog 연결

기본 제공, 단방향 통합

현재 AWS DevOps Agent는 기본 제공 단방향 통합을 통해 Datadog 사용자를 지원하므로 다음을 사용할 수 있습니다.

자동 조사 트리거링 - AWS DevOps 에이전트 웹후크를 통해 AWS DevOps 에이전트 인시던트 해결 조사를 트리거하도록 Datadog 이벤트를 구성할 수 있습니다.
원격 측정 내부 검사 - 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`

권한 부여

다음을 통해 OAuth 권한 부여 완료:

Datadog OAuth 페이지에서 사용자 권한 부여
로그인하지 않은 경우 허용, 로그인, 권한 부여를 차례로 선택합니다.

구성되면 모든 에이전트 스페이스에서 Datadog을 사용할 수 있게 됩니다.

2단계: 활성화

특정 에이전트 공간에서 DataDog를 활성화하고 적절한 범위 지정을 구성합니다.

구성

에이전트 공간 페이지에서 에이전트 공간을 선택하고 세부 정보 보기를 누릅니다(에이전트 공간을 아직 생성하지 않은 경우 참조에이전트 스페이스 생성).
기능 탭을 선택합니다.
아래로 스크롤하여 원격 측정 섹션으로 이동합니다.
추가를 누릅니다.
Datadog 선택
다음
검토 후 저장을 누릅니다.
Webhook URL 및 API 키 복사(저장 시 한 번 표시됨, API 키는 나중에 볼 수 없음 - 분실한 경우 이전 키를 무효화하는 기능 탭의 Webhook 세부 정보에서 다시 생성)

3단계: 웹후크 구성

2단계의 Webhook URL 및 API 키를 사용하여 모니터가 알림을 보내는 경우와 같이 조사를 트리거하는 이벤트를 보내도록 Datadog을 구성할 수 있습니다.

Datadog 웹후크는 보유자 토큰 인증을 사용합니다. 일반적인 웹후크 요청 형식 및 페이로드 스키마는 섹션을 참조하세요Webhook를 통해 DevOps 에이전트 호출. 다음 섹션에서는 ready-to-use 수 있는 Datadog 구성을 제공합니다. 페이로드를 직접 구성할 필요가 없습니다.

3.1단계: Datadog에서 웹후크 생성

Datadog에서 통합을 열고 Webhook를 검색한 다음 통합 타일을 엽니다. 자세한 내용은 Datadog 설명서의 Webhooks를 참조하세요.
Webhooks에서 새로 만들기를 선택합니다.
이름에와 같은 이름을 입력합니다devops-agent. 모니터 메시지@webhook-devops-agent에서이 이름을 참조합니다.
URL의 경우 2단계의 Webhook URL을 붙여 넣습니다(에이전트 공간의 기능 탭에 있는 Datadog 항목에서 다시 볼 수 있음).
페이로드의 경우 기본 페이로드를 3.2단계의 템플릿으로 바꿉니다.
인증 메서드를 구성되지 않은 상태로 두고 대신 사용자 지정 헤더를 선택하고 다음 예제에 표시된 헤더를 입력하여를 2단계의 API 키<API_KEY_FROM_STEP_2>로 바꿉니다.
인코딩을 양식이 지워진 상태로 둡니다. 웹후크 엔드포인트에는 원시 JSON 본문이 필요합니다. 양식 인코딩으로 인해 페이로드 처리가 실패합니다.
웹후크를 저장합니다.

6단계의 사용자 지정 헤더 값:


{"Authorization": "Bearer <API_KEY_FROM_STEP_2>"}

키를 일반 보기에 저장하지 않으려면 보기에서 숨기기가 선택된 Webhook 타일에서 사용자 지정 변수(예: $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 스키마에 매핑되는 방법

Webhook 필드	사용할 값	참고
`eventType`	리터럴 문자열 `incident`	필수 상수입니다.
`incidentId`	`datadog-$ALERT_CYCLE_KEY`	`$ALERT_CYCLE_KEY`는 모니터가 트리거될 때부터 해결될 때까지 동일하게 유지되므로 재알림은 단일 조사로 중복 제거됩니다. 모든 알림이 별도의 조사를 시작하도록 하려는 경우에만 `$ID` (이벤트당 ID)를 대신 사용합니다.
`action`	리터럴 문자열 `created`	`$ALERT_TRANSITION`이 필드에 매핑하지 마십시오. 해당 값(예: `Triggered` 및 `Recovered`)은 유효한 `action` 값이 아닙니다. 대신 모니터 메시지에서 웹후크가 실행되는 시기를 제어합니다(3.3단계 참조).
`priority`	리터럴 문자열 `CRITICAL`, `HIGH`, `MEDIUMLOW`, 또는 중 하나 `MINIMAL`	`$ALERT_PRIORITY` 여기에서를 사용하지 마십시오. 이 필드에 유효한 값이 아닌 Datadog 모니터 우선 순위(`P1`–`P5`)로 확장됩니다. 웹후크는 200개의 응답을 반환하지만 조사가 시작되지 않습니다. 다른 우선 순위를 보내려면 우선 순위 수준(예: `devops-agent-critical` 및 `devops-agent-high`)당 하나의 웹후크를 생성하고 각 모니터에서 적절한 웹후크를 참조합니다.
`title`	`$ALERT_TITLE`	모니터의 알림 제목입니다.
`description`	`$TEXT_ONLY_MSG`	마크다운이 있는 이벤트 텍스트가 제거되었습니다. 마크다운 형식 지정 시 노이즈가 추가`$EVENT_MSG`되는 대신 이를 선호합니다.
`service`	리터럴 서비스 이름	선택 사항. `datadog` 또는 서비스 이름과 같이 소스를 식별하는 정적 문자열입니다.
`timestamp`	생략	선택 사항. Datadog의 날짜 변수(`$DATE`, `$DATE_POSIX`)는이 필드에 필요한 ISO 8601 형식이 아닌 에포크 값이므로 필드를 생략합니다.
`data`	Datadog 컨텍스트 변수	선택 사항이지만 권장됩니다. 의 모든 것이 원래 이벤트로 에이전트에 전달`data`되어 조사를 통해 모니터 쿼리, 범위, 태그 및 Datadog 이벤트에 대한 링크를 다시 제공합니다.

3.3단계: 모니터에서 웹후크 참조

알림을 통해 조사를 트리거해야 하는 각 모니터에서 알림 전환만 실행되도록 범위가 지정된 Webhook 멘션을 모니터 메시지에 추가합니다.


{{#is_alert}}
@webhook-devops-agent
{{/is_alert}}

{{#is_alert}} 조건부 알림이 없으면 경고 및 복구 알림도 웹후크를 전송합니다. 복구 이벤트는를 통한 미해결 조사에 대해 중복 제거$ALERT_CYCLE_KEY되지만 경고는 조사를 원하지 않을 수 있는 임계값에 대한 조사를 시작합니다.

구성 확인

모니터에서 테스트 알림(모니터 편집기의 테스트 알림)을 보내고 다음을 확인합니다.

웹후크는 200 응답을 반환합니다. Datadog 웹후크 통합의 이벤트 스트림에서 전송 상태를 확인할 수 있습니다. 4xx 응답은 Authorization 헤더가 잘못되었음을 의미합니다. API 키를 다시 확인하고 양식으로 인코딩이 지워졌는지 확인합니다.
에이전트 스페이스에서 조사가 시작됩니다. (테스트 알림의 조사는 근본 원인 없이 종료됩니다. 이는 예상된 일입니다.) 조사가 없는 200 응답은 페이로드가 수락된 후 검증에 실패했음을 의미합니다. Datadog 이벤트 스트림에서 웹후크 응답 본문을 확인합니다. 잘못된 페이로드는 본문에 검증 오류(예: 'P2' is not one of ['CRITICAL', 'HIGH', ...])가 나열된 200 응답을 반환하고 유효한 페이로드는를 반환합니다{"message": "Webhook received"}. 가장 일반적인 원인은 리터럴이 아닌 priority 값(위의 매핑 표 참조)과 동일한 알림 주기의 incidentId 이전 테스트에서 중복된 값입니다.

일반적인 웹후크 문제 해결은 섹션을 참조하세요Webhook를 통해 DevOps 에이전트 호출.

자세히 알아보기: Datadog 원격 MCP 서버

제거

원격 측정 소스는 에이전트 공간 수준과 계정 수준에서 두 가지 수준으로 연결됩니다. 완전히 제거하려면 먼저 에이전트 공간이 사용되는 모든 에이전트 공간에서 제거한 다음 등록을 취소할 수 있습니다.

1단계: 에이전트 공간에서 제거

에이전트 스페이스 페이지에서 에이전트 스페이스를 선택하고 세부 정보 보기를 누릅니다.
기능 탭을 선택합니다.
아래로 스크롤하여 원격 측정 섹션으로 이동합니다.
Datadog 선택
제거를 누릅니다.

2단계: 계정에서 등록 취소

기능 공급자 페이지로 이동(측면 탐색에서 액세스 가능)
현재 등록된 섹션으로 스크롤합니다.
에이전트 공간 수가 0인지 확인합니다(다른 에이전트 공간에서 위의 1단계를 반복하지 않는 경우).
Datadog을 선택한 다음 작업 메뉴에서 등록 취소를 선택합니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

Dynatrace 연결

Grafana 연결