Datadog ทำงานอย่างไรข้างใน

โมดูลนี้มีไว้ทำไม

โมดูลก่อนหน้าสอนให้คุณ ตั้งค่า Datadog: ติดตั้ง Agent, ส่ง custom metric, เพิ่ม sampling rule, เขียน log pipeline ทุกเรื่องมีจังหวะที่มันทำอย่างอื่นเงียบ ๆ ต่างจากที่ config ดูเหมือนบอก — dd_url ที่ย้าย writer แค่หนึ่งในสี่ตัว, histogram ที่ p99 เอามาเฉลี่ยไม่ได้, max_traces_per_second: 0 ที่ไม่ส่งอะไรเลย, status remapper ที่เปลี่ยน SEVERE เป็น OK, config ของ OTLP ที่ configcheck ยอมรับทั้งที่ receiver ตายแล้ว โมดูลนี้เปิดกล่องห้าระบบย่อย และพิสูจน์แต่ละกลไกจากภายนอกด้วยเครื่องมือจริง เพื่อว่าเมื่อคุณรีวิว config ที่คน (หรือ AI) เขียน จะบอกได้ว่าปุ่มไหนจริงและทำงานที่ไหน

1. Agent คืออะไรในทางกายภาพ และ byte ไปไหน? (Agent Architecture — process tree ที่ถูก supervise, ตารางเวลาของ check scheduler, aggregator กับ retry queue ของ forwarder, agent status ทีละ section)
2. custom metric ถูก aggregate ที่ไหน และทำไมเฉลี่ย percentile ไม่ได้? (DogStatsD and Aggregation — ชั้น client, Agent และ backend, payload series และ sketches ที่ถอดรหัสแล้ว, การ merge DDSketch)
3. ด่านไหนทิ้ง trace ของฉัน? (The Trace Sampling Pipeline — head sampler, rate limiter, feedback rate_by_service ของ Agent กับตัวบังคับไม่กี่ตัว, ingestion controls, retention)
4. log pipeline ทำอะไรกับบรรทัด log จริง ๆ และตามลำดับไหน? (Log Pipeline Processors — rule ฝั่ง Agent รันจริง, semantic ของ Grok และ remapper จาก docs, การ validate model แบบเข้มงวดของ pipeline JSON)
5. OpenTelemetry data กลายเป็น Datadog data ได้อย่างไร? (OTLP and Open Standards — receiver ของ Agent, semantic mapping ที่วัดได้, เส้นทาง Collector ที่ validate ด้วย otelcol-contrib จริง)

flowchart TD
  A["Agent Architecture: scheduler, aggregator, forwarder"] --> D["DogStatsD and Aggregation: what the aggregator flushes"]
  A --> T["Trace Sampling Pipeline: the Agent's samplers and feedback"]
  A --> L["Log Pipeline Processors: Agent-side rules, then backend"]
  A --> O["OTLP and Open Standards: the Agent as receiver"]
  D --> O
  T --> O

ห้าบทเรียนและความเชื่อมโยง

พิสูจน์ทุกอย่างในโมดูลนี้อย่างไร

