Troubleshoot Grafana: Dashboard ไม่แสดง Data, Alert ไม่ทำงาน

Categories

Grafana เป็น visualization layer ที่ทีม DevOps ใช้ดู metrics จาก Prometheus, Loki, Elasticsearch และ data source อื่น ๆ เมื่อ dashboard ไม่แสดงข้อมูลตามที่คาดหรือ alert ไม่ถูกส่งออกไป การ troubleshoot ต้องตรวจตั้งแต่ data source, query, panel settings, ไปจนถึง notification policy — บทความนี้รวมวิธีตรวจสอบปัญหาที่พบบ่อยทั้งสองฝั่งแบบเป็นลำดับ

ปัญหาหลักของ Grafana แบ่งเป็น 2 กลุ่มใหญ่ คือ dashboard ไม่แสดง data (panel ว่าง หรือ “No data”) และ alert ที่ไม่ทำงานหรือทำงานผิดพลาด แต่ละกลุ่มมีจุดตรวจเฉพาะที่ต่างกัน

ขั้นตอนที่ 1: ตรวจ Data Source Connection

ปัญหาส่วนใหญ่ของ panel ที่แสดง “No data” หรือ error เกิดจาก data source เชื่อมต่อไม่ได้ ไปที่ Configuration > Data Sources แล้วกด Test ปุ่มด้านล่างของ data source ที่ใช้งาน — ผลลัพธ์ที่เป็น “working” เท่านั้นจึงใช้ได้

  • HTTP URL ผิด (เช่น ลืมใส่ port, typo ใน hostname)
  • Authentication ไม่ถูกต้อง (API token หมดอายุ, basic auth password เปลี่ยน)
  • Network/firewall block ระหว่าง Grafana กับ data source
  • TLS certificate issue (self-signed cert ไม่ได้ tick “Skip TLS Verify”)
  • Data source plugin ยังไม่ได้ install หรือ version ไม่ compatible

ขั้นตอนที่ 2: ใช้ Query Inspector

Query Inspector เป็นเครื่องมือที่สำคัญที่สุดในการ debug panel ที่ไม่แสดงข้อมูล กดที่ title ของ panel > Inspect > Query จะเห็น request ที่ Grafana ส่งไปจริง และ response ที่ได้รับกลับมา

  • Stats tab: ดู query duration, data processing time — ถ้าเกิน 30 วินาที มักจะ timeout
  • Query tab: ดู URL และ body ที่ส่งไปยัง data source — copy ไปรันบน data source โดยตรง เพื่อยืนยันว่า query ถูกต้อง
  • JSON tab: ดู response จริงจาก data source — บางครั้งมี data กลับมาแต่ panel แสดงผลไม่ได้เพราะ format ไม่ตรง
  • Data tab: ดู data frame ที่ Grafana ประมวลผลแล้ว — ถ้าว่างแต่ JSON มี data แปลว่า transformation ผิด

ขั้นตอนที่ 3: ตรวจ Time Range และ Variables

หลาย panel ดูเหมือนไม่มีข้อมูล แต่จริง ๆ คือ time range ที่เลือกอยู่นอกช่วงที่มี data หรือ variable ที่อ้างอิงใน query ไม่มีค่าที่ถูกต้อง:

  • ลองเปลี่ยน time range เป็น “Last 24 hours” หรือ “Last 7 days” เพื่อยืนยันว่ามีข้อมูลจริง
  • ตรวจ dashboard variable — ไปที่ Dashboard settings > Variables เปิดดูค่าปัจจุบัน
  • ใน query ให้ลองแทนตัวแปรด้วยค่าจริง เช่น $instance → server-01:9100 แล้วดูว่ามีข้อมูลหรือไม่
  • ตรวจ timezone ของ dashboard กับ data source — บางครั้ง Grafana อยู่ UTC แต่ data source เก็บเวลาท้องถิ่น ทำให้ดูเหมือนไม่มีข้อมูลในช่วงที่เลือก

ขั้นตอนที่ 4: ตรวจ Panel Type และ Field Mapping

