Review checklist

ใช้รายการนี้ ด้วยตา กับทุก diff — ของคุณหรือของ AI — หลังจาก เครื่องมือใน Verification tools รันและผ่านแล้ว รายการนี้ตั้งใจให้พอดีหนึ่งหน้ากระดาษ ทุกบรรทัดลิงก์ไปยัง entry ในแคตตาล็อกที่อธิบายว่า ทำไม (ใน AI bug catalog entry มีเลข 1–27) หน้านี้จึงยังเป็นรายการ ไม่ใช่การรันโมดูลซ้ำ กลุ่มเรียงตามลำดับการอ่านใน module overview

flowchart LR
  A["Agent config<br/>(conf.d, datadog.yaml)"] --> A1["configcheck: shape only<br/>agent status: loads and types"]
  T["Tracer options"] --> T1["tsc / .d.ts / harness --options:<br/>names. Config dump: values. Payload: order"]
  M["Custom metrics"] --> M1["Captured flush + dogstatsd-stats:<br/>type and cardinality. Meaning: review"]
  TF["Terraform"] --> TF1["terraform validate: names and types.<br/>Semantics: API only"]
  J["JSON monitors / SLOs / catalog"] --> J1["Model: types and required.<br/>_unparsed: enums. Grammar: API only"]
  K["Kubernetes wiring"] --> K1["Cluster node Agent configcheck.<br/>Not kubectl"]
  V["Versions and pins"] --> V1["docker image inspect, config dump,<br/>package versions"]

สิ่งที่จับแต่ละกลุ่มได้จริง (ถ้ามี)

Agent configuration

conf.d/<name>.d/ ใช้ชื่อของ check (redisdb ไม่ใช่ redis) และ agent status — ไม่ใช่แค่ agent configcheck — แสดง check โดยไม่มี Loading Error หรือไม่ ดู entry 3 ที่พิสูจน์ด้วย Check redis not found in Catalog
instances: เป็น list (- host: …) ไม่ใช่ mapping ใช่ไหม Entry 1 พิสูจน์ด้วย cannot unmarshal !!map into []integration.RawMap
tags: (และ key ชนิด list อื่นทุกตัว) เป็น YAML list ไม่ใช่ scalar แบบ env:prod ใช่ไหม Entry 2 — configcheck พิมพ์ผ่านสบาย ๆ ส่วน agent status ปฏิเสธ
ค่าตัวเลขและ boolean เป็นตัวเลขและ boolean จริงไหม (timeout: 5 ไม่ใช่ "five") Entry 4 เห็นได้แค่ [ERROR] ใน agent status
DD_SITE เป็น domain (datadoghq.com) ไม่ใช่ URL ใช่ไหม Entry 6 พิสูจน์ด้วย https://process.https://api.datadoghq.com.
ก่อนเขียนว่า “ไม่มี init_config” คุณรันเครื่องมือแล้วหรือยัง Entry 5: ไฟล์ถูก load finding ที่เครื่องมือ reproduce ไม่ได้คือบันทึก ไม่ใช่ bug

Image และ Kubernetes wiring

image ของ Agent ถูก pin เป็น tag เต็มหรือ digest แทน latest / major ที่ลอย เพื่อให้ postmortem ระบุ Agent ที่รันได้หรือไม่ Entry 7 — วันนี้ tag ตรงกัน จึงไม่มีใครสังเกต
Autodiscovery annotation อยู่บน Pod template (spec.template.metadata) ใช้ ชื่อ container และอยู่ในรูป .checks (v2, Agent 7.36+) หรือไม่ Entry 8 — docs อย่างเดียว ไม่มีอะไร offline พิสูจน์ ตรวจบน cluster จริงด้วย agent configcheck ของ Agent บน node
DD_ENV, DD_SERVICE, DD_VERSION มาจากแหล่งเดียวที่เป็นตัวพิมพ์เล็ก (pod label) ทุก workload หรือไม่ Entry 12

Tracer option (Node.js และ Python)

ทุก key ที่ส่งให้ tracer.init({...}) มีอยู่ใน TracerOptions และสะกดแบบ camelCase (logInjection ไม่ใช่ log_injection) หรือไม่ Entry 9 และ 11 TypeScript: tsc --noEmit; JavaScript: harness --options หรือ startup config dump
dd-trace ถูก initialise (หรือ preload ด้วย --import dd-trace/initialize.mjs) ก่อน library ที่ต้อง instrument หรือไม่ Entry 10 — พิสูจน์ด้วย payload ที่ดักได้ซึ่งไม่มี express.request
คำกล่าวว่า setting “deprecated” มีหน้า docs รองรับ ไม่ใช่ความจำหรือไม่ Entry 13 — DD_TRACE_SAMPLE_RATE ไม่ได้ deprecated และ dd-trace 6.17.0 (Node) ทำตาม แต่ ddtrace 4.15.2 (Python) เมินเงียบ ๆ ให้ใช้ DD_TRACE_SAMPLING_RULES เพื่อพฤติกรรมข้ามภาษา
ใน Python: ทุก ddtrace.config.<x> เป็น attribute จริง (การ อ่าน ไม่ใช่การเขียนที่สร้าง attribute ขึ้นเงียบ ๆ) หรือไม่ Entry 14
tracer.configure(...) ถูกเรียกด้วย keyword argument ที่อยู่ใน inspect.signature(tracer.configure) เท่านั้นหรือไม่ address ของ agent อยู่ใน DD_TRACE_AGENT_URL Entry 15
RUM init ของเบราว์เซอร์มี allowedTracingUrls (ไม่ใช่ allowedTracingOrigins) หรือไม่ Entry 16 — tsc จับชื่อ, มีแต่ trace ใน UI ที่จับการละไว้

