Grafana Dashboard Creation: สร้าง Custom Dashboard สำหรับ Metrics

Categories

Grafana เป็นเครื่องมือ visualization ที่นิยมที่สุดในโลก open-source monitoring เพราะรองรับ data source หลายประเภท, มี panel หลากหลายรูปแบบ, และ UI ที่ใช้งานได้ง่าย การสร้าง dashboard ที่ดีช่วยให้ทีมมองเห็นสถานะของระบบได้อย่างรวดเร็วและตัดสินใจได้ตรงประเด็น บทความนี้จะพาไปเรียนรู้วิธีสร้าง custom dashboard ตั้งแต่การเลือก panel, การเขียน query, การตั้ง variable, ไปจนถึง best practices ที่ควรรู้

Dashboard ที่ดีไม่ใช่แค่สวย แต่ต้อง “อ่านง่าย” ช่วยให้ผู้ใช้เข้าใจสิ่งที่เกิดขึ้นในระบบโดยไม่ต้องตีความเพิ่ม บทความนี้เน้นการสร้าง dashboard เชิงปฏิบัติที่ใช้งานได้จริงใน production พร้อมเทคนิคการจัดวาง panel, ใช้ template variable, และการตั้งค่า alert thresholds

องค์ประกอบหลักของ Dashboard

ก่อนเริ่มสร้าง dashboard ควรเข้าใจองค์ประกอบหลักที่ใช้กัน ซึ่งจะช่วยให้ออกแบบ layout ได้เหมาะสมกับข้อมูลแต่ละประเภท

  • Panel — หน่วยแสดงผลย่อย แต่ละ panel แสดงข้อมูลหนึ่งชุดตาม query ที่กำหนด
  • Row — กลุ่มของ panel ที่จัดในแนวนอน ใช้แบ่งเนื้อหา dashboard เป็นหมวด
  • Variable — ตัวแปรที่ใช้ใน query ทำให้ dashboard ตอบโต้ได้ (เลือก environment, namespace, host)
  • Data Source — แหล่งข้อมูล เช่น Prometheus, Loki, MySQL, Elasticsearch
  • Annotation — เครื่องหมายบนกราฟที่แสดง event สำคัญ เช่น deployment, incident
  • Time Range — ช่วงเวลาที่ dashboard แสดง มีทั้ง relative (last 6h) และ absolute

ประเภทของ Panel ที่ใช้บ่อย

Grafana มี panel หลายประเภท แต่ละประเภทเหมาะกับข้อมูลต่างกัน การเลือก panel ที่ตรงกับลักษณะข้อมูลช่วยให้ผู้อ่านเข้าใจได้เร็วขึ้น

  • Time Series — กราฟเส้นที่แสดง metric ตามเวลา เหมาะกับ CPU, Memory, Request rate
  • Stat — แสดงค่าเดียว (single value) ที่เด่น เช่น current uptime, success rate
  • Gauge — แสดงค่าปัจจุบันเทียบกับ threshold เหมาะกับ disk usage, memory utilization
  • Bar Gauge — แสดงหลายค่าในแนวนอนแบบ bar chart เหมาะสำหรับเปรียบเทียบ
  • Table — แสดงข้อมูลแบบตาราง เหมาะกับ list of hosts, logs summary
  • Heatmap — แสดง distribution ของข้อมูลตามเวลา เหมาะกับ latency histogram
  • Pie Chart — แสดงสัดส่วน เหมาะกับ traffic breakdown (ใช้แค่เมื่อจำเป็น)
  • Logs — แสดง log lines จาก Loki หรือ Elasticsearch
  • Text — panel ข้อความที่ใช้เป็น note หรือ markdown คำอธิบาย

1. สร้าง Dashboard ใหม่

เข้าเมนู Dashboards → New → New Dashboard จากนั้นกด “Add visualization” เพื่อเพิ่ม panel แรก เลือก data source ที่ต้องการใช้ (เช่น Prometheus) แล้วเขียน query ในช่อง query editor

