Monitor Types และ Thresholds

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

Datadog Monitor คือ query ที่ save ไว้บวกกับกฎชุดหนึ่งสำหรับแปลงผลของ query นั้นให้เป็น state — OK, Warn, Alert, หรือ No Data — และในบรรดา monitor type ที่มีมากมาย metric alert คือที่ที่ชัดเจนที่สุดในการเรียนว่า threshold ทำงานยังไงจริง ๆ

Monitor type เยอะแยะ แต่ mental model เดียว

Datadog มี monitor type เยอะพอสมควร เช็ค enum จริงปัจจุบันตรงจาก MonitorType.allowed_values ของ datadog_api_client ที่ติดตั้งจริง แทนที่จะเชื่อ list ที่อาจล้าสมัยจากความจำ — มี metric alert, log alert, trace-analytics alert (APM), composite, synthetics alert, slo alert, rum alert, process alert, service check, event alert/event-v2 alert, audit alert, ci-pipelines alert, ci-tests alert, cost alert, database-monitoring alert, data-jobs alert, network-performance alert, network-path alert, data-quality alert, error-tracking alert, และ llm-observability alert

ทั้งหมดนี้เสียบเข้ากับ alerting และ notification machinery ตัวเดียวกัน ไอเดียเรื่อง state, threshold, และ message เดียวกัน สิ่งที่ต่างคือแค่ข้อมูลมาจากไหน บทนี้ (และที่เหลือใน module นี้) ใช้ metric alert เป็นตัวอย่างจริง เพราะ threshold configuration ของมันคือ shape ที่ monitor type อื่นทุกตัวใช้ซ้ำในทางจิตวิญญาณ

monitors/payments-api-log-alert.json

{
  "name": "Payments API 5xx errors spiking",
  "type": "log alert",
  "query": "logs(\"service:payments-api status:error\").index(\"main\").rollup(\"count\").last(\"5m\") > 50"
}

monitors/payments-api-apm-alert.json

{
  "name": "payments-api p99 latency high",
  "type": "trace-analytics alert",
  "query": "trace-analytics(\"service:payments-api\").rollup(\"p99\", \"@duration\").last(\"5m\") > 2000000000"
}

🐶 พิสูจน์: ทั้ง log alert และ APM alert validate ผ่าน Monitor model จริง

รันทั้งสอง fence ข้างบนผ่าน Monitor(**data, _check_type=True) จริงตัวเดียวกับที่ harness ใช้ (datadog-api-client==2.61.0 ที่ pin ไว้): ทั้งคู่ {"ok": true, "error": null} Monitor model เดียวกัน shape ระดับบนสุดเดียวกัน (name/type/query/options) แค่ค่า type กับภาษา query ต่างกัน — พิสูจน์ว่า claim “machinery เดียวกัน แค่ data source ต่างกัน” ข้างบนไม่ใช่แค่ prose แต่คือ client-side model ตัวเดียวกันจริง ๆ

กายวิภาคของ threshold ใน metric alert

query ของ metric alert มี comparison อยู่ในตัวแล้ว และ options.thresholds สะท้อนและขยายมัน:

monitors/payments-api-cpu.json

{
  "name": "High CPU usage on payments-api",
  "type": "metric alert",
  "query": "avg(last_5m):avg:system.cpu.user{service:payments-api} > 90",
  "options": {
    "thresholds": {
      "critical": 90,
      "warning": 80,
      "critical_recovery": 70,
      "warning_recovery": 50
    },
    "evaluation_delay": 300
  }
}

• critical — ข้ามค่านี้แล้วย้าย monitor เข้า state Alert ปกติจะตรงกับ comparison ที่เขียนไว้ใน string query อยู่แล้ว
• warning — เส้นที่ severity ต่ำกว่าและมาก่อน ข้ามมันแล้วย้ายเข้า state Warn มีประโยชน์สำหรับเผยว่ามีอะไรกำลังเลื่อนไปผิดทิศทางก่อนจะกลายเป็น page

ทั้ง critical และ warning คือ threshold แบบ trigger — ตอบคำถามว่า “เมื่อไหร่ถึงถือว่าเป็นปัญหา”

