Datadog คืออะไร

ไอเดียหลักในหนึ่งประโยค

Datadog คือ SaaS backend เดียวที่ Agent ตัวเบา ๆ (หรือ pipeline OpenTelemetry — พิสูจน์ด้านล่าง ไม่ต้องใช้ SDK เฉพาะของ Datadog เลย) ป้อน tagged telemetry เข้าไป และทุก product ที่เห็นใน UI — Infrastructure Monitoring, Log Management, APM, RUM, Synthetics, Cloud Security, CI Visibility, Agent Observability — จริง ๆ แล้วคือมุมมองที่ต่างกันของ data stream เดียวกันนั้นเอง

หนึ่งแพลตฟอร์ม หลาย product

ทีมส่วนใหญ่เจอ Datadog ทีละ product — บางคนติดตั้ง Agent เพื่อเก็บ host metric บางคนเปิด APM บางคนเริ่มส่ง log เข้าไป ทำให้เข้าใจง่าย ๆ ว่านี่คือเครื่องมือแยกกันที่บังเอิญใช้ login เดียวกัน แต่จริง ๆ ไม่ใช่ ข้างใต้มีสิ่งเดียวที่ส่งเข้ามาที่ backend ของ Datadog นั่นคือ telemetry ที่มี tag ติดอยู่ metric, log, trace และ process snapshot คือ telemetry รูปแบบต่างกัน แต่ทั้งหมดใช้ tagging model เดียวกัน, organization เดียวกัน และ billing account เดียวกัน

backend เดียวนั้นคือสิ่งที่ขับเคลื่อน product ตระกูลเต็ม (ยืนยันจาก navigation index จริงของ docs.datadoghq.com เอง):

Infrastructure Monitoring — metric ของ host กับ container, Host Map, dashboard ระดับ resource
APM (Application Performance Monitoring) — distributed trace, service map, มุมมอง latency กับ error rate
Log Management — การเก็บ, pipeline ประมวลผล, การ index และการค้นหา log event
RUM (Real User Monitoring) — Browser RUM กับ Mobile RUM: event session/view/action/error จริงจาก browser/แอปจริง ไม่ใช่ synthetic check
Synthetic Monitoring — check แบบ scripted ที่ schedule ไว้ (API test, browser test) ที่ probe ระบบคุณคล้าย RUM แต่ตามตารางเวลาแทนที่จะรอ traffic จริง
Cloud Security — posture/misconfiguration scanning กับ runtime threat detection ปัจจุบันทำตลาดภายใต้ umbrella Cloud Security Management (CSM)
CI Visibility — observability ของ pipeline กับ test run สำหรับระบบ CI เชื่อม flaky test กับ build ที่ช้ากลับไปหา service เดียวกัน
Agent Observability — monitor, troubleshoot และ evaluate แอปที่ขับเคลื่อนด้วย LLM (chatbot, agent) ข้อเท็จจริงจาก docs จริงที่ควรพูดถึงตรง ๆ: docs.datadoghq.com/llm_observability/ คือ product ที่เดิม (และยังพบบ่อยในเนื้อหาเก่าและ training data ของ AI) เรียกว่า “LLM Observability” — ตัว product เองตอนนี้แสดงตัวเป็น Agent Observability ถ้าเจอ “LLM Observability” ใน prompt, docs snippet หรือโค้ดที่ generate มา ให้ถือว่าเป็น product เดียวกันที่เปลี่ยนชื่อ umbrella ไม่ใช่ product แยก
Monitors & SLOs — กฎ alert กับการติดตาม error budget ที่ประเมินจากข้อมูลด้านบนทั้งหมด
Software Catalog — ไดเรกทอรีของ service ที่ผูก ownership metadata กลับไปหา metric, log และ trace เดียวกัน

ไม่มีตัวไหนเป็นเครื่องมือแยกที่มี storage silo ของตัวเอง ทั้งหมดคือ view เหตุผลที่เรื่องนี้สำคัญในทางปฏิบัติ — เมื่อคุณปรับ tagging ให้ดีขึ้นครั้งเดียว (บทถัดไปของ module นี้ลงลึกเรื่องนี้) ทุก view เหล่านี้ดีขึ้นพร้อมกัน คุณไม่ได้ตั้งค่าแปด product แยกกัน คุณตั้งค่า data model เดียว