Panel type ที่เลือกต้องตรงกับรูปแบบข้อมูล เช่น Gauge ต้องการข้อมูลเป็น scalar, Time series ต้องการ series ที่มี time column และค่า numeric, Table รับได้หลายรูปแบบ หาก data frame ไม่ตรงกับ panel type ที่ใช้ ให้ใช้ Transformations เปลี่ยนรูปก่อน เช่น Reduce เพื่อลด time series เป็น single value, หรือ Labels to fields เพื่อแปลง Prometheus label เป็น column

ขั้นตอนที่ 5: ตรวจ Server Log

หาก panel แสดง error ที่อ่านยาก ให้ดู log ของ server โดยตรง:

# Docker/Docker Compose
docker logs grafana --tail 100 -f

# Systemd (install แบบ package)
journalctl -u grafana-server -f

# Kubernetes
kubectl logs -f deployment/grafana -n monitoring

# ตำแหน่ง log file (ถ้าเปิด file logging)
/var/log/grafana/grafana.log

ใน log มักจะพบ error แบบ “context deadline exceeded” (query timeout), “connection refused” (data source unreachable), “permission denied” (organization role ไม่พอ) ซึ่งบอกสาเหตุชัดเจนกว่า error ใน UI

Unified Alerting vs Legacy Alerting

ตั้งแต่เวอร์ชัน 8 เป็นต้นมา Grafana มีระบบ Unified Alerting ที่แทน Legacy Alerting ทั้งสองระบบตั้งค่าต่างกัน — ต้องรู้ว่าใช้ระบบใดอยู่ก่อน ไปที่ Configuration > Alerting จะเห็นเมนูย่อย “Alert rules”, “Contact points”, “Notification policies” → เป็น Unified; ถ้าเห็นแค่ “Alert rules” ภายใต้ panel edit mode เท่านั้น → เป็น Legacy

ขั้นตอนที่ 1: ตรวจ Alert Rule State

ไปที่ Alerting > Alert rules แล้วดู state ของแต่ละ rule:

  • Normal — เงื่อนไขยังไม่ถูก trigger (ไม่มี alert ส่ง)
  • Pending — เงื่อนไข trigger แล้วแต่ยังไม่ถึง “for” duration
  • Firing — alert ถูก trigger และจะส่งไปตาม notification policy
  • No data — query ไม่คืนค่า (มักเกิดจาก data source ไม่ตอบ)
  • Error — query มีปัญหา (syntax หรือ data source error)

หาก state เป็น “No data” หรือ “Error” alert จะไม่ถูกส่ง แม้เงื่อนไขควรจะ match ให้ตรวจ query ใน rule ด้วยการกด “Preview alerts” บนหน้า rule edit ซึ่งจะแสดงผลลัพธ์จริงในขณะนั้น

ขั้นตอนที่ 2: ตรวจ Contact Point

Contact point คือ channel ที่ alert จะถูกส่งไป (Slack, Email, PagerDuty, webhook) หากตั้งไว้ผิด alert ที่ firing ก็ไม่ถึงปลายทาง ทดสอบได้โดยใช้ปุ่ม “Test” บน contact point — จะส่ง test notification ออกไปทันที

  • Slack: ตรวจ webhook URL — ต้อง generate ใหม่หาก revoke ไปแล้ว
  • Email: ตรวจ SMTP config ใน grafana.ini ว่าถูกต้อง (host, port, auth)
  • PagerDuty: ตรวจ integration key ว่าตรงกับ service ที่ต้องการ
  • Webhook: ตรวจ URL ของ endpoint และ authentication header

ขั้นตอนที่ 3: ตรวจ Notification Policy

Notification policy เป็น routing tree ที่ตัดสินใจว่า alert ไหนจะส่งไปที่ contact point ไหน ถ้า routing ตั้งไม่ถูก alert จะหายไปที่ default policy หรือส่งผิด channel ไปที่ Alerting > Notification policies แล้วกด “View Tree” — ดูว่า alert ที่ต้องการจะ match กับ policy ไหน

  • Match label ใน policy (เช่น severity=critical, team=platform) ต้องตรงกับ label ของ alert rule
  • ตรวจ “Continue matching” — ถ้าไม่เปิด alert จะหยุดที่ policy แรกที่ match
  • ตรวจ Mute timings — alert ที่อยู่ในช่วง mute จะไม่ถูกส่ง (ดูตาราง silence ประกอบ)

