8.5 KiB
title, source_type, url, archive_url, related_branches, related_projects, tags, status, confidence, created, last_reviewed
| title | source_type | url | archive_url | related_branches | related_projects | tags | status | confidence | created | last_reviewed | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Datadog APM vs OpenTelemetry — Vendor APM 비교 | company-tech-blog | https://www.datadoghq.com/blog/opentelemetry-instrumentation/ |
|
|
|
raw | low | 2026-05-22 | 2026-05-27 |
Datadog APM vs OpenTelemetry — Vendor APM 비교
Layer:
raw/company-tech-blogs/— Datadog 공식 블로그 "Send OpenTelemetry data to Datadog" (2019) + Datadog Java tracer docs verbatim. 주의: 본 파일의 이전 버전에는 verbatim 으로 확인되지 않는 marketing 문구 4개가 포함되어 있었음 (예: "Datadog supports OpenTelemetry instrumentation in two ways: OTLP ingest via the Datadog Agent...", "auto-instruments 100+ frameworks out of the box", "AWS X-Ray uses its own propagation header (X-Amzn-Trace-Id)..."). 2026-05-27 재검증 결과 본문에서 verbatim 확인 안 됨 — 모두needs-confirmation으로 격하.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-distributed-tracing-contract | Micrometer Tracing + OpenTelemetry exporter 채택 결정의 vendor-neutrality 근거 (대안: Datadog dd-trace-java / AWS X-Ray) |
| raw/project-notes/ca-skeleton-operational-contract | Distributed Tracing Contract — OTel vs vendor-native APM 비교의 입력 자료 |
컨텍스트 / 왜 저장했는지
ca-tmpl이 채택한 "Micrometer Tracing + OpenTelemetry exporter"를 vendor APM (Datadog native tracer / AWS X-Ray)과 비교. vendor lock-in trade-off 명시.
출처 / Source
- 원본 URL: https://www.datadoghq.com/blog/opentelemetry-instrumentation/
- 보조 1: Datadog APM Java tracer docs — https://docs.datadoghq.com/tracing/trace_collection/dd_libraries/java/
- 보조 2: AWS X-Ray Java SDK docs (별도 확인 필요)
- 아카이브 URL: (미수집)
- 저자 / 조직: Datadog (2019-09 블로그)
- 발행일: 2019-09 (Datadog/OpenTelemetry 파트너십 발표 시점)
- 마지막 확인일: 2026-05-27
핵심 인용 / Key quotes (verbatim)
(Datadog 블로그 — datadoghq.com/blog/opentelemetry-instrumentation/, 2026-05-27 재검증 결과)
[§OpenTelemetry vendor-neutrality] "Because OpenTelemetry is vendor-neutral, companies will be able to migrate their observability data between monitoring backends more easily, without vendor lock-in."
[§Datadog 기여] "contributing our tracing libraries to the OpenTelemetry project"
(Datadog Java tracer docs — docs.datadoghq.com/tracing/trace_collection/dd_libraries/java/)
[§dd-trace-java 자동 계측] "Automatic instrumentation for Java uses the
java-agentinstrumentation capabilities provided by the JVM."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| DD-OTEL-C1 | OpenTelemetry 는 vendor-neutral 이며 이를 통해 모니터링 backend 간 observability 데이터 마이그레이션이 vendor lock-in 없이 더 쉬워짐 | [§OpenTelemetry vendor-neutrality] "Because OpenTelemetry is vendor-neutral, companies will be able to migrate their observability data between monitoring backends more easily, without vendor lock-in." | company-case-study |
Datadog 외 backend 로의 portability 가 결정 요인일 때 | OTel 가 vendor-native 기능 (Datadog Watchdog, Continuous Profiler) 를 모두 대체한다는 뜻은 아님 |
| DD-OTEL-C2 | Datadog 은 자사 tracing 라이브러리를 OpenTelemetry 프로젝트에 기여 (2019 시점) | [§Datadog 기여] "contributing our tracing libraries to the OpenTelemetry project" | company-case-study |
Datadog/OTel 호환성 history | 현재 2026 시점에서의 정확한 통합 상태 (OTLP ingest 경로 등) 는 본 인용으로 보장 안 됨 — 별도 docs 필요 |
| DD-OTEL-C3 | dd-trace-java 의 자동 계측은 JVM 의 java-agent 계측 기능을 사용 |
[§dd-trace-java 자동 계측] "Automatic instrumentation for Java uses the java-agent instrumentation capabilities provided by the JVM." |
official-vendor-doc |
Java 애플리케이션에 dd-trace-java 통합 시 | dd-trace-java 가 자동 계측하는 framework 의 개수 / 목록은 본 인용 범위 밖 (예: "100+ frameworks") |
| DD-OTEL-C4 | (부재) "Datadog supports OpenTelemetry instrumentation in two ways: OTLP ingest via the Datadog Agent, and direct OTLP HTTP/gRPC ingestion." — 본 자료의 2026-05-27 재검증에서 verbatim 미확인 | (부재 자체가 claim) | needs-confirmation |
Datadog 의 OTLP 수집 경로 (Agent vs direct) | 해당 사실이 거짓이라는 뜻은 아님. Datadog OTLP docs (별도) 에서 verbatim 재수집 필요 |
| DD-OTEL-C5 | (부재) "dd-trace-java auto-instruments 100+ frameworks out of the box" — verbatim 미확인 | (부재 자체가 claim) | needs-confirmation |
dd-trace-java 의 자동 계측 framework 개수 비교 | Datadog Compatibility Requirements 페이지 (별도) 의 확인 필요 |
| DD-OTEL-C6 | (부재) "AWS X-Ray uses its own propagation header (X-Amzn-Trace-Id) by default; W3C trace context support added in 2021" — verbatim 미확인 (Datadog 블로그가 아닌 AWS X-Ray docs 가 출처여야 함) |
(부재 자체가 claim) | needs-confirmation |
AWS X-Ray propagation 헤더 / W3C 호환 | AWS X-Ray Developer Guide 의 verbatim 확인 필요. 본 raw 파일로는 미보장 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
DD-OTEL-C1: OpenTelemetry 의 vendor-neutrality 주장 (Datadog 블로그의 marketing 문구)DD-OTEL-C2: Datadog 의 OTel 프로젝트 기여 (2019 시점)DD-OTEL-C3: dd-trace-java 가 java-agent 기반이라는 vendor docs 사실
- 이 자료가 증명하지 않는 것:
DD-OTEL-C4,C5,C6: 이전 raw 파일에 기록된 marketing/spec 문구의 정확한 verbatim- Datadog APM 의 모든 기능 (Watchdog, Continuous Profiler, Live Search) 의 정확한 동작
- AWS X-Ray 의 정확한 propagation 헤더 / W3C 호환 시점
- OTel SDK + Datadog 조합의 실제 production 운영 사례
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- Datadog OTLP ingest 경로 (Agent vs direct) 의 최신 docs 확인 → 별도 raw 파일 생성 권고
- AWS X-Ray Developer Guide 에서 propagation 헤더 verbatim 수집 → 별도 raw 파일 생성 권고
- Micrometer Tracing 1.x + OTel exporter + Datadog Agent 의 실측 latency / 호환성 검증
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석. 주의: 아래 메모는 verbatim 출처가 없는 사실을 포함할 수 있음 → wiki 로 옮길 때 verbatim 재수집 필요.
-
3가지 선택지 비교 (사실 자체는 별도 출처 확인 필요):
옵션 propagation exporter vendor lock-in OTel SDK (ca-tmpl 채택) W3C traceparent OTLP → any backend 없음 Datadog dd-trace-java W3C 또는 Datadog header dd agent → Datadog only 있음 AWS X-Ray X-Amzn-Trace-Id(W3C 옵션)X-Ray daemon → AWS only 있음 -
장점 (ca-tmpl OTel SDK 채택):
- vendor-neutral → backend swap 가능 (
DD-OTEL-C1으로 지지됨). - Spring Boot 3 + Micrometer Tracing 통합 자연스러움.
- W3C trace context default 와 정합.
- vendor-neutral → backend swap 가능 (
-
단점 (vendor-native 대비):
- vendor-specific feature (Datadog Watchdog, X-Ray service map auto-discovery) 사용 어려움.
- vendor auto-instrumentation 이 더 광범위한 경우 있음.
-
ca-tmpl 과의 차이: 명시적으로 "특정 APM vendor 종속 설정" 을 out-of-scope 로 둠 → OTel 선택은 결정과 정합.
-
운영 복잡도: OTel + collector 추가 deploy 필요. vendor native 는 agent 설치만으로 시작 가능 → 초기 적용 비용은 vendor native 가 낮으나 장기 portability 는 OTel 우위.
Related / 관련
- 같은 주제 다른 raw:
- (예정)
raw/official-docs/aws-x-ray-propagation— X-Ray 헤더 verbatim 확인 - (예정)
raw/company-tech-blogs/datadog-otlp-ingest-options— Datadog OTLP 경로 verbatim 확인
- (예정)
- 인용하는 branch:
- 인용하는 project:
- raw/project-notes/ca-skeleton-operational-contract (Distributed Tracing Contract)
- 인용한 wiki 요약: (미작성)