Agent กับ backend

Agent คือซอฟต์แวร์ชิ้นเล็ก ๆ ที่คุณรันอยู่ข้าง infrastructure ของคุณ — บน host, เป็น container หรือเป็น Kubernetes DaemonSet หน้าที่ของตัวเองแคบมาก คือเก็บข้อมูลในเครื่องแล้วส่งเข้า Datadog backend ผ่าน HTTPS ไม่ได้ render dashboard, ไม่ได้ประเมิน monitor และไม่ได้เก็บ history — ทั้งหมดนั้นอยู่ใน Datadog SaaS backend นั่นคือเหตุผลที่ Agent เองยังคงเบาและทิ้งแล้วสร้างใหม่ได้ง่าย Agent ก็ไม่ใช่ประตูหน้าเดียวด้วยซ้ำ — พิสูจน์ด้านล่าง Agent รับ telemetry ผ่าน protocol แบบ vendor-neutral อย่าง OTLP ได้ด้วย ไม่ใช่แค่ protocol ของตัวเอง

flowchart LR
    Host["Host / Container"] -->|metrics, checks| Agent
    App["Instrumented app (Datadog tracer)"] -->|traces| Agent
    OTelApp["Instrumented app (OpenTelemetry SDK)"] -->|OTLP grpc/http| Agent
    Files["Log files"] -->|logs| Agent
    Agent -->|HTTPS intake| Backend["Datadog Backend (one site)"]
    Backend --> Infra["Infrastructure Monitoring"]
    Backend --> Logs["Log Management"]
    Backend --> APM["APM"]
    Backend --> Mon["Monitors / SLOs"]
    Backend --> Cat["Software Catalog"]

telemetry มาจากไหน

OpenTelemetry กับ OTLP ingestion

ทุก section ก่อนหน้าอธิบายเส้นทาง Datadog-native: Agent ของ Datadog เอง, tracer library ของ Datadog เอง โค้ดที่ AI generate ส่วนใหญ่ขึ้นเรื่อย ๆ กลับ default ไปที่ OpenTelemetry SDK แทน (@opentelemetry/sdk-node, opentelemetry-instrument, OTEL_EXPORTER_OTLP_ENDPOINT) — vendor-neutral ไม่ใช่ของ Datadog โดยเฉพาะ Datadog support เส้นทางนี้จริง สองแบบ: Agent รับ OTLP ตรงได้ และ OpenTelemetry Collector แบบ standalone export เข้า Datadog ได้

Agent เป็น OTLP receiver — พิสูจน์ด้วย config จริง

เปิด otlp_config ใน datadog.yaml ทำให้ Agent เองกลายเป็น OTLP gRPC/HTTP receiver โดยไม่ต้องมี Collector แยก:

api_key: "<DD_API_KEY>"
site: "datadoghq.com"

otlp_config:
  receiver:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

mount เข้า datadog/agent:7 container จริง agent status ยืนยันว่ามันเปิดจริง ไม่ใช่แค่รับ YAML key ไว้เฉย ๆ:

$ docker exec dd-otlp agent status
...
  feature_otlp_enabled: true
...
====
OTLP
====

  Status: Enabled
  Collector status: Running

feature_otlp_enabled: true ใน section Metadata กับ block สถานะ OTLP เฉพาะ (Status: Enabled, Collector status: Running) คือการยืนยันสองแบบที่เป็นอิสระต่อกันจาก container จริงตัวเดียวกันว่า receiver ทำงานอยู่บน 4317/4318 พร้อมรับ OpenTelemetry SDK ไหนก็ได้ที่ชี้มาด้วย OTEL_EXPORTER_OTLP_ENDPOINT=http://<agent-host>:4318

Datadog Exporter ใน OpenTelemetry Collector

อีกเส้นทางที่ support ข้าม Agent ไปเลย: OpenTelemetry Collector (otel/opentelemetry-collector-contrib เวอร์ชันจริงที่ pull มา 0.161.0) ที่มี Datadog Exporter built-in ส่งตรงไปที่ intake ของ Datadog:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  datadog:
    api:
      key: "${env:DD_API_KEY}"
      site: datadoghq.com

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog]