Recovery threshold: ตัวเลขคู่ที่ต่างออกไปโดยตั้งใจ

critical_recovery และ warning_recovery เป็น field แยกกัน และตอบคำถามคนละข้อ: “เมื่อไหร่ถึงถือว่าปัญหานี้ จบแล้ว” ถ้าไม่ตั้งค่าไว้ Datadog default ให้เท่ากับ trigger threshold แต่ทีมส่วนใหญ่ override มันโดยตั้งใจ

นี่คือเหตุผลว่าทำไม gap นี้ถึงสำคัญ ถ้า recovery threshold เท่ากับ trigger threshold metric ที่แกว่งอยู่แถว 90 จะ alert, recover, alert, recover วนไปเรื่อย ๆ — เรียกว่า flapping และเป็นหนึ่งในวิธีที่เร็วที่สุดที่จะทำให้ทีม on-call เลิกเชื่อ (แล้วเริ่มเมิน) page ของตัวเอง

ตั้ง critical_recovery ให้ต่ำกว่า critical อย่างมีนัยสำคัญ — 70 แทนที่จะเป็น 90 — สร้าง dead zone พอ monitor fire แล้ว metric ต้องลดลงมากกว่านั้นอย่างเห็นได้ชัดก่อนที่ Datadog จะถือว่ามัน resolve จริง ค่าที่เด้งระหว่าง 88 กับ 92 จะอยู่ใน state Alert ตลอด แทนที่จะ flap เข้าออก

evaluation_delay: อย่า alert บนข้อมูลที่มาไม่ครบ

metric บางตัวมาถึงช้า — cost/billing metric กับอะไรก็ตามที่ aggregate จาก upstream pipeline ที่ช้าคือตัวอย่างที่พบบ่อย ถ้าไม่คำนึงถึงความล่าช้านั้น evaluation window ของ monitor อาจดูต่ำผิดปกติหรือไม่ครบ แล้วมัน trigger (หรือ flap) บนข้อมูลที่แค่ยังมาไม่ครบก็ได้

evaluation_delay เลื่อนจุดเวลาที่ query ถูก evaluate เทียบด้วย หน่วยวินาที ด้วย evaluation_delay: 300 (ใน fence ข้างบน) monitor evaluate window ของมันช้ากว่าปกติ 5 นาที ให้เวลาข้อมูลที่มาช้าโผล่มาก่อนที่จะตัดสินใจ

พิสูจน์: กับดักของ notify_no_data — ต้องมีข้อมูลโผล่มาอย่างน้อยครั้งหนึ่งก่อน

docs.datadoghq.com/monitors/configuration/ ระบุตรง ๆ และนี่คือวิธีที่พบบ่อยที่สุดที่ monitor แบบ “เราจะได้ alert ถ้า heartbeat metric หยุดรายงาน” พังหน้าที่ของตัวเองไปเงียบ ๆ:

Note: The monitor must be able to evaluate data before alerting on missing data. For example, if you create a monitor for service:abc and data from that service is not reporting, the monitor does not send alerts.

พูดอีกแบบ notify_no_data ป้องกัน metric ที่เคยรายงานแล้วหยุด — ไม่ใช่ป้องกัน metric ที่ config ผิด (tag ผิด, ชื่อ metric ผิด, integration ไม่เคยติดตั้ง) แล้วเลยไม่เคยรายงานตั้งแต่แรก monitor ที่เฝ้า metric ที่ไม่มี history เลยพฤติกรรมเหมือนกันเป๊ะไม่ว่า monitor นั้นจะ config ถูกสมบูรณ์หรือพังทั้งหมด: เงียบ ไม่มี alert ทั้งสองกรณี

monitors/payments-api-heartbeat.json

{
  "name": "payments-api heartbeat metric missing",
  "type": "metric alert",
  "query": "avg(last_5m):avg:payments_api.heartbeat{*} < 1",
  "options": {
    "notify_no_data": true,
    "no_data_timeframe": 20
  }
}

