1. Datadog의 기본 수집 방식 (Push)
Datadog은 호스트(또는 컨테이너)에 Datadog Agent를 설치하고,
이 Agent가 주기적으로 Datadog SaaS 백엔드로 데이터를 전송(push) 합니다.
흐름
[Application / OS / Container]
↓
Datadog Agent
↓ (HTTPS, outbound)
Datadog BackendAgent가 수집하는 것
• 시스템 메트릭 (CPU, Memory, Disk, Network)
• 애플리케이션 메트릭
• 로그 (선택)
• APM Trace
• 프로파일링 데이터
• 컨테이너 / Kubernetes 메타데이터
→ 모두 Agent가 주도적으로 전송합니다.
⸻
2. Prometheus와의 결정적 차이
항목 Datadog Prometheus
수집 주체 Agent Prometheus Server
모델 Push (Agent → Backend) Pull (Server → Target)
네트워크 Outbound 위주 Inbound 필요
SaaS 친화성 매우 높음 상대적으로 낮음
방화벽 구성 단순 복잡해질 수 있음
Datadog이 대규모 SaaS 환경, 기업망, 클라우드에서 많이 쓰이는 이유 중 하나가 Push 기반이라 네트워크 제약이 적기 때문입니다.
⸻
3. “그런데 Pull처럼 보이는 경우” (예외적 요소)
Datadog 내부에는 Pull 성격을 가진 구성 요소도 일부 존재합니다.
1) Prometheus Integration
• Datadog Agent가 Prometheus exporter endpoint를 scrape
• 이 경우:
• Prometheus Server → Pull ❌
• Datadog Agent → Pull (scrape) ⭕
즉, Datadog 전체 아키텍처는 Push지만,
Agent 내부에서 특정 타겟을 Pull하는 구조는 존재합니다.
⸻
2) OpenMetrics / StatsD
• 애플리케이션 → Agent 로 Push
• Agent → Datadog Backend 로 Push
여전히 전체 흐름은 Push 기반입니다.
⸻
4. 한 문장 요약
Datadog은 전체 시스템 관점에서는 명확한 Push 모델이며,
Agent 내부에서만 제한적으로 Pull(scrape)을 사용한다.
⸻
5. eBPF·Parca·Prometheus를 같이 보는 관점에서
지금처럼 eBPF, Parca, Prometheus, Datadog을 함께 비교하는 상황이라면
구조를 이렇게 이해하면 정확합니다.
• Prometheus: Pull-first, TSDB 중심
• Datadog: Agent-centric Push-first SaaS
• Parca: Pull + eBPF profiling (Prometheus 생태계 친화)