validate จริงด้วย subcommand validate ของตัว Collector เอง (ไม่ใช่การเดา schema — คือ Go config loader จริงที่ Collector รันตอน startup):

$ docker run --rm -e DD_API_KEY=<fake> \
    -v "$PWD/collector.yaml":/etc/otelcol-contrib/config.yaml:ro \
    otel/opentelemetry-collector-contrib:latest \
    validate --config=/etc/otelcol-contrib/config.yaml
$ echo $?
0

field API key ของ Datadog exporter เป็นแบบ nested (api.key) ซึ่งเป็นรูปแบบที่ลืมง่ายมากถ้าจำเอาจากความจำ — key แบบแบน apikey: คือความผิดพลาดจริงที่พบบ่อย และคำสั่ง validate เดียวกันนี้ปฏิเสธมันทันที error จริง:

Error: exporters::datadog: api.key is not set

Semantic convention mapping

OpenTelemetry กับ Datadog ทั้งคู่ต้องการ triad service/env/version ในที่สุด แต่ไม่ได้เริ่มด้วยชื่อ attribute เดียวกัน ตาม docs.datadoghq.com/opentelemetry/schema_semantics/semantic_mapping/: service.name ของ OTel map ไปเป็น tag service ของ Datadog, service.version map ไปเป็น version และ deployment.environment.name map ไปเป็น env — ตัวหลังนี้ แทนที่ convention deployment.environment เก่าที่ deprecated ไปแล้วโดยเฉพาะ และต้องการ Datadog Agent 7.58.0+, Datadog Exporter v0.110.0+ หรือ direct OTLP intake ถึงจะ map ถูก นี่คือ trio service/env/version เดียวกับที่บทถัดไปลงลึกเรื่อง unified service tagging — section นี้ครอบแค่ว่า attribute ของแอปที่ instrument ด้วย OTel ลงเอยใน model เดียวกันนั้นยังไง ไม่ใช่เรื่อง tagging เต็มรูปแบบ

รายละเอียดภายในเต็ม ๆ — เส้นทาง OTLP ingest ข้างใน Agent, ความหมายของ exporter และตาราง semantic-convention เต็ม — อยู่ใน OTLP and Open Standards

Site กับ region

organization ของ Datadog ไม่ได้ลอยอยู่ทั่วอินเทอร์เน็ต — แต่อยู่ใน site เดียว (คำที่ Datadog ใช้เรียก region) เช่น US1, US3, US5, EU1 หรือ AP1 site ที่คุณอยู่คือตัวกำหนด hostname ที่ Agent กับ API call ของคุณต้องใช้ — เช่น org บน US1 คุยกับ api.datadoghq.com ส่วน org บน EU1 คุยกับ api.datadoghq.eu ถ้าตั้งค่า Agent ให้ชี้ไปที่ intake ของ site ผิด จะ authenticate กับ backend คนละตัวไปเลย — นี่คือความผิดพลาดวันแรกที่พบบ่อยที่สุด ควรเช็ค site ของตัวเองให้ชัดเจนแทนที่จะเดาเอา

# datadog.yaml (Agent main config) — site must match your org
api_key: "<DD_API_KEY>"
site: "datadoghq.eu"   # e.g. datadoghq.com (US1), datadoghq.eu (EU1), us3.datadoghq.com, ap1.datadoghq.com

API key เทียบกับ Application key

credential สองแบบนี้ถูกสับสนบ่อยมากเพราะทั้งคู่ก็แค่ string ที่เอาไปแปะที่ไหนสักที่ แต่อนุญาตให้ทำคนละอย่างกันโดยสิ้นเชิง

API key อนุญาตให้ ส่งข้อมูลเข้ามา — คือสิ่งที่ Agent ใส่ใน config เพื่อส่ง metric, log และ trace เข้า Datadog โดย key นี้ scope อยู่ที่ organization ไม่ได้ผูกกับคนใดคนหนึ่ง
Application key อนุญาตให้ ทำตัวเป็น user — key นี้ผูกกับ permission ของ user คนหนึ่งโดยเฉพาะ และใช้เรียก read/management API ของ Datadog (query metric, สร้าง dashboard, จัดการ monitor ผ่าน API หรือ Terraform) ถ้า user คนนั้นถูก deactivate หรือ permission ถูกถอด สิ่งที่ใช้ Application key ของเขาก็เสีย access นั้นไปด้วย

