Synthetics กับ Uptime Check

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

Synthetic Monitoring รัน scripted check เชิงรุกจาก global network ของ location ที่ Datadog เป็นเจ้าของเอง แทนที่จะรอให้ traffic จริงจาก user หรือ backend เผยปัญหาออกมา และเมื่อ test ตัวหนึ่ง fail จะเสียบเข้ากับ monitor และ notification pipeline เดียวกับที่พูดถึงไปแล้วก่อนหน้าใน module นี้พอดี

API test: single request-response check

API test คือ single request-response check แบบ HTTP/TCP/DNS/ICMP — เช่นยิงไปที่ health-check endpoint แล้ว assert status code, response time หรือ body content โดยรันซ้ำ ๆ จาก location ที่เลือกไว้

{
  "name": "Checkout health check",
  "type": "api",
  "subtype": "http",
  "config": {
    "request": {
      "method": "GET",
      "url": "https://checkout.example.com/health"
    },
    "assertions": [
      { "type": "statusCode", "operator": "is", "target": 200 },
      { "type": "responseTime", "operator": "lessThan", "target": 300 }
    ]
  },
  "locations": ["aws:ap-southeast-1", "aws:eu-west-1"]
}

Browser test: user journey แบบ scripted เต็มรูปแบบ

Browser test รัน scripted browser flow เต็มรูปแบบผ่านหลาย step — เปิดหน้าเว็บ กดปุ่ม login assert ว่า dashboard element โผล่มา — เพื่อทดสอบ user journey จริงตั้งแต่ต้นจนจบ Browser test จับสิ่งที่ API test ทำไม่ได้โดยธรรมชาติ — หน้าเว็บอาจ return 200 แต่ UI พังก็ได้ หรือ flow อาจ fail กลางคันทั้งที่ทุก request ที่อยู่เบื้องหลัง “สำเร็จ” หมด

{
  "name": "Login flow",
  "type": "browser",
  "config": {
    "steps": [
      { "type": "goToUrl", "params": { "value": "https://app.example.com/login" } },
      { "type": "click", "params": { "element": "#login-button" } },
      { "type": "assertElementPresent", "params": { "element": "#dashboard" } }
    ]
  },
  "locations": ["aws:us-east-1"]
}

Alerting pipeline เดียวกัน แหล่งสัญญาณต่างกัน

Synthetic test ที่ fail จะ trigger monitor ประเภท synthetics alert — และ synthetics alert monitor ใช้กลไก threshold, notification และ escalation แบบเดียวกับที่สอนไปแล้วก่อนหน้าใน module นี้เป๊ะ critical/warning threshold, @-mention, escalation_message และ Downtime สำหรับ maintenance ที่วางแผนไว้ล่วงหน้า ทำงานเหมือนกันทุกอย่าง สิ่งที่ต่างมีแค่ input ที่ป้อนเข้า monitor เท่านั้น

{
  "type": "synthetics alert",
  "query": "\"synthetics\" for test_public_id in (\"abc-def-ghi\") \"failure\" over \"5m\" last \"3\" check greater than 2",
  "options": {
    "thresholds": {
      "critical": 2,
      "warning": 1
    }
  },
  "message": "@slack-checkout-oncall @pagerduty-checkout-critical Checkout health check is failing from multiple locations.",
  "escalation_message": "@pagerduty-checkout-escalation Still failing, escalating."
}

ไม่มีอะไรในกลไก alerting เปลี่ยนไปเลยตรงนี้ ยังเป็น shape ของ critical/warning threshold เดียวกับบทที่ 1 การ route ด้วย @-mention และพฤติกรรม re-notify ของ escalation_message เดียวกับบทที่ 2 และความสามารถ mute ด้วย Downtime ตอน maintenance ที่วางแผนไว้ก็เหมือนกันทุกอย่าง สิ่งที่ต่างมีแค่แหล่งสัญญาณ แทนที่จะเป็น metric query หรือ log search input กลายเป็น “scripted check นี้ผ่านหรือ fail จาก location พวกนี้”

flowchart LR
  Loc1[Location: ap-southeast-1] --> Test[Synthetic test: API or Browser]
  Loc2[Location: eu-west-1] --> Test
  Test -->|pass or fail per run| History[Test result history]
  History --> Mon[synthetics alert monitor]
  Mon -->|critical/warning thresholds| Notify[Same notification/escalation pipeline as metric and composite monitors]

From Synthetic test run to alert