Custom metrics

เมื่อ requirement บอก “global percentile” type เป็น distribution ไม่ใช่ histogram หรือไม่ Entry 17 — flush ที่ดักได้ไป /api/beta/sketches เทียบกับ /api/v1/series
ทุกค่า tag มาจากเซตที่เล็กและมีขอบเขตหรือไม่ (ไม่มี user_id, request id หรือ URL ดิบ) Entry 18 — 50 ค่า 50 series

Terraform

ทุก resource block validate กับ provider ที่ pin ไว้ (terraform init && terraform validate) ไม่ใช่ตัวที่ AI จำได้หรือไม่ Entry 19–20
ใน datadog_dashboard query ของแต่ละ request เป็น query { metric_query { … } } พร้อม block formula หรือไม่ Entry 19
recovery threshold อยู่ใน monitor_thresholds { … }, tags เป็น list, และชื่อ block เป็นเอกพจน์ (template_variable) หรือไม่ Entry 20
สำหรับ metric ที่เบาบางหรือ traffic ต่ำ ตั้ง notify_no_data, no_data_timeframe และ require_full_window ด้วยความตั้งใจหรือไม่ Entry 21 — validate เขียวทั้งสองทาง และ default ของ notify_no_data ใน provider คือ false
datadog_role อ้าง permission ด้วย ID และ logs_modify_indexes ตั้งใจให้ role นี้จริงหรือไม่ Entry 22
exclusion filter แคบเท่าเจตนาและเรียงตามที่ตั้งใจ (active ตัวแรกที่ match ชนะ) หรือไม่ Entry 23

JSON ของ monitor, SLO และ catalog

query ของ burn-rate เป็น burn_rate("<slo_id>").over("<7d|30d|90d>").long_window("…").short_window("…") > N หรือไม่ Entry 24 — model validation เขียวสำหรับตัวที่ผิด มีแต่ API กับไวยากรณ์ใน docs ที่คัดค้าน
query ของ composite monitor อ้าง monitor ID จริง หรือไม่ Entry 25
JSON ถูกตรวจด้วยอะไรที่เข้มกว่า constructor (ตรวจ _unparsed บน object ที่ deserialize) เพื่อให้ enum ที่พิมพ์ผิดปรากฏหรือไม่ Entry 26
entry ของ Service Catalog เป็น apiVersion: v3 และมีคนตรวจ key ใน spec (schema ไม่ปฏิเสธ key ที่ไม่รู้จัก) หรือไม่ Entry 27

Tooling

อ่าน agent status หลัง agent configcheck และให้ check รันอย่างน้อยหนึ่งครั้งหรือไม่ ดู Verification tools
CI รัน npm run verify (option, Terraform, JSON model) กับทุก fence และ node tools/verify-snippets.mjs --agent เมื่อมี YAML ของ Agent หรือไม่
ทุกคำกล่าวที่ไม่มีเครื่องมือพิสูจน์ มี URL ของ docs อยู่ข้าง ๆ — พร้อมวันที่หรือเวอร์ชัน — หรือไม่

Spot the bug

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

resource "datadog_dashboard" "checkout" {
title       = "Checkout overview"
layout_type = "ordered"

widget {
  timeseries_definition {
    request {
      q            = "avg:system.cpu.user{*}"
      display_type = "line"
    }
    title_size = "large"
  }
}

template_variables {
  name = "env"
}
}

เฉลย

แค่บรรทัดเดียว และ terraform validate (provider 4.22.0) พิมพ์วิธีแก้ให้: Unsupported block type ... Blocks of type "template_variables" are not expected here. Did you mean "template_variable"? block เป็นเอกพจน์ ฉบับแก้ที่ validate ผ่าน:

resource "datadog_dashboard" "checkout" {
  title       = "Checkout overview"
  layout_type = "ordered"

  widget {
    timeseries_definition {
      request {
        q            = "avg:system.cpu.user{*}"
        display_type = "line"
      }
      title_size = "large"
    }
  }

  template_variable {
    name = "env"
  }
}

Mental Model