กฎง่าย ๆ — ถ้ากำลังตั้งค่าอะไรบางอย่างให้ ส่ง ข้อมูลเข้า Datadog ต้องใช้ API key ถ้ากำลังเขียน script หรือ Terraform provider ที่ต้อง อ่านหรือจัดการ resource ของ Datadog แทน user คนหนึ่ง ต้องใช้ Application key คู่กับ API key

# Typical pairing for a script that talks to Datadog's API
export DD_API_KEY="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
export DD_APP_KEY="yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
curl -X GET "https://api.datadoghq.com/api/v1/validate" \
  -H "DD-API-KEY: ${DD_API_KEY}" \
  -H "DD-APPLICATION-KEY: ${DD_APP_KEY}"

🐶 สรุปในบรรทัดเดียว

Datadog คือ backend เดียว, tagging model เดียว, product view หลายตัว — Infrastructure, APM, Logs, RUM, Synthetics, Cloud Security, CI Visibility และ Agent Observability (ชื่อปัจจุบันของสิ่งที่เคยเรียกว่า LLM Observability) ทั้งหมดอ่านจาก tagged telemetry stream เดียวกัน stream นั้นมาได้ผ่าน Agent/tracer ของ Datadog เอง หรือ ผ่าน OTLP แบบ vendor-neutral — พิสูจน์ด้านบน ทั้ง OTLP receiver ของ Agent เอง (otlp_config) และ Datadog Exporter ของ OpenTelemetry Collector แบบ standalone เป็นเส้นทาง ingestion จริง ปัจจุบัน support ทั้งคู่ API key คือตัวที่ให้ telemetry เข้ามาได้ และ Application key คือตัวที่ให้ script หรือ tool ของ user ที่ authenticate แล้วอ่านหรือจัดการ resource ของ Datadog ได้ทีหลัง

Reading AI-generated code

🐛 หา bug ในโค้ดนี้

# AI comment: "Send OTel Collector traces straight to Datadog"
receivers:
otlp:
  protocols:
    grpc:
      endpoint: 0.0.0.0:4317

exporters:
datadog:
  apikey: "${env:DD_API_KEY}"
  site: datadoghq.com

service:
pipelines:
  traces:
    receivers: [otlp]
    exporters: [datadog]

เฉลย

นี่คือ config ของ OpenTelemetry Collector ที่ดูสมเหตุสมผลมาก — receiver จริง, ชื่อ exporter จริง, pipeline ต่อกันถูก bug ที่พิสูจน์ด้วย Collector binary จริงเองผ่านคำสั่ง validate ด้านบน: field API key ของ Datadog exporter เป็น nested (api: { key: ... }) ไม่ใช่ key แบบแบนระดับบนสุด apikey: validate ปฏิเสธ config นี้เป๊ะ ๆ ด้วย Error: exporters::datadog: api.key is not set — Collector fail ตอน startup ไม่ใช่แบบเงียบ ๆ ตอน runtime ซึ่งเป็นข่าวดีอย่างเดียวตรงนี้ แต่ก็ยังแปลว่าไม่มี trace ไหนถึง Datadog เลยจนกว่าจะแก้ shape เป็น api.key

Mental Model

ลองนึกภาพ backend ของ Datadog เป็น คลังสินค้าเดียวที่มีสายพาน intake ที่มี tag เดียว ไม่ใช่แปดคลังแยกกัน ทุก product — Infrastructure, APM, Logs, RUM, Synthetics, Cloud Security, CI Visibility, Agent Observability — คือหน้าต่างที่มองเข้าไปในคลังเดียวกัน กรองด้วย telemetry ประเภทไหน (และ tag ไหน) ที่หน้าต่างนั้นสนใจ ตัวสายพานเองรับสินค้าได้สองรูปแบบท่าเรือ: รูปแบบของ Datadog เอง (Agent, tracer ของ Datadog) หรือรูปแบบ OTLP แบบ vendor-neutral (พิสูจน์ด้านบน ทั้งตรงเข้า Agent และผ่าน Collector) — ทั้งสองรูปแบบลงเอยบนสายพานเดียวกัน tag แบบเดียวกัน เห็นในหน้าต่างเดียวกัน