หน้าเอกสารเดียวกันเพิ่มกับดักที่สองที่อิสระจากกันมาทับอีกชั้น: พฤติกรรม default สำหรับ missing data ขึ้นกับ query type และ notify_no_data/no_data_timeframe เป็นแค่หนึ่งในห้าพฤติกรรมที่เลือกได้ (Evaluate as zero, Show last known status, Show NO DATA, Show NO DATA and notify, Show OK) — quote ตรง ๆ: “For queries with default_zero(), missing data is always evaluated as zero… For queries without default_zero(), Count queries default to Evaluate as zero, while other query types default to Show last known status.” query แบบ avg() เหมือน CPU monitor ข้างบน default เป็น Show last known status ตอนข้อมูลหายไป — หมายความว่าถ้าไม่ตั้ง notify_no_data: true ชัดเจน metric alert ส่วนใหญ่ไม่ถึงกับเปลี่ยนเป็น state NO DATA ที่เห็นได้ด้วยซ้ำ มันแค่แสดง state เดิมที่มีอยู่ก่อนหน้าเงียบ ๆ ต่อไป ซึ่งอาจเป็น OK สงบ ๆ จากหลายชั่วโมงก่อนก็ได้

🐶 พิสูจน์: fence นี้ validate ผ่าน Monitor model จริง

รัน fence heartbeat ข้างบนผ่าน Monitor(**data, _check_type=True): {"ok": true, "error": null} notify_no_data และ no_data_timeframe ล้วนเป็น field จริงปัจจุบันบน MonitorOptions (ยืนยันด้วยการ list MonitorOptions.attribute_map ของ client ที่ pin ไว้จริง) — พร้อมกับ field ใหม่กว่าอย่าง on_missing_data ที่เอกสารระบุว่าจำเป็นสำหรับ monitor type บางแบบ (APM Trace Analytics, Audit Logs, CI Pipelines, Error Tracking, Events, Logs, และ RUM monitor) แทนที่ no_data_timeframe แบบเก่า

Watchdog: anomaly detection ที่ไม่ต้อง config เลย ไม่ใช่ monitor ที่เราสร้าง

docs.datadoghq.com/watchdog/ อธิบาย Watchdog ตรง ๆ: “Watchdog is Datadog’s AI engine, providing you with automated alerts, insights, and root cause analyses that draw from observability data across the entire Datadog platform… All Watchdog features come built-in, and do not require setup.” มัน “proactively computes a baseline of expected behavior for your systems, applications, and deployments… used to detect anomalous behavior.”

ความต่างเรื่อง “ไม่ต้อง setup” นี้สำคัญกับบทนี้: JSON fence ของ monitor ทุกอันข้างบนคือสิ่งที่คนคนหนึ่ง (หรือ Terraform/API call ที่ AI สร้าง) ตั้งใจเขียนขึ้นเอง — query, threshold, type Watchdog ตรงข้ามกัน: ไม่มี type: "watchdog alert" ใน enum MonitorType จริงที่เช็คไว้ข้างบน และไม่มี JSON payload ให้เขียนเลย เพราะ Watchdog alert โผล่มาอัตโนมัติจาก baseline computation ของ Datadog เอง ไม่ใช่จาก monitor definition ที่ใครเขียนขึ้น สิ่งที่ใกล้เคียงที่สุดที่เราต้องตั้งค่าเองคือ monitor แบบ Anomaly Algorithm (query alert ที่ใช้ function anomaly()) — ฟีเจอร์ที่เกี่ยวข้องแต่แยกกัน: anomaly monitor คือ query ที่เราเขียนและ tune เอง Watchdog คือ background process ที่ไม่ต้องเขียนอะไรเลย

renotify_interval: แนะนำไว้ก่อน (เจาะลึกเต็มในบทถัดไป)

ถ้า monitor ยังคง trigger อยู่ renotify_interval (หน่วยนาที) ทำให้มัน notify ซ้ำเป็นระยะแทนที่จะ notify แค่ครั้งเดียว — บทถัดไปครอบ renotify_interval คู่กับ escalation_message และ composite monitor แบบเต็ม

