จัดการ Datadog เป็น Code ด้วย Terraform

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

Terraform Datadog provider ตัวทางการ ทำให้คุณ define monitor, dashboard และ SLO เป็น code ที่ versioned และ review ได้ แทนที่จะคลิกประกอบเองทีละ environment ใน UI

ทำไมต้องจัดการ Datadog เป็น code

คลิกประกอบ monitor ใน UI ครั้งแรกก็เร็วดี ปัญหาจะโผล่มาตอนครั้งที่สอง — คุณต้องการ monitor ตัวเดียวกันใน staging, dashboard ตัวเดียวกันใน region ใหม่ หรือต้องรู้ให้ได้ว่า threshold ที่เปลี่ยนไปเมื่อเดือนก่อนคืออะไรและทำไม config ที่ประกอบผ่าน UI ไม่มี diff ไม่มีขั้นตอน review และไม่มี single source of truth — สองคนอาจเข้าใจ threshold ของ monitor ไม่ตรงกันแบบเงียบ ๆ แล้วไม่มีอะไรจับได้เลย

การจัดการ monitor, dashboard และ SLO ผ่าน Terraform Datadog provider เปลี่ยนทุกอย่างนี้ให้เป็น code change — config อยู่ใน repository, ถูก review ผ่าน pull request เหมือน change อื่น ๆ ที่ลง production และ module เดียวกันนำไป instantiate ซ้ำได้ทั้ง prod, staging และทุก service ใหม่ที่เพิ่มเข้ามา แค่เปลี่ยน variable แทนที่จะคลิก wizard ใหม่ทุกครั้ง

resource `datadog_monitor` ตัวจริง

นี่คือ metric alert monitor ที่เขียนเป็น Terraform

resource "datadog_monitor" "high_cpu" {
  name    = "High CPU on checkout-service"
  type    = "metric alert"
  message = "CPU is high on checkout-service. Notify: @slack-sre-alerts"

  query = "avg(last_5m):avg:system.cpu.user{service:checkout-service} by {host} > 85"

  monitor_thresholds {
    warning  = 70
    critical = 85
  }

  tags = ["service:checkout-service", "team:checkout"]
}

type — metric alert เป็นหนึ่งใน monitor type หลายแบบ (ตัวอื่นมี log alert, apm alert และ cost alert ที่จะเจอในบทถัดไป)
message — เนื้อหาที่แจ้งเตือน handle @slack-sre-alerts เป็น notification target ของ Datadog resolve เหมือนกับที่พิมพ์เข้าไปใน message box ของ UI ทุกอย่าง
query — เงื่อนไข alert จริง ๆ ประเมินเป็น avg(last_5m):avg:system.cpu.user{service:checkout-service} by {host} > 85
monitor_thresholds — warning กับ critical map ตรงกับ threshold slider ที่ปกติต้องลากเองใน UI
tags — tag ปกติของ Datadog ที่ติดกับตัว monitor เอง ใช้ filter หน้า Manage Monitors และ route ผ่าน Service Catalog ownership ได้

ข้อควรระวังสำคัญ: string query ใน resource datadog_monitor ไม่ใช่ syntax เดียวกับที่พิมพ์ใน monitor query builder ของ UI Datadog UI builder เป็น widget ที่ช่วยประกอบ query ให้ทีละขั้น แต่ field query ใน Terraform คือ API query syntax ดิบ ๆ ต้องเขียนเองให้ถูกต้องตั้งแต่รอบแรก โดย default terraform plan จะส่ง query นี้ไปที่ API ของ Datadog เพื่อ validate ดังนั้น query ที่ผิดรูปแบบจะ fail ตั้งแต่ตอน plan ไม่ใช่ไปสร้าง monitor พังแบบเงียบ ๆ ถ้าจำเป็นต้องข้าม check นี้จริง ๆ — เช่น อ้างถึง metric ที่ยังไม่มีใน environment นี้ — ตั้ง validate = false บน resource ได้ แต่นั่นคือการแลก safety net ทิ้งไป ควรเป็นข้อยกเว้น ไม่ใช่ default

dashboard เป็น code: layout `ordered` กับ `free`

บทเรียน dashboard จากโมดูล Infrastructure & Metrics คุยเรื่อง named query, formula และ template variable ในมุมของ UI widget model เดียวกันนี้โผล่มาใน Terraform ผ่าน datadog_dashboard_v2 และตัวเลือกเพิ่มเติมที่ต้องตัดสินใจตอนเขียน code คือ layout_type

ด้วย layout_type = "ordered" widget แต่ละตัวจะเรียงซ้อนบนลงล่างตามลำดับที่ declare ไว้ — ตัวเลือกที่ง่ายที่สุด และเป็น default ที่ดี

resource "datadog_dashboard_v2" "checkout_overview" {
  title       = "Checkout Service Overview"
  layout_type = "ordered"

  widget {
    timeseries_definition {
      request {
        query {
          name        = "query1"
          data_source = "metrics"
          query       = "avg:system.cpu.user{service:checkout-service} by {host}"
        }
        display_type = "line"
      }
    }
  }
}

ด้วย layout_type = "free" widget ทุกตัวต้องมี block widget_layout ของตัวเอง ให้ตำแหน่งแบบ pixel-grid ที่แน่นอนด้วย x, y, width และ height

resource "datadog_dashboard_v2" "checkout_overview_free" {
  title       = "Checkout Service Overview (free layout)"
  layout_type = "free"

  widget {
    timeseries_definition {
      request {
        query {
          name        = "query1"
          data_source = "metrics"
          query       = "avg:system.cpu.user{service:checkout-service} by {host}"
        }
        display_type = "line"
      }
    }
    widget_layout {
      x      = 0
      y      = 0
      width  = 4
      height = 2
    }
  }
}

ordered เป็น default ที่เหมาะกับ dashboard operational ส่วนใหญ่ — ไม่ค่อยต้องมาสู้กับตำแหน่ง pixel สำหรับ dashboard ที่ส่วนใหญ่ scroll ดูบนลงล่างอยู่แล้ว free คุ้มค่าตอนทำ dashboard ติดจอ TV-wall หรือ layout ที่ตั้งใจ design ให้ widget อยู่ตำแหน่งสัมพัทธ์กันแบบเจาะจง

flowchart LR
  A[Write datadog_monitor / datadog_dashboard_v2 in HCL] --> B[terraform plan]
  B --> C{Query validation}
  C -->|valid, or validate = false| D[Pull request review]
  C -->|invalid| E[Plan fails: fix query]
  D --> F[terraform apply]
  F --> G[Monitor / Dashboard / SLO created in Datadog]
  G --> H[Reused across prod, staging, new services via variables]

From HCL to live Datadog resources

จัดการ Datadog เป็น Code ด้วย Terraform

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

ทำไมต้องจัดการ Datadog เป็น code

resource datadog_monitor ตัวจริง

dashboard เป็น code: layout ordered กับ free

resource `datadog_monitor` ตัวจริง

dashboard เป็น code: layout `ordered` กับ `free`