2. เขียน Query สำหรับ Time Series

# CPU usage per host
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Memory usage percentage
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# Request rate per service
sum by (service) (rate(http_requests_total[5m]))

# Error rate percentage
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m])) * 100

3. ปรับ Display Options

หลังได้ query ที่ถูกต้อง ให้ปรับ display options ที่ช่อง Panel options ด้านขวา เช่น title, legend, axis label, color scheme ควรตั้ง unit ให้ตรงกับข้อมูล (percent, bytes, seconds) ผู้อ่านจะเข้าใจได้ทันที

4. ตั้ง Threshold

Threshold ช่วยให้ดู dashboard แล้วรู้สถานะทันที ตั้งค่าได้ที่ Thresholds section เช่น warning ที่ 70%, critical ที่ 90% แต่ละ panel สามารถแสดงเส้น threshold บนกราฟและเปลี่ยนสีตามระดับได้

Template Variables — ทำให้ Dashboard ยืดหยุ่น

Template variable เป็นฟีเจอร์ที่ทำให้ dashboard เดียวใช้ได้กับหลายสภาพแวดล้อม ผู้ใช้สามารถเลือก filter ผ่าน dropdown แทนที่จะต้องสร้าง dashboard แยกสำหรับแต่ละ environment

ตัวอย่างการสร้าง Variable

# Variable: environment
Name: environment
Type: Query
Data source: Prometheus
Query: label_values(environment)
Multi-value: false
Include All option: true

# Variable: namespace (depends on environment)
Name: namespace
Type: Query
Data source: Prometheus
Query: label_values(kube_pod_info{environment="$environment"}, namespace)

# Variable: instance (depends on environment + namespace)
Name: instance
Type: Query
Query: label_values(up{environment="$environment", namespace="$namespace"}, instance)
Multi-value: true
Include All option: true

เมื่อสร้าง variable แล้ว ใช้ใน query ผ่าน syntax $variable_name หรือ ${variable_name} ตัวอย่าง query ที่ใช้ variable:

# Query ที่ใช้ variable
sum by (pod) (rate(container_cpu_usage_seconds_total{
  namespace="$namespace",
  pod=~"$pod"
}[5m]))

# การใช้ regex กับ multi-value
up{instance=~"$instance"}

การจัด Layout ที่ดี

Layout ของ dashboard มีผลต่อการใช้งาน ควรจัดให้ข้อมูลสำคัญอยู่บนสุด ผู้อ่านไม่ต้อง scroll เพื่อดู key metric หลักการจัด layout ที่ใช้กันในองค์กรใหญ่ ๆ คือแบบ “RED” และ “USE”

RED Method (สำหรับ Request-driven services)

  • Rate — จำนวน request ต่อวินาที (req/s)
  • Errors — จำนวน error ต่อวินาที หรือ error rate percentage
  • Duration — latency (p50, p95, p99)

USE Method (สำหรับ Resources)

  • Utilization — อัตราการใช้งาน resource (CPU%, Memory%)
  • Saturation — ระดับความเต็มของ queue หรือ buffer
  • Errors — จำนวน error (disk I/O error, network dropped packets)

Transformations — ประมวลผลข้อมูลบน Panel

Grafana มีฟีเจอร์ Transformation ที่ใช้ประมวลผลข้อมูลเพิ่มก่อนแสดงผล เช่น join ข้อมูลจากหลาย query, คำนวณค่า derived, กรอง row แถวที่ไม่ต้องการ transformation ช่วยให้ dashboard แสดงข้อมูลที่มีความหมายได้โดยไม่ต้องเขียน query ซับซ้อน

  • Join by field — รวมหลาย query เป็นตารางเดียวตาม field ที่กำหนด
  • Organize fields — เปลี่ยนลำดับ column, rename, hide field
  • Filter data by values — กรอง row ตามเงื่อนไข value
  • Group by — รวมข้อมูลตาม field พร้อมใช้ aggregate (sum, avg, count)
  • Calculate field — คำนวณ column ใหม่จาก column ที่มี
  • Rename by regex — เปลี่ยนชื่อ field ด้วย regex pattern

