ควบคุม Label Cardinality ใน Prometheus ก่อนข้อมูลระเบิด

จำนวนชุดค่าของ label เป็นตัวกำหนดจำนวน time series ที่ Prometheus ต้องเก็บ เหมาะกับทีมที่เริ่มวางมาตรฐาน instrumentation และต้องควบคุม RAM กับพื้นที่เก็บข้อมูล บทความนี้สรุปแนวคิดจากเอกสารทางการของ Prometheus และจุดที่ควรตรวจเมื่อนำไปใช้จริง

ภาพรวม

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

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

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

label ที่มีค่ามาก เช่น user ID หรือ request ID ทำให้สร้าง series ใหม่จำนวนมหาศาลแม้ metric มีชื่อเดียว

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

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

เหมาะกับทีมที่เริ่มวางมาตรฐาน instrumentation และต้องควบคุม RAM กับพื้นที่เก็บข้อมูล

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

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

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

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

ข้อควรระวัง

อย่าใช้ค่าที่ไม่จำกัดจำนวนเป็น label ให้เก็บรายละเอียดระดับคำขอใน log หรือ trace

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

สรุป

จำนวนชุดค่าของ label เป็นตัวกำหนดจำนวน time series ที่ Prometheus ต้องเก็บ เหมาะกับทีมที่เริ่มวางมาตรฐาน instrumentation และต้องควบคุม RAM กับพื้นที่เก็บข้อมูล ก่อนนำไปใช้กับงานหลัก ควรตรวจผลตามขั้นตอนข้างต้นและทบทวนข้อจำกัดของระบบที่มีอยู่

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