ขั้นตอนที่ 4: ตรวจ Silence

Silence คือการหยุดส่ง alert ชั่วคราว หากมี silence ที่ยัง active อยู่ alert ที่ match กับ label ของ silence นั้นจะไม่ส่ง ไปที่ Alerting > Silences เพื่อดู silence ที่ยัง active และ label matcher ของแต่ละรายการ — ลบหรือ expire รายการที่ไม่ต้องการ

Dashboard โหลดช้าผิดปกติ

  • Panel เยอะเกินไป — แนะนำไม่เกิน 20 panel ต่อ 1 dashboard
  • Query แต่ละ panel ยิง datasource พร้อมกันเมื่อเปิด dashboard — ใช้ “Query options” ตั้ง Relative time ให้สั้นลง
  • ใช้ rate() บน range ยาว เช่น rate(metric[7d]) โหลดข้อมูลมาก — ควรใช้ recording rule แทน
  • Dashboard ที่มี template variable ซับซ้อน ยิง query หลายครั้งต่อการโหลด — ลด variable หรือ cache ด้วย Refresh: On Dashboard Load

Permission / Organization Issue

Grafana รองรับ multi-org และ folder-level permission ผู้ใช้ที่เห็น dashboard ไม่ครบ หรือแก้ไม่ได้ อาจเป็นเพราะ role ต่ำเกินไป (Viewer แทน Editor) หรืออยู่ใน organization ผิด — ตรวจที่ profile icon > Switch organization และตรวจ folder permission ของ dashboard ที่เปิดดู

Memory สูง / Process restart บ่อย

Grafana ใช้ memory เพิ่มตามจำนวน data source query ที่รันพร้อมกัน + size ของ result set ถ้า memory เต็มบ่อย ควรพิจารณา:

# grafana.ini
[dataproxy]
timeout = 30         # ตัดต่อ query ที่ช้าเกิน 30 วินาที
max_conns_per_host = 10

[alerting]
max_attempts = 3
execute_alerts = true

# ถ้า deploy แบบ Docker ให้ limit memory
docker run --memory=2g --memory-swap=2g grafana/grafana

Checklist สำหรับ Troubleshooting

  • Test data source connection — ต้องขึ้น “working”
  • ใช้ Query Inspector ดู request/response ทุกครั้งก่อนไล่หาสาเหตุอื่น
  • ลองเปลี่ยน time range เป็น Last 7 days เพื่อยืนยันว่ามีข้อมูลจริง
  • ตรวจ variable ใน dashboard settings — ค่าต้องไม่ว่าง
  • ดู server log เมื่อ UI ไม่บอก error ชัดเจน
  • สำหรับ alert: ดู state ต้องเป็น Firing ไม่ใช่ No data / Error
  • Test contact point ทุก channel อย่างน้อยเดือนละครั้ง
  • ตรวจ Silence list ก่อนสรุปว่า alert เสีย

สรุป

การ troubleshoot Grafana ต้องรู้ว่าปัญหาอยู่ที่ชั้นไหน — data source, query, panel, หรือ alerting — แล้วใช้เครื่องมือในตัวระบบเช่น Query Inspector และ Alert rule state ตรวจทีละจุด การเข้าใจความต่างระหว่าง Unified Alerting กับ Legacy Alerting ก็สำคัญเพราะหน้าจัดการไม่เหมือนกัน และ notification ไม่ถูกส่งออกไปเมื่อ config ผิดระบบ

การทำ dashboard health check เป็นประจำ เช่น ตรวจ data source ทุก data source, test alert contact point, และ audit silence list จะช่วยลดปัญหา alert หลุดและป้องกันไม่ให้ user เปิด dashboard แล้วเจอ panel ที่ไม่มีข้อมูล