ตั้ง Scrape Interval และ Evaluation Interval ใน Prometheus

ช่วง scrape กำหนดความถี่ในการเก็บ metric ส่วน evaluation กำหนดความถี่ในการประเมิน rule เหมาะกับการตั้งค่าระบบเฝ้าระวังให้สอดคล้องกับความเร็วของปัญหาที่ต้องตรวจจับ บทความนี้สรุปแนวคิดจากเอกสารทางการของ Prometheus และจุดที่ควรตรวจเมื่อนำไปใช้จริง

ภาพรวม

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

หัวข้อนี้ตอบโจทย์เฉพาะเรื่อง: ช่วง scrape กำหนดความถี่ในการเก็บ metric ส่วน evaluation กำหนดความถี่ในการประเมิน rule จึงควรเริ่มจากปัญหาที่ต้องแก้และผลลัพธ์ที่คาดหวัง ไม่ใช่เพียงเปิดฟีเจอร์เพราะมีอยู่ในเครื่องมือ

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

ช่วงที่สั้นให้รายละเอียดเพิ่มแต่เพิ่มจำนวน sample และภาระเครือข่ายกับที่เก็บข้อมูล

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

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

เหมาะกับการตั้งค่าระบบเฝ้าระวังให้สอดคล้องกับความเร็วของปัญหาที่ต้องตรวจจับ

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

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

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

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

ข้อควรระวัง

ช่วงยาวเกินไปอาจพลาดเหตุการณ์สั้น ๆ ส่วนช่วงสั้นเกินไปอาจแพงโดยไม่เพิ่มประโยชน์

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

สรุป

ช่วง scrape กำหนดความถี่ในการเก็บ metric ส่วน evaluation กำหนดความถี่ในการประเมิน rule เหมาะกับการตั้งค่าระบบเฝ้าระวังให้สอดคล้องกับความเร็วของปัญหาที่ต้องตรวจจับ ก่อนนำไปใช้กับงานหลัก ควรตรวจผลตามขั้นตอนข้างต้นและทบทวนข้อจำกัดของระบบที่มีอยู่

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