Annotations — แสดง Event บน Dashboard

Annotation ช่วยให้เห็นความสัมพันธ์ระหว่าง event กับ metric เช่น กราฟ CPU พุ่งขึ้นตรงกับเวลาที่ deploy หรือ incident ที่เกิด สามารถตั้ง annotation ให้ดึงจาก data source หรือ API ภายนอกได้

# Annotation จาก Prometheus
Name: Deployments
Data source: Prometheus
Query: changes(kube_deployment_status_observed_generation{deployment="api"}[1m]) > 0

# Annotation จาก HTTP API (webhook from CI/CD)
Name: CI Deploy
Data source: Grafana
URL: https://ci.example.com/api/deploys
Headers: Authorization: Bearer TOKEN

Best Practices สำหรับ Dashboard Design

  • สรุปก่อน รายละเอียดทีหลัง — วาง panel ภาพรวม (error rate, uptime) ด้านบน รายละเอียดย่อยไว้ด้านล่าง
  • ใช้สีอย่างมีจุดประสงค์ — สีแดงสำหรับ error/critical, เหลืองสำหรับ warning, เขียวสำหรับ healthy ไม่ใช้สีเพื่อสวยอย่างเดียว
  • ตั้ง title ที่ชัดเจน — panel title ต้องบอกได้ทันทีว่าแสดงอะไร ไม่ใช่แค่ metric name
  • ใช้ description — เพิ่ม description บน panel เพื่ออธิบายว่า metric มีความหมายอย่างไรและ threshold ที่ควรกังวล
  • อย่า panel เยอะเกินไป — dashboard หนึ่งควรมี panel 6-12 panel สำหรับ overview หาก panel เกินไปให้แยก dashboard
  • ใช้ template variable แทนการ duplicate — หลีกเลี่ยงการสร้าง dashboard แยกสำหรับแต่ละ host ใช้ variable ให้เลือกแทน
  • ตั้ง refresh rate ที่เหมาะสม — 5s-30s สำหรับ real-time ops, 1m-5m สำหรับ overview
  • เก็บ version control — export dashboard เป็น JSON และเก็บใน Git เพื่อติดตาม change

Export / Import Dashboard ระหว่าง Environment

Dashboard สามารถ export เป็น JSON เพื่อ sharing หรือ version control ได้ การใช้ data source variable และ ${DS_PROMETHEUS} placeholder ช่วยให้ dashboard portable ไปใช้ที่อื่นได้โดยไม่ต้องแก้ไข

# Export dashboard
# Dashboard settings (gear icon) → JSON Model → Copy to clipboard
# หรือใช้ HTTP API

curl -H "Authorization: Bearer $GRAFANA_TOKEN" \
  http://grafana:3000/api/dashboards/uid/abc123 \
  | jq '.dashboard' > my-dashboard.json

# Import dashboard via API
curl -X POST -H "Authorization: Bearer $GRAFANA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"dashboard": '$(cat my-dashboard.json)', "overwrite": true}' \
  http://grafana:3000/api/dashboards/db

สรุป

การสร้าง dashboard ที่ดีใน Grafana ต้องเข้าใจ panel แต่ละประเภท, ใช้ template variable เพื่อความยืดหยุ่น, จัด layout ตาม methodology (RED/USE) และปรับแต่ง display options ให้เหมาะกับข้อมูล dashboard ที่ดีไม่ใช่แค่สวย แต่ช่วยให้ทีมเข้าใจสถานะระบบและตัดสินใจได้เร็วขึ้นในยามเกิดปัญหา

เมื่อสร้าง dashboard แล้ว อย่าลืม export เก็บเป็น JSON และเก็บใน version control เพื่อให้ทีมสามารถ review, rollback, และ replicate ไปยัง environment อื่นได้ง่าย และควรทำ review dashboard ทุกไตรมาสเพื่อปรับปรุงให้สอดคล้องกับการเปลี่ยนแปลงของระบบ