flowchart LR
  OK -->|value crosses warning e.g. 80| WARN[Warn]
  WARN -->|value crosses critical e.g. 90| ALERT[Alert]
  OK -->|value crosses critical directly| ALERT
  ALERT -->|value drops below critical_recovery e.g. 70| WARN
  WARN -->|value drops below warning_recovery e.g. 50| OK

การเปลี่ยนสถานะของ metric alert

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

critical และ warning ตัดสินว่า metric alert trigger เมื่อไหร่ critical_recovery และ warning_recovery เป็น field แยกที่ตัดสินแค่ว่ามันกลับไป OK เมื่อไหร่ — คง gap ระหว่างสองคู่นี้ไว้ป้องกัน flapping — และ evaluation_delay ปกป้อง monitor จากการตัดสินข้อมูลที่มาไม่ครบ notify_no_data จับได้แค่ metric ที่หยุดรายงานหลังจากรายงานไปแล้วอย่างน้อยครั้งหนึ่ง (พิสูจน์แล้วข้างบนจากเอกสาร) และ Watchdog ไม่ต้องมี monitor definition เลย — มันคือ baseline ในตัว ไม่ใช่สิ่งที่เราเขียนขึ้น

Reading AI-generated code

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

// AI comment: "Alert us if the payments-api heartbeat metric ever stops reporting"
{
"name": "payments-api heartbeat monitor",
"type": "metric alert",
"query": "avg(last_5m):avg:payments_api.heartbeat{*} < 1",
"options": {
  "thresholds": {
    "critical": 1
  }
}
}

เฉลย

นี่คือ JSON ที่ valid และผ่าน Monitor(**data, _check_type=True) ได้สะอาด — พิสูจน์แล้วข้างบนว่า client model ไม่มีความเห็นเลยว่า notify_no_data มีอยู่หรือไม่ บั๊กคือ: ไม่มี notify_no_data/no_data_timeframe (หรือ on_missing_data) เลย ถ้า payments_api.heartbeat หยุดรายงานไปเลย default ที่ quote จากเอกสารสำหรับ query แบบ avg() จะใช้ — Show last known status — หมายความว่า monitor แสดง state เดิมที่มีอยู่ก่อนหน้าเงียบ ๆ ต่อไป ไม่มี notification เลย นานเท่าที่ metric ยังหายอยู่ เป้าหมายที่ comment ของ AI ระบุไว้ (“alert us if it ever stops reporting”) คือ scenario เดียวเป๊ะที่ config นี้ไม่ครอบคลุม การแก้: เพิ่ม "options": {"notify_no_data": true, "no_data_timeframe": 20} เข้าไปคู่กับ threshold ที่มีอยู่แล้ว — และอย่าลืมกับดักที่ลึกกว่านั้นที่พิสูจน์แล้วข้างบนแม้หลังแก้แล้ว: ถ้า metric ไม่เคยรายงานสักครั้งเลย (service ใหม่เอี่ยม, ชื่อ metric พิมพ์ผิด) notify_no_data ก็ไม่ทำงานเช่นกัน เพราะ monitor ประเมิน missing data ที่มันไม่เคยมี baseline ให้ไม่ได้

Mental Model

ห้าการตั้งค่าของ metric alert — critical, warning, critical_recovery, warning_recovery, evaluation_delay — จริง ๆ แล้วตอบสามคำถามที่แยกกัน และการปนกันคือจุดที่ misconfiguration ส่วนใหญ่มาจาก “นี่แย่เมื่อไหร่” คือ critical/warning “นี่ไม่แย่แล้วเมื่อไหร่” คือ critical_recovery/warning_recovery — คำถามที่แยกจริง ๆ ไม่ใช่กระจกของคำถามแรก เพราะ dead zone ระหว่างสองคู่นี้แหละที่หยุด flapping “เมื่อไหร่ที่ควรจะดูด้วยซ้ำ” คือ evaluation_delay — คำถามเรื่องเวลาที่ข้อมูลมาถึงเอง ไม่เกี่ยวกับดีหรือแย่เลย notify_no_data ตอบคำถามที่สี่ที่แยกออกไปอีก — “ถ้าไม่มีข้อมูลให้ตัดสินล่ะ” — และ Watchdog ไม่ได้ตอบคำถามพวกนี้ต่อ-monitor เลยสักข้อ มันคือระบบคนละแบบไปเลย คอยเฝ้า anomaly ที่ไม่มีใครเขียน query ให้

