Recording Rules ลดภาระคิวรี Dashboard ใน Prometheus

Recording rules บันทึกผลลัพธ์ของ PromQL เป็น time series ใหม่ตามรอบ เหมาะกับการ aggregate ข้อมูลจำนวนมากที่หลายหน้าจอเรียกซ้ำ บทความนี้สรุปแนวคิดจากเอกสารทางการของ Prometheus และจุดที่ควรตรวจเมื่อนำไปใช้จริง

ภาพรวม

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

หัวข้อนี้ตอบโจทย์เฉพาะเรื่อง: Recording rules บันทึกผลลัพธ์ของ PromQL เป็น time series ใหม่ตามรอบ จึงควรเริ่มจากปัญหาที่ต้องแก้และผลลัพธ์ที่คาดหวัง ไม่ใช่เพียงเปิดฟีเจอร์เพราะมีอยู่ในเครื่องมือ

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

คิวรีที่คำนวณซ้ำบ่อยจึงถูกเตรียมไว้ล่วงหน้าและใช้ร่วมกันใน dashboard หรือ alert

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

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

เหมาะกับการ aggregate ข้อมูลจำนวนมากที่หลายหน้าจอเรียกซ้ำ

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

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

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

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

ข้อควรระวัง

ระวังชื่อ metric ใหม่และจำนวน series ที่สร้างเพิ่ม เพราะ rule เองก็ใช้ทรัพยากร

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

สรุป

Recording rules บันทึกผลลัพธ์ของ PromQL เป็น time series ใหม่ตามรอบ เหมาะกับการ aggregate ข้อมูลจำนวนมากที่หลายหน้าจอเรียกซ้ำ ก่อนนำไปใช้กับงานหลัก ควรตรวจผลตามขั้นตอนข้างต้นและทบทวนข้อจำกัดของระบบที่มีอยู่

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