Files
llm-wiki/raw/company-tech-blogs/tracing-datadog-apm-vs-opentelemetry.md
T

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/
feature-distributed-tracing-contract
ca-skeleton-operational-contract
ca-distributed-tracing
datadog
opentelemetry
apm
vendor-comparison
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

핵심 인용 / 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-agent instrumentation 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-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 우위.