Trade-offs

• Recovery threshold ที่เท่ากับ trigger เทียบกับ dead zone ที่ตั้งใจ — threshold ที่เท่ากันคิดง่ายกว่าและตรงกับ comparison ของ query เองเป๊ะ แต่พิสูจน์แล้วข้างบนว่ามัน flap กับ metric ไหนก็ตามที่แกว่งอยู่ใกล้เส้น; dead zone หยุด flapping แลกกับ monitor ที่อยู่ใน state Alert นานกว่าค่าจริง ณ ขณะนั้นของ metric จะบอกนิดหน่อย
• notify_no_data: true เทียบกับปล่อยไม่ตั้ง — เปิดมันจับ metric ที่เงียบไปหลังจากรายงานปกติ มีประโยชน์จริงกับ check แบบ heartbeat; ปล่อยไม่ตั้ง (default ของ query type ส่วนใหญ่ พิสูจน์แล้วข้างบนจากเอกสาร) หลีกเลี่ยง alert รบกวนบน metric ที่คาดว่าจะ sparse อยู่แล้ว แลกกับจุดบอดเงียบ ๆ บน metric ที่ควรรายงานตลอด
• Anomaly Algorithm monitor ที่เขียนเอง เทียบกับพึ่ง Watchdog — anomaly monitor tune ได้ (เลือก algorithm, sensitivity, query เฉพาะ) และโผล่เป็น monitor ธรรมดาใน notification pipeline เดียวกับทุกอย่าง; Watchdog ไม่ต้อง config เลยและเผยสิ่งที่ไม่มีใครคิดจะเขียน query ให้ แลกกับการ tune ไม่ได้ตามความหมาย “ผิดปกติ” เฉพาะของทีมใดทีมหนึ่งแบบที่ monitor ที่เขียนเองทำได้

Common Misconceptions

• “notify_no_data alert กับ metric ไหนก็ตามที่ไม่เคยโผล่มาเลย” ไม่จริง — พิสูจน์แล้วข้างบนด้วยการ quote เอกสารตรง ๆ: monitor ต้อง evaluate ข้อมูลอย่างน้อยครั้งหนึ่งก่อนถึงจะ alert ได้ว่าข้อมูลนั้นหายไป metric ที่ไม่เคยรายงานเลยให้ผลเป็นความเงียบ ไม่ใช่ alert ไม่ว่า notify_no_data จะเปิดหรือไม่
• “ถ้าไม่ config พฤติกรรม no-data Datadog แสดง state NO DATA ที่เห็นได้โดย default” ไม่จริง — พิสูจน์แล้วข้างบน: สำหรับ query type อื่นนอกจาก Count (และไม่มี default_zero()) default ที่เอกสารระบุคือ Show last known status ซึ่งเก็บ state เดิมของ monitor ไว้เงียบ ๆ แทนที่จะเผยอะไรออกมา
• “Watchdog เป็น monitor type ที่เราสร้างได้ เหมือน metric alert หรือ composite monitor” ไม่จริง — พิสูจน์แล้วข้างบนจาก docs.datadoghq.com/watchdog/ และ enum MonitorType จริง: ไม่มี monitor type ของ Watchdog ไม่มี JSON payload ให้เขียน Watchdog คือระบบ background ในตัวที่ไม่ต้อง config เลย
• “Recovery threshold แค่เป็นเอกสารของ trigger threshold ไม่มีความหมายแยกจากกันจริง ๆ” ไม่จริง — พิสูจน์แล้วข้างบน: critical_recovery/warning_recovery เป็น field อิสระที่พอตั้งให้ต่ำกว่า trigger threshold อย่างมีนัยสำคัญแล้ว คือกลไกทั้งหมดที่ป้องกัน flapping

ใน Datadog metric alert threshold critical กับ critical_recovery สัมพันธ์กันยังไง

