วิธีอ่าน config Datadog ที่คุณไม่ได้เขียน

ทุกโมดูลก่อนหน้าสอนให้คุณ เขียน Datadog: Agent configuration, tracer setup, custom metrics, logs, monitors, SLOs, Terraform โมดูลนี้คือครึ่งที่เหลือ — การอ่าน conf.d/*.yaml, การเรียก tracer.init({...}), datadog_monitor ใน Terraform หรือ query ของ burn-rate ที่คนอื่น หรืออย่างอื่น เขียนไว้ แล้วตัดสินว่าถูกหรือไม่ AI assistant ส่ง config ที่หน้าตาเหมือน documentation เป๊ะให้คุณ และความสำเร็จนั้นคือกับดัก: YAML parse ผ่าน, JavaScript รัน, terraform validate ไม่พูดอะไร และ dashboard ตัวอย่างก็มีข้อมูล — ขณะที่ tracer เมิน option ที่คุณสะกดว่า log_injection เงียบ ๆ, check ไม่เคย load เพราะ tags: เป็น string และ alert แบบ burn-rate ขาด window ที่ required

มีสามเรื่องที่ทำให้ Datadog แย่กว่าเครื่องมือส่วนใหญ่ ข้อแรก พื้นผิว กว้างและ validate หลวม: JavaScript object รับทุก key, ไฟล์ conf.d ถูก parse สองขั้น (loader ของ Agent แล้วจึง model ของ check เอง), query ของ monitor เป็น string ทึบสำหรับทุก client library ข้อสอง ข้อมูลฝึก เก่าและปนกัน: Agent อยู่สาย 7.83 ขณะที่ tutorial แสดง format annotation เก่า, API tracer.configure(hostname=…) ของ Python จาก major ก่อน และชื่อ option จาก tracer ตัวหนึ่งที่ถูกแปะใส่อีกตัว ข้อสาม วิธีแก้ที่ assistant หยิบมาเร็วที่สุดคือสิ่งที่มันเห็นล่าสุด — และบางครั้ง “วิธีแก้” นั้นแก้ปัญหาที่ไม่มีอยู่จริง แคตตาล็อกของโมดูลนี้มีสัญญาณเตือนเท็จสองอัน (“ไม่มี init_config” และ DD_TRACE_SAMPLE_RATE ที่ “deprecated”) โดยตัวหลังจริง ๆ แล้ว Node ทำตามและ Python เมินเงียบ ๆ ทั้งคู่จึงต่างจากความเชื่อเมื่อรันดู

ทุก claim ในสี่บทเรียนนี้ที่รันได้ ถูกรันแล้ว — กับ Agent 7.83.3 (datadog/agent:7), dd-trace 6.17.0, ddtrace 4.15.2, @datadog/browser-rum 7.15.0, datadog-api-client 2.61.0 และ datadog Terraform provider 4.22.0 — ด้วย API key ปลอมและไม่มีอะไรถูกส่งไป Datadog เลย ที่ที่มีแต่ Datadog API หรือ docs ที่ตัดสินได้ บทเรียนบอกตรง ๆ และอ้าง URL ของ docs

flowchart TD
  A["1. Versions and pins<br/>which Agent, tracer, provider? floating tags?"] --> B["2. Agent config<br/>conf.d shape, check name, list vs scalar, DD_SITE"]
  B --> C["3. Kubernetes wiring<br/>Autodiscovery on the Pod template, container name, v2 format"]
  C --> D["4. Tracer options<br/>real option names, init order, env case"]
  D --> E["5. Custom metrics<br/>histogram vs distribution, bounded tags"]
  E --> F["6. Terraform and monitor JSON<br/>provider schema, recovery, burn-rate grammar, enums"]
  F --> G["7. Prove it<br/>configcheck, status, config dump, validate, models, harness"]

ลำดับการอ่าน config Datadog ที่คุณไม่ได้เขียน

1. Versions และ pin

ตรวจว่าโค้ดสมมติเวอร์ชันไหนก่อนตัดสินอย่างอื่น image ของ Agent เป็น latest หรือ major ที่ลอยแทน tag เต็มหรือ digest หรือไม่ Terraform provider ไม่ได้ pin หรือ pin ไว้ที่เวอร์ชันที่ไม่มี resource หรือไม่ คำกล่าวอย่าง “X deprecated” มาจากหน้า docs หรือจากความจำ ต้นทุนจริงคือ reproducibility: ในวันที่จับข้อมูลโมดูลนี้ tag 7, 7.83.3 และ latest เป็น image เดียวกัน ซึ่งเป็นเหตุผลที่ไม่มีใครสังเกต ดู catalog entry 7 และ 13

2. Agent configuration

directory conf.d/<name>.d/ ใช้ชื่อของ check (redisdb ไม่ใช่ redis) หรือไม่ instances: เป็น list หรือไม่ tags: และ key ชนิด list อื่นทุกตัวเป็น YAML list หรือไม่ DD_SITE เป็น domain ไม่ใช่ URL หรือไม่ จุดหลอก: agent configcheck พิมพ์ tags แบบ scalar, ชื่อ check ที่ผิด และค่าที่ผิด type โดยไม่มี error และคืน 0 แม้ตอนที่รายงาน error — ความจริงอยู่ใน agent status ดู entry 1–6

3. Kubernetes wiring

Autodiscovery annotation อยู่บน Pod template (spec.template.metadata) ใช้ ชื่อ container ในรูป .checks ที่รวมแล้ว (Agent 7.36+) หรือไม่ DD_ENV/DD_SERVICE/DD_VERSION มาจากแหล่งตัวพิมพ์เล็กแหล่งเดียวหรือไม่ ขั้นนี้พึ่ง docs มากกว่าการรันในเครื่อง — kubectl ยอมรับทุกตำแหน่งที่ผิด ดู entry 8 และ 12

4. Tracer option

ทุก key ใน tracer.init({...}) มีอยู่ใน TracerOptions หรือไม่ tracer ถูก initialise ก่อน library ที่ต้อง instrument หรือไม่ ไฟล์ Python อ่าน attribute ที่มีอยู่และเรียก tracer.configure ด้วย keyword ที่มีอยู่หรือไม่ JavaScript รับทุก key เงียบ ๆ และ Python รับการเขียนลงทุก attribute ดู entry 9–11 และ 13–16

5. Custom metrics

requirement “global percentile” ถูก implement ด้วย distribution ไม่ใช่ histogram หรือไม่ ทุกค่า tag มีขอบเขตหรือไม่ สิ่งเหล่านี้รันสะอาดแต่เสียเงินหรือเสียความแม่นยำภายหลัง ทั้งคู่พิสูจน์ด้วย flush ของ Agent จริง ดู entry 17 และ 18

6. Terraform และ monitor JSON

แต่ละ resource validate กับ provider ที่ pin หรือไม่ recovery threshold อยู่ใน monitor_thresholds ชื่อ block เป็นเอกพจน์ query ของ dashboard เป็น metric_query พร้อม formula หรือไม่ query ของ burn-rate เป็น burn_rate(…).over(<SLO window>).long_window(…).short_window(…) หรือไม่ enum เป็นค่าจริงหรือไม่ ตรงนี้ terraform validate และ model constructor มีประโยชน์และไม่ครบ และความไม่ครบนั้นถูกวัดไว้ ดู entry 19–27

7. พิสูจน์

เลือกเครื่องมือที่มองเห็น layer ที่ bug อยู่ และเขียนไว้ว่าผลเขียวนั้น ไม่ ครอบคลุมอะไร นั่นคือ Verification tools โดยมี Review checklist เป็นฉบับหนึ่งหน้า

โมดูลนี้ครอบคลุมอะไรต่อไป

The AI Bug Catalog — 27 pattern แต่ละอันมีโค้ดที่ AI มักเขียน, output จริงที่จับได้, หมายเหตุตรง ๆ เมื่อมีแต่ API หรือ docs ที่ตัดสินได้ และวิธีแก้ รวมสาม bug ที่ review ของคอร์สเองเจอ (log_injection, query ของ dashboard แบบแบน, query ของ burn-rate)
Review Checklist — pattern ชุดเดียวกันเป็น checklist เจ็ดกลุ่ม แต่ละบรรทัดระบุเครื่องมือที่พิสูจน์
Verification Tools — สิ่งที่ agent configcheck, agent status, config dump ของ tracer, terraform validate, model ของ API client และ harness ของคอร์ส (npm run verify, --agent, --k8s) พิสูจน์ได้ รวมถึงจุดบอดที่วัดได้
สาม worked review ที่ใช้ลำดับการอ่านนี้กับระบบที่ AI เขียนเต็มรูปแบบ: Worked Review 1 — บริการ Node (dd-trace, logs, unified service tagging), Worked Review 2 — Kubernetes cluster (Agent ผ่าน Helm หรือ Operator, Autodiscovery, Cluster Agent) และ Worked Review 3 — monitors, SLO และ dashboard as code (Terraform กับ JSON) สามบทนี้เขียนและดูแลแยกจากหน้านี้; ถ้าลิงก์ใดเป็น 404 ระหว่างที่งานนั้นยังไม่เสร็จ ลำดับการอ่าน แคตตาล็อก checklist และเครื่องมือก็ใช้งานได้ด้วยตัวเอง
ทุกบทเรียน Phase 3 มีส่วน Reading AI-generated code อยู่แล้ว โมดูลนี้ไม่ทำซ้ำ — แต่จัดกลุ่มชุดที่กว้างกว่ารอบลำดับการอ่าน เริ่มจาก What is Datadog สำหรับเส้นทางทีละบทเรียน

Mental Model

Reading order for Datadog config you did not write:

1. Versions and pins   -> which Agent / tracer / provider, floating tags?
2. Agent config        -> check name, list vs mapping, scalar tags, DD_SITE
3. Kubernetes wiring   -> Pod template, container name, .checks (v2)
4. Tracer options      -> real option names, init order, env case
5. Custom metrics      -> distribution vs histogram, bounded tags
6. Terraform / JSON    -> provider schema, recovery, burn-rate grammar, enums
7. Prove it            -> the tool that sees the layer where the bug lives

"It ran / it validated" answers almost none of these. Most of the 27 catalog
entries pass at least one tool and fail another.

Common Misconceptions

“ถ้า agent configcheck สะอาด integration จะรัน” พิสูจน์ว่าผิดสามทางในแคตตาล็อก: tags แบบ scalar, ชื่อ check ที่ผิด และค่าที่ผิด type ล้วนพิมพ์ configuration ปกติแล้วล้มใน agent status
“key ของ option ที่ไม่รู้จักจะถูกปฏิเสธ” ไม่ใช่ใน JavaScript (log_injection ถูกเมินเงียบ ๆ) และไม่ใช่กับ Config object ของ Python (การเขียนสร้าง attribute) มีแต่ type checker หรือ harness ที่เห็น
“model ของ API client validate monitor JSON ของฉัน” มันตรวจ type ของ scalar และ field ที่ required type: "metrics alert" และ query burn-rate ที่ไม่มี .short_window() construct ผ่านทั้งคู่; _unparsed จับ enum และมีแต่ API ที่จับไวยากรณ์
“reviewer ที่ flag เยอะกว่าปลอดภัยกว่า” entry 5 และ 13 ของแคตตาล็อกเป็นสัญญาณเตือนเท็จ เวลาที่เสียกับมันคือเวลาที่ไม่ได้ใช้กับ DD_SITE ที่เป็น URL