Service Discovery ของ Prometheus ตามหา Target อัตโนมัติ

service discovery เติมรายการ target จากระบบภายนอกแทนการเขียน IP ด้วยมือ เหมาะกับ Kubernetes หรือระบบที่ instance ถูกสร้างและลบบ่อย บทความนี้สรุปแนวคิดจากเอกสารทางการของ Prometheus และจุดที่ควรตรวจเมื่อนำไปใช้จริง

ภาพรวม

Prometheus เก็บ metric เป็น time series จาก target ตามรอบ ความหมายของชื่อ metric, label และช่วงเวลาคิวรีมีผลต่อความถูกต้องของกราฟและต้นทุนเก็บข้อมูล

หัวข้อนี้ตอบโจทย์เฉพาะเรื่อง: service discovery เติมรายการ target จากระบบภายนอกแทนการเขียน IP ด้วยมือ จึงควรเริ่มจากปัญหาที่ต้องแก้และผลลัพธ์ที่คาดหวัง ไม่ใช่เพียงเปิดฟีเจอร์เพราะมีอยู่ในเครื่องมือ

หลักการทำงาน

Prometheus อ่านข้อมูลแหล่งต่าง ๆ แล้วใช้ relabeling เลือกและปรับ label ของ target ก่อน scrape

ให้ตรวจทั้งสถานะที่เครื่องมือรายงานและผลลัพธ์ปลายทางที่ผู้ใช้หรือระบบอื่นได้รับ หากสองส่วนไม่ตรงกัน ควรกลับไปตรวจค่าตั้งต้นและขอบเขตที่ฟีเจอร์นี้รับผิดชอบก่อนเปลี่ยนค่าเพิ่มเติม

เหมาะกับงานแบบไหน

เหมาะกับ Kubernetes หรือระบบที่ instance ถูกสร้างและลบบ่อย

ก่อนทดลอง ให้ระบุสิ่งที่จะใช้วัดผล เช่น เวลาตอบสนอง ความพร้อมใช้งาน ความถูกต้องของข้อมูล หรือภาระการดูแล แล้วเทียบกับสภาพเดิม วิธีนี้ช่วยให้รู้ว่าฟีเจอร์แก้ปัญหาจริงหรือย้ายภาระไปอีกจุดหนึ่ง

ขั้นตอนนำไปใช้

1. กำหนดคำถามที่ metric หรือ alert ต้องตอบให้ชัด
2. ตรวจผลคิวรีกับช่วงเวลาหลายขนาดและกรณี target หาย
3. ติดตามจำนวน time series, เวลา query และความถี่ alert

เริ่มจากขอบเขตเล็กและเก็บผลทดสอบไว้กับการเปลี่ยนแปลง หากจะใช้ใน production ให้กำหนดผู้ติดตามผลและเงื่อนไขที่จะหยุดการขยายการใช้งาน

ข้อควรระวัง

ตรวจ relabeling อย่างละเอียด เพราะกฎที่ผิดอาจทำให้ target หายหรือสร้าง label มากเกิน

แปลงข้อควรระวังนี้เป็นรายการตรวจในการทบทวนงาน เพราะปัญหาจากค่าตั้งต้นอาจไม่แสดงทันทีในสภาพแวดล้อมทดสอบ

สรุป

service discovery เติมรายการ target จากระบบภายนอกแทนการเขียน IP ด้วยมือ เหมาะกับ Kubernetes หรือระบบที่ instance ถูกสร้างและลบบ่อย ก่อนนำไปใช้กับงานหลัก ควรตรวจผลตามขั้นตอนข้างต้นและทบทวนข้อจำกัดของระบบที่มีอยู่

อ่านเพิ่มเติม: เอกสารทางการของ Prometheus