ต้องเท่ากันเสมอ monitor ถึงจะทำงาน critical ตัดสินว่า monitor เข้า state Alert เมื่อไหร่ critical_recovery ตัดสินแค่ว่ามันกลับไป OK เมื่อไหร่ critical_recovery ถูก evaluate ก่อน critical ใน query critical_recovery ตั้งระยะเวลา retention ของ alert history

ทำไมทีมส่วนใหญ่ถึงตั้ง critical_recovery ต่ำกว่า critical แทนที่จะเท่ากัน

เพื่อให้ monitor evaluate เร็วขึ้น เพื่อลดจำนวน metric point ที่ต้องใช้ evaluate เพื่อสร้าง gap ที่ป้องกัน flapping ตอน metric แกว่งอยู่แถวเส้น critical เพราะ Datadog บังคับให้ recovery threshold ต่างจาก trigger threshold

monitor ตัวหนึ่ง config notify_no_data: true แต่ metric ที่มันเฝ้าไม่เคยรายงานข้อมูลเลยสักครั้ง (service ใหม่เอี่ยม หรือชื่อ metric พิมพ์ผิด) พิสูจน์แล้วข้างบนด้วยการ quote เอกสารตรง ๆ เกิดอะไรขึ้น

monitor ส่ง No Data notification ทันทีเพราะ metric หายไป monitor ไม่ส่ง alert เลย -- มันต้อง evaluate ข้อมูลอย่างน้อยครั้งหนึ่งก่อนถึงจะ alert ได้ว่าข้อมูลนั้นหายไป notify_no_data แก้คำผิดให้อัตโนมัติแล้วเริ่ม alert บน metric ที่ถูกต้อง monitor default ไปที่ state Warn หลัง 5 นาที

สำหรับ metric query แบบ avg() ทั่วไปที่ไม่ได้ตั้ง no-data option ชัดเจน พฤติกรรม DEFAULT ที่เอกสารระบุตอน query คืนค่าไม่มีข้อมูลคืออะไร

Show NO DATA and notify Evaluate as zero Show last known status -- monitor เก็บ state เดิมไว้เงียบ ๆ ไม่มีการเปลี่ยนแปลงที่เห็นได้ ไม่มี notification monitor ลบตัวเองอัตโนมัติ

Monitor model จริงของ datadog_api_client พิสูจน์อะไรกับ JSON payload ที่ options.thresholds.critical ตั้งเป็น string "ninety" แทนที่จะเป็นเลข 90

validate ผ่านสำเร็จ -- client ไม่เช็ค type ของค่า threshold throw ApiTypeError จริง: type ที่ต้องการคือ float แต่ type ที่ส่งมาคือ str แปลง "ninety" เป็น 90 ให้เงียบ ๆ throw JSONDecodeError ก่อน model จะถูก construct ด้วยซ้ำ

Watchdog ต่างจาก monitor type อื่นทุกตัวในบทนี้ยังไง พิสูจน์แล้วข้างบนจาก docs.datadoghq.com/watchdog/ และ enum MonitorType จริง

Watchdog แค่เป็น composite monitor ที่มีชื่อพิเศษ Watchdog ต้องการ JSON payload shape เดียวกับ metric alert แค่ type: "watchdog alert" Watchdog คือระบบ background ในตัวที่ไม่ต้อง config เลย ไม่มี monitor type ให้เขียน ไม่มี JSON payload -- มันคำนวณ baseline ของตัวเองอัตโนมัติ Watchdog ใช้ได้แค่กับ monitor ที่อิง log เท่านั้น

ข้อไหนถูกต้องเกี่ยวกับ Datadog monitor type ที่มีมากมาย (metric alert, log alert, composite, synthetics alert, SLO alert ฯลฯ)

แต่ละ type มีระบบ notification และ escalation แยกของตัวเอง ทั้งหมดใช้ alerting/notification machinery ตัวเดียวกัน มีแค่ data source ที่ต่างกัน มีแค่ metric alert ที่รองรับ threshold composite monitor ส่ง notification ไม่ได้

Submit

Mark as complete