Trade-offs

Agent/tracer ของ Datadog เอง เทียบกับ OpenTelemetry SDK + OTLP — Datadog-native ได้ feature เฉพาะของ Datadog ก่อน (บาง integration, บาง UI feature ship ให้เส้นทาง native ก่อนที่เส้นทาง OTel จะตามทัน) และ default ที่ง่ายกว่าเล็กน้อย; OpenTelemetry ได้ vendor neutrality (สลับ backend ได้โดยไม่ต้อง instrument ใหม่) และเรื่อง instrumentation เดียวข้ามหลาย observability vendor แลกกับต้องพึ่ง semantic-convention mapping ที่พิสูจน์ด้านบนถึงจะลงเอยใน model service/env/version ของ Datadog ได้ถูก
OTLP ตรงเข้า Agent เทียบกับผ่าน Collector แบบ standalone — ส่ง OTLP ตรงเข้า Agent (พิสูจน์ด้านบน) มีชิ้นส่วนต้อง deploy/ดูแลน้อยกว่าหนึ่งชิ้น; Collector แบบ standalone เพิ่ม hop แต่รวมศูนย์การประมวลผล (sampling, filtering, fan-out ไปหลาย backend) ไว้นอก agent ของ vendor เดียว ซึ่งสำคัญเมื่อคุณส่ง telemetry เดียวกันไปมากกว่าหนึ่งที่
ชื่อ docs.datadoghq.com/llm_observability/ — ใช้ชื่อ URL/product family เดิม “LLM Observability” ใน docs ของตัวเองค้นหาง่ายกว่าและตรงกับเนื้อหาภายนอกที่มีมาหลายปี; ใช้ชื่อปัจจุบัน “Agent Observability” ตรงกับสิ่งที่ user เห็นจริงใน UI ของ Datadog วันนี้ ไม่มีอันไหนผิด แต่การผสมสองชื่อในเอกสารเดียวกันโดยไม่บอกว่าเป็น product เดียวกัน (แบบที่บทนี้บอกตรง ๆ) ทำให้สับสน

Common Misconceptions

“Datadog คือชุด product แยกกัน” ผิด — พิสูจน์ด้านบนโดย design: การเปลี่ยน tagging model (หรือเปิด product ใหม่) คือหน้าต่างบน backend เดียวกัน ไม่ใช่การ sync กันใหม่ระหว่างเครื่องมือแยก
“ต้องใช้ tracer/SDK ของ Datadog เองถึงจะส่งข้อมูลเข้า Datadog ได้” ผิด — พิสูจน์ด้านบนด้วย Agent จริง (feature_otlp_enabled: true, สถานะ OTLP Enabled/Running) และ config OTel Collector จริง (validate exit 0): instrumentation OpenTelemetry ธรรมดาก็เข้าถึง Datadog ได้ผ่านสองเส้นทางจริง current, support อยู่
“LLM Observability กับ Agent Observability เป็นสอง product คนละตัว” ผิด — ยืนยันตรงจาก docs.datadoghq.com/llm_observability/: URL นั้นตอนนี้แสดงตัวเป็น “Agent Observability” เนื้อหาเก่า (และ training data ของ AI จำนวนมาก) ยังเรียกสิ่งเดียวกันนี้ว่า “LLM Observability”
“API key กับ Application key ใช้แทนกันได้ หรือ key เดียวทำทั้งสองอย่าง” ผิด — พิสูจน์ด้วยจุดประสงค์ที่ต่างกันโดยสิ้นเชิงด้านบน: API key ให้แค่ telemetry เข้ามา; Application key อนุญาตให้ อ่าน/จัดการ resource ในฐานะ user คนหนึ่ง และใช้ key ผิดตัวสำหรับ call ของ Terraform/script จะ fail ทันที