เรียงตามต้นทุนของความผิด ชื่อและ shape (ถูก ตรวจด้วยเครื่องมือได้) ก่อน แล้วค่าและลำดับ (ลึกไปอีกชั้น) แล้วความหมาย (review หรือ API)
ทุกบรรทัดคือคำถามใช่/ไม่ใช่ที่มีเจ้าของ “คำสั่งไหนตอบข้อนี้” เป็นส่วนของบรรทัด บรรทัดที่ไม่มีคำสั่งคือบรรทัด docs และต้องมี URL
เขียวแปลว่า “ไม่ใช่ error ชนิดนี้” configcheck เขียวตัด shape ออก แต่ไม่ได้บอกอะไรว่า check load ขึ้นหรือไม่

Trade-offs

เจ็ดกลุ่มมากเกินไปสำหรับ diff เล็ก ข้ามกลุ่มที่ diff ไม่แตะ แต่ห้ามข้ามกลุ่ม Tooling
รายการอาจตรึงความเชื่อ Entry 5 และ 13 อยู่ในหน้านี้เพราะกฎที่ฟังดูสมเหตุสมผลกลับเป็นเท็จหรือจริงแค่ครึ่งเดียว พิสูจน์บรรทัดใหม่เมื่อเวอร์ชัน Agent, tracer หรือ provider เปลี่ยน
บรรทัดที่ใช้ docs เก่าลง ตำแหน่งของ Autodiscovery และไวยากรณ์ burn-rate อ้าง URL ของ docs อ่านซ้ำเมื่อ upgrade

Common Misconceptions

“harness ผ่าน แปลว่า checklist เสร็จ” harness พิสูจน์ชื่อ type และ shape; บรรทัดของ Monitor, SLO และ permission ข้างบนอยู่นอกขอบเขตของมัน
“ข้อใน checklist ชัดเจนอยู่แล้ว” แต่ละข้ออย่างน้อยหนึ่งครั้งในโมดูลนี้ ถูกสร้างโดย assistant ที่ฟังดูมั่นใจ
“terraform validate ตรวจกับ Datadog” มันตรวจกับ provider schema; ไม่มี request ใดถูกส่ง (validate = false ใน provider block ของ harness)

ทำไม checklist บอกให้อ่าน agent status หลัง agent configcheck พิมพ์ข้อมูลเหมือนกัน configcheck ตรวจ shape ของไฟล์ (list เทียบ mapping) ส่วนค่าผิด type, tags แบบ scalar และชื่อ check ที่ไม่รู้จักจะล้มใน agent status เท่านั้น agent status เร็วกว่า configcheck ถูก deprecate

โค้ดนี้อยู่ในกลุ่มไหนของ checklist และอะไรจับได้

import tracer from 'dd-trace';
tracer.init({ service: 'checkout', agentUrl: 'http://dd-agent:8126' });

Agent configuration - configcheck Tracer options - tsc (TS2353 unknown property) หรือ harness --options; JavaScript ล้วนจะรันและเมินมันเงียบ ๆ Terraform - terraform validate Custom metrics - dogstatsd-stats

บรรทัดไหนของ checklist ที่ไม่มีเครื่องมือ offline ในโมดูลนี้ตอบได้ instances เป็น list หรือไม่ Autodiscovery annotation อยู่บน Pod template แทน Deployment metadata หรือไม่ ชื่อ block ของ Terraform มีใน provider 4.22.0 หรือไม่ option ของ tracer มีใน .d.ts หรือไม่

checklist ถามว่าคำกล่าว 'deprecated' มีหน้า docs รองรับหรือไม่ กรณีจริงในโมดูลนี้ที่เป็นเหตุของบรรทัดนี้คืออะไร log_injection ที่ถูกเปลี่ยนชื่อ DD_TRACE_SAMPLE_RATE - ไม่ได้ deprecated; dd-trace 6.17.0 (Node) ทำตาม แต่เป็น no-op เงียบ ๆ ใน ddtrace 4.15.2 (Python) จึงใช้ DD_TRACE_SAMPLING_RULES เป็น setting ข้ามภาษา image tag latest allowedTracingOrigins

ทำไมบรรทัด burn-rate ถูกจัดกลุ่มกับ 'มีแต่ API และไวยากรณ์ใน docs ที่คัดค้าน' แทนที่จะอยู่กับบรรทัดที่เครื่องมือตรวจได้ เพราะ API client ไม่รองรับ burn rate เพราะ model มอง query เป็น string ทึบ - query ที่ไม่มี .short_window() และ .over("1h") ก็ construct ผ่าน เพราะสร้าง SLO เป็นโค้ดไม่ได้ เพราะ terraform validate ปฏิเสธ

คุณรีวิวการเปลี่ยน Terraform ที่ตั้ง critical_recovery = 1.5 บน datadog_monitor checklist คาดหวังอะไร ไม่มีอะไร มันเป็น argument ระดับบนสุดที่ valid ให้อยู่ใน monitor_thresholds { ... } - ระดับบนสุดเป็น Unsupported argument ใน provider 4.22.0 และถ้าไม่มี recovery threshold monitor จะ recover ทันทีที่เงื่อนไข alert หาย ให้เป็น string ให้ลบออก