मेट्रिक्स सिस्टम में high cardinality क्या है, और आप इसे काबू में कैसे रखते हैं?

cardinality किसी मेट्रिक के लिए label के अनोखे मेलों की गिनती है, और हर मेल मेमोरी में रखी एक अलग time series होती है। label में user id, request id, ईमेल पते या कच्चे URL path डालने से लाखों series बन सकती हैं और एक Prometheus इंस्टेंस बैठ सकता है। label सीमित और कम विकल्पों वाले रखें, बदलते path हिस्सों को template बनाएं, प्रति रिक्वेस्ट ब्योरा लॉग या traces में डालें, और relabeling तथा sample cap से सीमाएं लागू करें।

label वैल्यू का हर अनोखा मेल अपनी अलग time series है, अपनी मेमोरी और डिस्क पर अपने chunk के साथ। तो जिस पल कोई user_id या कच्चा path label बनाकर जोड़ता है, आप कुछ सौ series से लाखों पर पहुंच जाते हैं। हमारा एक Prometheus इंस्टेंस बार बार OOM हो रहा था और निकला कि एक टीम ने अपने request counter पर query string समेत पूरा URL label बना दिया था। मैं यह नियम इस्तेमाल करता हूं कि label वैल्यू ऐसे छोटे, बंद सेट से आनी चाहिए जिसे आप व्हाइटबोर्ड पर लिख सकें: method, status class, endpoint template, region। जो भी बेहिसाब है वह लॉग लाइन या trace span attribute में जाता है, जहां स्टोरेज का ढांचा उसी के लिए बना है। व्यावहारिक तौर पर मैं इसे metric_relabel_configs से लागू करता हूं ताकि scrape के वक्त जाने पहचाने खराब label गिर जाएं, प्रति target sample limit रखता हूं ताकि एक सर्विस पूरा इंस्टेंस न गिरा दे, और जब भी pull request में नई मेट्रिक दिखे तो एक तेज रिव्यू करता हूं।