เมื่อรวบรวม Logs จากหลาย ๆ service เข้าสู่ Loki แล้ว ขั้นตอนต่อไปคือการค้นหาและวิเคราะห์ Logs เหล่านั้นเพื่อ debug ปัญหา, ตรวจจับ error หรือทำ alerting ซึ่งจำเป็นต้องใช้ภาษา query ที่ออกแบบมาโดยเฉพาะสำหรับ log data — LogQL คือคำตอบ LogQL (Loki Query Language) คือภาษาค้นหา logs ของ Grafana Loki ที่ได
Promtail เป็น log collection agent ที่ Grafana Labs พัฒนาเพื่อเก็บ log จาก server หรือ container แล้วส่งต่อไปยัง Loki สำหรับจัดเก็บและค้นหา ด้วยโครงสร้างที่เน้น label discovery คล้าย Prometheus แต่ทำงานกับไฟล์ log แทน metric บทความนี้ครอบคลุมวิธีติดตั้ง, การกำหนด scrape target, pipeline แปลง log, re
Loki เป็น log aggregation system ที่ Grafana Labs ออกแบบมาให้ประหยัดต้นทุนและ scale แบบ horizontal ได้ดีกว่าเดิมมาก ต่างจากระบบเก็บ log แบบเก่าที่ index ทุกฟิลด์ Loki เลือก index เฉพาะ label ทำให้ storage footprint เล็กกว่าและ operate ง่ายขึ้น บทความนี้อธิบาย architecture ของระบบ — component ย่อยแต่
การเลือกระบบเก็บและค้น log กลางเป็นหนึ่งในการตัดสินใจที่ส่งผลระยะยาวมากที่สุดในทีม DevOps — ทั้งเรื่อง cost, performance และ learning curve ของทีม ตัวเลือกหลักในตลาดปัจจุบันมีสองค่ายใหญ่: ELK Stack (Elasticsearch + Logstash + Kibana) ที่ครองตลาด centralized logging มานานกว่า 10 ปี และ Loki + Grafana
ข้อจำกัดใหญ่ของ 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 ที่มีต้นทุนสูงถูกคำนวณล่วงหน้าแล
เมื่อเข้าใจ PromQL ระดับพื้นฐานแล้ว ขั้นต่อไปคือการใช้ความสามารถที่ลึกขึ้น เช่น subquery, vector matching (join ข้าม metric), group operator และเทคนิคจัดการ high-cardinality ที่จะเปลี่ยนการเขียน query ธรรมดาให้ตอบโจทย์งานจริงที่ซับซ้อนได้ บทความนี้จะลงรายละเอียดเรื่องเหล่านี้พร้อมตัวอย่างที่ใช้งานได
PromQL (Prometheus Query Language) เป็นหัวใจของการใช้ Prometheus อย่างมีประสิทธิภาพ — ความสามารถในการเขียน query ที่ตรงจุดและมีประสิทธิภาพจะเปลี่ยนกองข้อมูล metric จำนวนมหาศาลให้กลายเป็น insight ที่ใช้ตัดสินใจได้ บทความนี้จะพาทำความเข้าใจ PromQL ตั้งแต่พื้นฐานของ data model, ประเภทข้อมูลที่รองรับ, s
การเขียน Custom Prometheus Exporter เป็นเรื่องจำเป็นเมื่อระบบที่ต้อง monitor ไม่มี exporter สำเร็จรูป หรือเมื่อต้องการเก็บ business metric เฉพาะทาง เช่น จำนวน order ต่อวินาที, latency ของ internal API, หรือสถานะของ job queue — บทความนี้จะลงลึกถึงวิธีเขียน custom exporter ระดับ production ที่เสถียร ป
