เมื่อระบบ monitoring ที่ใช้ Prometheus เริ่มมีปัญหา เช่น metrics บางชุดหายไปจากกราฟ, dashboard ใช้เวลาโหลดนาน, query ที่เคยเร็วกลับช้าผิดปกติ หรือเก็บข้อมูลย้อนหลังไม่ได้ — ปัญหาเหล่านี้ส่วนใหญ่สาเหตุซ้ำกันและแก้ได้ด้วยการตรวจสอบอย่างเป็นระบบ การรู้ว่าจุดไหนควรดูก่อนและเครื่องมือใดใช้ได้เมื่อไหร่ จะ
คำว่า Monitoring และ Observability มักถูกใช้สลับกันในหลายทีม แต่ในทางปฏิบัติแล้วสองแนวคิดนี้ไม่ใช่สิ่งเดียวกัน Monitoring เน้นตอบคำถามที่ถูกคาดเดาไว้ล่วงหน้า เช่น "CPU เกิน 80% ไหม" หรือ "API latency เกิน 500ms หรือเปล่า" ในขณะที่ Observability มุ่งให้เราสามารถตั้งคำถามใหม่ที่ไม่เคยคิดไว้และหาคำตอบจ
ปัญหาที่ทีม DevOps เจอบ่อยที่สุดไม่ใช่ "Metrics ไม่พอ" แต่เป็น "Metrics เยอะเกินจนไม่รู้จะดูอะไร" หรือในอีกมุมคือ เก็บทุกอย่างแต่ไม่มี Metric ไหนบอกได้ว่า "ระบบกำลังมีปัญหาหรือเปล่า" การเลือก Metrics ที่ถูกต้องตั้งแต่ต้นจึงเป็นเรื่องสำคัญ เพราะทุก Metric ที่เก็บต้องเสียค่า storage, ค่า ingestion, แล
การจะรู้ว่าแอปพลิเคชันทำงานดีหรือไม่ เพียงแค่เช็คว่า process ยังรันอยู่ไม่พอ เพราะแอปอาจรันได้แต่ตอบช้า มี error เยอะ หรือใช้ทรัพยากรเกินงบ การใส่ instrumentation — การเพิ่มโค้ดเก็บ metrics จากภายในแอป — คือวิธีที่ทำให้ทีมเห็นสิ่งที่เกิดขึ้นจริงในเชิงตัวเลข ไม่ใช่แค่การเดา บทความนี้อธิบายแนวคิดของ a
เมื่อระบบย้ายไปอยู่บน Kubernetes การดูแค่ CPU หรือ Memory ระดับ Node ไม่เพียงพออีกต่อไป — สิ่งที่ทีม SRE ต้องการคือภาพของ Object ทุกประเภทภายใน Cluster ไม่ว่าจะเป็น Pod, Deployment, StatefulSet, Job, หรือ PersistentVolumeClaim และสถานะของมัน ณ เวลานั้น ๆ ซึ่งข้อมูลเหล่านี้ไม่ได้อยู่ใน cAdvisor หรือ
ข้อจำกัดใหญ่ของ Prometheus คือ TSDB ฝั่ง local เก็บข้อมูลได้แค่ระยะสั้น — ค่า default retention อยู่ที่ 15 วัน และถ้าดันขึ้นถึง 6 เดือนหรือ 1 ปี ดิสก์ของ server จะเต็มอย่างรวดเร็ว นอกจากนี้การ query ข้อมูลข้าม Prometheus หลายตัวก็ทำไม่ได้โดยตรง เมื่อองค์กรต้องการเก็บ metrics ไว้ย้อนหลังหลายปีเพื่อ c
เมื่อ Prometheus ต้องประมวลผลคำสั่งที่ซับซ้อนหรือรวมข้อมูลจากเมตริกจำนวนมากซ้ำ ๆ ใน Dashboard และ Alert การเรียก PromQL แบบสดทุกครั้งจะเปลือง CPU และทำให้ Grafana ค่อย ๆ ช้าลงอย่างเห็นได้ชัด บทความนี้จะอธิบาย Recording Rules — กลไกการ pre-compute เมตริกเพื่อให้ query ที่มีต้นทุนสูงถูกคำนวณล่วงหน้าแล
PromQL (Prometheus Query Language) เป็นหัวใจของการใช้ Prometheus อย่างมีประสิทธิภาพ — ความสามารถในการเขียน query ที่ตรงจุดและมีประสิทธิภาพจะเปลี่ยนกองข้อมูล metric จำนวนมหาศาลให้กลายเป็น insight ที่ใช้ตัดสินใจได้ บทความนี้จะพาทำความเข้าใจ PromQL ตั้งแต่พื้นฐานของ data model, ประเภทข้อมูลที่รองรับ, s
Node Exporter เป็น exporter สำคัญของ Prometheus ที่ใช้เก็บ metric ระดับระบบปฏิบัติการ Linux/Unix เช่น CPU, Memory, Disk, Network, File system และ systemd service — เป็น exporter ตัวแรกที่ทุกคนต้องติดตั้งเมื่อเริ่มวาง monitoring stack เพราะครอบคลุม baseline metric ของ server ทั้งหมด บทความนี้จะอธิบาย
Prometheus Exporter คือตัวกลางที่แปลง metrics จากแอปพลิเคชันหรือระบบที่ไม่ได้รองรับ Prometheus โดยตรงให้กลายเป็นรูปแบบ text-based ที่ Prometheus อ่านได้ ระบบ exporter เป็นจุดสำคัญของ ecosystem เพราะทำให้ Prometheus สามารถ monitor อะไรก็ได้ ตั้งแต่ MySQL, Redis, Nginx ไปจนถึง router และ IoT device บท