• Agent จริง datadog/agent:7 resolve เป็น Agent 7.83.3 (Go 1.26.7) เริ่มด้วย key ปลอมและเปลี่ยนทุก intake ไปที่ port ในเครื่องที่ไม่มีใครฟัง หรือ fake intake ในเครื่องที่ decompress และเก็บทุก request เพื่อไม่ให้อะไรถูกส่งไป Datadog Agent run ช่วงแรกสองครั้งของผมติดต่อ intake จริงของ Datadog ด้วย key ปลอม (process endpoint และอีกครั้งคือ intake ของ database-monitoring event) ทั้งสองตอบ 403; run เหล่านั้นถูกระบุในบทเรียน และ output ที่แสดงมาจาก run ที่แยกขาดในภายหลัง
• payload ที่ถอดรหัส body ของ series, sketch และ trace ที่ Agent flush เป็น protobuf wire decoder ขนาดเล็กที่เขียนมือโดยใช้หมายเลข field ของ agent_payload.proto สาธารณะของ Datadog แปลงเป็นค่าที่แสดง
• Tracer dd-trace 6.17.0 (tools/probe/node) และ ddtrace 4.15.2 (tools/probe/venv) จาก harness ของคอร์ส พร้อม fake trace-agent ในเครื่องที่พิมพ์ tag ด้าน sampling ของ root span แต่ละตัวและตอบ rate_by_service ที่เลือกได้
• Model datadog-api-client 2.61.0 สำหรับ pipeline JSON บวกการตรวจแบบเข้มงวดต่อ processor ที่เขียนสำหรับบท log
• Collector image otel/opentelemetry-collector-contrib ที่มีอยู่ในเครื่อง, otelcol-contrib 0.161.0 ด้วย --network none
• Docs สิ่งที่มีอยู่เฉพาะใน backend ที่ Datadog host (Grok, remapper, ingestion controls, retention filters, intelligent retention) อ้างจาก docs.datadoghq.com พร้อม URL ดึงเมื่อ 2026-09-30 ไม่มี runtime ในเครื่องสำหรับสิ่งเหล่านั้น และบทเรียนไม่แกล้งสร้างขึ้นมา
• เวลาและตัวเลข มาจาก Mac เครื่องเดียว (Docker Desktop, linuxkit VM) รันครั้งเดียวต่อกรณี เป็นหลักฐานของกลไก ไม่ใช่ benchmark

🐶 สิ่งหนึ่งที่โมดูลนี้พิสูจน์ซ้ำ ๆ

agent configcheck ตรวจ check มัน exit 0 กับ datadog.yaml ที่ OTLP receiver ตายแล้ว และไม่พูดอะไรเรื่อง dd_url, sampling หรือ pipeline เมื่อบทเรียนบอกว่า config “validate ผ่าน” จะระบุว่าเครื่องมือไหนรัน และเครื่องมือนั้นเห็นและไม่เห็นอะไร

ลำดับการอ่านและแต่ละบทสมมติว่ารู้อะไรมาก่อน

บทเรียน	ต่อยอดจาก (Phase 3)	ตอบคำถาม
Agent Architecture	The Datadog Agent and Integrations	อะไรรันอยู่, scheduler ทำอะไร, forwarder ทำอะไรเมื่อ intake ล่ม?
DogStatsD and Aggregation	Custom Metrics with DogStatsD	อะไรออกจาก client, Agent flush อะไร และทำไม DISTRIBUTION ใช้ sketch
The Trace Sampling Pipeline	Ingestion Sampling vs. Retention Filters, Trace Metrics and DDSketch	ด่านไหนตัดสิน, แต่ละด่านทิ้ง tag อะไร, ด่านไหนบังคับจริง
Log Pipeline Processors	Log Collection and Processing Pipelines	อะไรรันที่ไหน, ตัวซ้ำตัวไหนชนะ, model JSON จับอะไรไม่ได้
OTLP and Open Standards	What Is Datadog	Agent และ Collector ทำอะไรกับข้อมูล OTLP

Mental Model

ทุกบทเรียนใช้ไอเดียเดียวกับระบบย่อยที่ต่างกัน: Datadog คือชุด pipeline เล็ก ๆ ที่มี stage คงที่ และแต่ละ stage ทิ้งหลักฐานที่คุณอ่านได้ stage ของ Agent ปรากฏเป็น section ของ agent status; การ aggregate ของ metric ปรากฏเป็น interval: 10 และ type: rate ใน payload; การตัดสินใจ sampling ปรากฏเป็น _sampling_priority_v1, _dd.p.dm และ _dd.limit_psr บน span; rule ฝั่ง Agent ของ log ปรากฏใน analyze-logs; การแปล OTLP ปรากฏเป็น http.method และ type=web ตรงที่ backend ที่ host ให้ซ่อนหลักฐานไว้ docs เป็นแหล่งเดียว และบทเรียนบอกไว้เช่นนั้น