📡 Obs · Zero→Hero
หน้าแรก/📈 2 · Metrics/Grafana Dashboards
📖 บทเรียน⏱ ~12 นาที

Grafana Dashboards

Prometheus เก็บข้อมูลและมี UI ไว้เทส query แต่ dashboard จริงใช้ Grafana — เครื่องมือทำ dashboard ที่เป็นมาตรฐานของวงการ (ต่อกับได้ทั้ง Prometheus, Elasticsearch/Loki, และอีกเป็นร้อย data source)

โมเดลความคิดของ Grafana

Data Source  →  Dashboard  →  Panel  →  Query (PromQL)  →  Visualization
(Prometheus)     (หนึ่งหน้า)   (หนึ่งกราฟ)   (ถามข้อมูล)      (เส้น/เกจ/ตาราง)
  • Data source — แหล่งข้อมูล เช่น Prometheus (ตั้งค่า URL http://prometheus:9090)
  • Dashboard — หนึ่งหน้าจอ ประกอบด้วยหลาย panel
  • Panel — หนึ่งกราฟ/วิดเจ็ต มี query + วิธีแสดงผล
  • Query — PromQL ที่ panel นั้นถาม (จากบทที่ 21)

ชนิด panel ที่ใช้บ่อย

Panel เหมาะกับ ตัวอย่าง
Time series metric ตามเวลา (ค่า default) request rate, latency
Stat ตัวเลขเด่นตัวเดียว error rate ตอนนี้, uptime
Gauge ค่าเทียบ threshold CPU %, budget เหลือ
Bar gauge เทียบหลายรายการ latency แต่ละ endpoint
Table ข้อมูลเป็นแถว target ที่ down, top errors
Heatmap histogram ตามเวลา การกระจายของ latency

Variables — dashboard เดียวใช้กับทุก service

ความสามารถที่ทำให้ Grafana ทรงพลัง: template variable ทำให้ dashboard หนึ่งอันเปลี่ยน service/instance ได้จาก dropdown ไม่ต้องสร้างซ้ำ

สร้างตัวแปร $service จาก query:
  label_values(http_requests_total, service)

แล้วใช้ในทุก panel:
  sum(rate(http_requests_total{service="$service"}[5m]))

นี่คือวิธีทำ "RED dashboard template" จากบทที่ 11 ให้เป็นจริง — dashboard เดียวมี dropdown $service เลือกดู service ไหนก็ได้ ทุก service หน้าตาเหมือนกัน ทีมอ่านง่าย ไม่ต้องดูแล dashboard เป็นร้อยอัน

หลักการออกแบบ dashboard ที่ "ดูรู้เรื่อง"

dashboard ที่ดีไม่ใช่ dashboard ที่มีกราฟเยอะสุด แต่คือที่ ตอบคำถามได้เร็วสุด:

เรียงจากบนลงล่างตามลำดับการ debug: บนสุด = signal ที่ผู้ใช้เห็น (RED: rate/errors/latency), กลาง = ทรัพยากร (USE: CPU/mem/pool), ล่าง = รายละเอียดเจาะลึก — เวลามีปัญหา ตาจะกวาดจากบนลงล่างตามธรรมชาติ

หลักปฏิบัติ:

  • จัดกลุ่มด้วย row — RED อยู่ row บน, USE อยู่ row ล่าง
  • ตั้งชื่อ + หน่วยให้ชัด — Grafana ตั้ง unit ได้ (ms, %, req/s) ใช้ให้ถูก
  • ใส่ threshold สี — เขียว/เหลือง/แดง ให้เห็นปัญหาด้วยหางตา
  • อย่ายัดเกิน ~9 panel ต่อหน้า — เยอะไปตาลาย หา signal ไม่เจอ
  • ใส่ช่วงเวลาให้เหมาะ — dashboard incident ดู 1-6 ชม., dashboard capacity ดูเป็นสัปดาห์

ระวัง "dashboard สวยแต่โกหก" — เช่นตั้งแกน Y ไม่เริ่มที่ 0 ทำให้ความต่างดูรุนแรงเกินจริง, หรือใช้ค่าเฉลี่ยแทน percentile (จำบทที่ 10) dashboard ที่ทำให้เข้าใจผิดอันตรายกว่าไม่มี dashboard

Provisioning — dashboard as code

อย่าคลิกสร้าง dashboard ด้วยมือแล้วจบ — Grafana เก็บ dashboard เป็น JSON ที่ commit ลง git ได้ และตั้งค่า data source/dashboard อัตโนมัติผ่านไฟล์ provisioning (เราจะใช้ใน lab):

# grafana/provisioning/datasources/prometheus.yml
apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

Dashboard as code ทำให้ dashboard ถูก version control, review, และ reproduce ได้ — สร้าง stack ใหม่ก็ได้ dashboard ครบทันที ไม่ต้องนั่งคลิกใหม่ ทีมมืออาชีพทำแบบนี้

Alerting ใน Grafana vs Prometheus

Grafana ก็ตั้ง alert ได้ (Grafana Alerting) ทับกับ Prometheus + Alertmanager — เลือกยังไง?

  • Prometheus alert rules + Alertmanager → นิยมในสาย cloud-native, alert-as-code, มี burn-rate ครบ (เราใช้แนวนี้ใน lab-metrics-02)
  • Grafana Alerting → สะดวกถ้าดึงหลาย data source มารวม, ตั้งผ่าน UI ง่าย

หลักการ alert (symptom-based, ไม่ทำ alert fatigue จากบทที่ 14) ใช้เหมือนกันไม่ว่าจะตั้งที่ไหน

สรุป

  • Grafana = หน้าจอ, Prometheus = คลังข้อมูล — โครงสร้าง Data source → Dashboard → Panel → Query
  • ใช้ template variables ($service) ทำ RED dashboard เดียวใช้ได้ทุก service
  • ออกแบบให้เรียง RED บน → USE ล่าง ตามลำดับการ debug, ≤9 panel/หน้า
  • ระวัง dashboard ที่ทำให้เข้าใจผิด (แกนไม่เริ่ม 0, ใช้ average)
  • ทำ dashboard as code (JSON + provisioning) commit ลง git

พอแล้วสำหรับทฤษฎี metrics — ได้เวลาลงมือ! ไป Lab: Prometheus + Grafana + node_exporter กัน