การมีระบบ Monitoring ที่ดีไม่เพียงพอหากไม่มี On-Call Alerting ที่สามารถแจ้งเตือนทีมได้ทันเวลาเมื่อเกิดปัญหาในเวลากลางคืนหรือวันหยุด การตั้ง Alertmanager ร่วมกับ PagerDuty ช่วยให้ทีม SRE/DevOps สามารถ rotate เวร รับ alert ผ่านโทรศัพท์ และจัดการ incident ได้อย่างเป็นระบบ ลด MTTR (Mean Time To Recovery
การรัน Kubernetes cluster ใน production โดยไม่มี monitoring ที่เหมาะสมเปรียบเหมือนการขับรถโดยปิดตา เราไม่เห็น pod ที่กำลัง crash loop ไม่รู้ว่า node ไหน CPU แตะ 90% และไม่ทราบว่า HPA ทำงานถูกต้องหรือเปล่า ผลคือเมื่อเกิดปัญหาผู้ใช้งานจะเจอ error ก่อนทีม DevOps รับรู้ การติดตั้ง Prometheus กับ Grafana
ในระบบ production ยุคปัจจุบัน การมีแค่ metrics ไม่เพียงพอต่อการแก้ปัญหาซับซ้อน ทีม DevOps และ SRE จึงต้องรวม 3 เสาหลักของ observability เข้าด้วยกัน นั่นคือ metrics, logs และ traces เพื่อให้มองเห็นระบบแบบ 360 องศา เมื่อเกิดปัญหาก็สามารถไล่หาสาเหตุได้ตั้งแต่ตัวเลขภาพรวม ลงไปถึง log บรรทัดที่ error และ
เมื่อระบบ monitoring ที่ใช้ Prometheus เริ่มมีปัญหา เช่น metrics บางชุดหายไปจากกราฟ, dashboard ใช้เวลาโหลดนาน, query ที่เคยเร็วกลับช้าผิดปกติ หรือเก็บข้อมูลย้อนหลังไม่ได้ — ปัญหาเหล่านี้ส่วนใหญ่สาเหตุซ้ำกันและแก้ได้ด้วยการตรวจสอบอย่างเป็นระบบ การรู้ว่าจุดไหนควรดูก่อนและเครื่องมือใดใช้ได้เมื่อไหร่ จะ
การเลือก Prometheus client library สำหรับภาษาที่ใช้งานเป็นการตัดสินใจที่ส่งผลต่อ reliability, memory footprint และความสะดวกในการ maintain ระยะยาว แต่ละ library มีปรัชญาและข้อจำกัดเฉพาะ — เช่น Python รองรับ multi-process mode ที่พิเศษ, Go มี CounterVec ที่ต้อง pre-register, Node.js ใช้ async collecti
การติดตาม MySQL Server ให้ทำงานได้อย่างมีประสิทธิภาพต้องอาศัย Metrics ที่ครบถ้วนและต่อเนื่อง ทั้ง Query Performance, Connection Usage, InnoDB Buffer Pool, Replication Lag และอื่น ๆ อีกมาก การเก็บข้อมูลเหล่านี้ด้วยตนเองจากคำสั่ง SHOW STATUS หรือ information_schema อาจใช้ได้กับการ debug เฉพาะหน้า แต่ไ
Alertmanager เป็นส่วนประกอบสำคัญของ Prometheus ecosystem ที่ทำหน้าที่รับสัญญาณจาก Prometheus server แล้วจัดการตั้งแต่การ deduplicate, grouping, silencing, inhibition ไปจนถึงการ route ส่งต่อยังช่องทางปลายทางเช่น email, Slack, PagerDuty หรือ webhook การใช้งานอย่างถูกวิธีจะช่วยลด noise และทำให้ทีม onca
ข้อจำกัดใหญ่ของ Prometheus คือ TSDB ฝั่ง local เก็บข้อมูลได้แค่ระยะสั้น — ค่า default retention อยู่ที่ 15 วัน และถ้าดันขึ้นถึง 6 เดือนหรือ 1 ปี ดิสก์ของ server จะเต็มอย่างรวดเร็ว นอกจากนี้การ query ข้อมูลข้าม Prometheus หลายตัวก็ทำไม่ได้โดยตรง เมื่อองค์กรต้องการเก็บ metrics ไว้ย้อนหลังหลายปีเพื่อ c
Prometheus รุ่นมาตรฐานถูกออกแบบให้ทำงานเป็น single node — เรียบง่าย เสถียร และดูแลง่าย แต่เมื่อระบบเริ่มใหญ่ขึ้น ทีมงานต้องการความพร้อมใช้งานระดับสูงเผื่อเซิร์ฟเวอร์ล่ม หรือมี monitoring หลาย data center ที่ต้องรวมข้อมูลขึ้นสู่ศูนย์กลาง ระบบนี้จึงมีแนวทาง High Availability (HA) และ Federation ให้เลื
เมื่อ Prometheus ต้องประมวลผลคำสั่งที่ซับซ้อนหรือรวมข้อมูลจากเมตริกจำนวนมากซ้ำ ๆ ใน Dashboard และ Alert การเรียก PromQL แบบสดทุกครั้งจะเปลือง CPU และทำให้ Grafana ค่อย ๆ ช้าลงอย่างเห็นได้ชัด บทความนี้จะอธิบาย Recording Rules — กลไกการ pre-compute เมตริกเพื่อให้ query ที่มีต้นทุนสูงถูกคำนวณล่วงหน้าแล
