बुनियादी ढांचे में समस्याओं की तलाश में सरल मैट्रिक्स और समय बचाने का एक तरीका

डेटा सेंटर में ऐसा नहीं है, जिसमें हम सर्वर किराए पर लेते हैं, एक और मिनी घटना हुई। परिणामस्वरूप, हमारी सेवा के लिए कोई गंभीर परिणाम नहीं थे, उपलब्ध मीट्रिक के अनुसार, हम यह समझने में सक्षम थे कि सचमुच एक मिनट में क्या हो रहा था। और फिर मैंने कल्पना की कि कैसे मेरे दिमाग को रैक करना होगा अगर केवल 2 सरल मैट्रिक्स गायब थे। कट के तहत, तस्वीरों में एक छोटी कहानी।

कल्पना कीजिए कि हमने एक निश्चित सेवा की प्रतिक्रिया समयरेखा में एक विसंगति देखी। सादगी के लिए, हम / पिंग हैंडलर लेते हैं, जो डेटाबेस या पड़ोसी सेवाओं तक नहीं पहुंचता है, लेकिन बस '200 ओके' लौटाता है (यह स्वास्थ्य जांच सेवा के लिए लोड बैलेंसर्स और के 8 के लिए आवश्यक है)


पहला विचार क्या है? यह सही है, सेवा में पर्याप्त संसाधन नहीं हैं, सबसे अधिक संभावना है कि सीपीयू! हम प्रोसेसर की खपत को देखते हैं:


हां, ऐसे ही फट रहे हैं। अगला, हम सर्वर पर सेवाओं द्वारा खपत को देखते हैं:



हम देखते हैं कि प्रोका की खपत सभी सेवाओं के लिए आनुपातिक रूप से बढ़ गई है। आप आगे स्पष्ट रूप से कुछ भी नहीं कह सकते हैं: आप जा सकते हैं और देख सकते हैं कि क्या लोड प्रोफ़ाइल बदल गई है (चूंकि सभी घटक जुड़े हुए हैं और इनपुट अनुरोधों में वृद्धि वास्तव में संसाधन खपत में आनुपातिक वृद्धि का कारण बन सकती है) या समझें कि सर्वर संसाधनों का क्या हो गया है।

बेशक, मैंने जितना हो सके साज़िश को संरक्षित करने की कोशिश की, लेकिन लेख की शुरुआत में, आप शायद पहले से ही अनुमान लगा चुके थे कि सर्वर ने केवल उपलब्ध सीपीयू टिक की संख्या कम कर दी है। Dmesg में, यह कुछ इस तरह दिखता है:

CPU3: Core temperature above threshold, cpu clock throttled (total events = 88981)


मोटे तौर पर, हमने प्रोसेसर के अधिक गर्म होने के कारण आवृत्ति को कम कर दिया है। हम तापमान को देखते हैं:



अब सब कुछ स्पष्ट है। चूंकि हमारे पास 6 सर्वरों में तुरंत समान व्यवहार था, इसलिए हमने महसूस किया कि समस्या डीसी में है, और सब कुछ में नहीं, बल्कि रैक की कुछ पंक्तियों में ही।

लेकिन वापस मैट्रिक्स के लिए। हम संभावित रूप से जानना चाहते हैं कि क्या सर्वर भविष्य में ज़्यादा गरम हो जाएगा, लेकिन यह सभी डैशबोर्ड में प्रोसेसर तापमान के ग्राफ को जोड़ने और हर बार जांचने का एक कारण नहीं है।

आमतौर पर ट्रिगर का उपयोग प्रक्रिया को अनुकूलित करने के लिए कुछ मैट्रिक्स को ट्रैक करने के लिए किया जाता है। लेकिन प्रोसेसर के तापमान से मुझे किस सीमा के लिए चयन करना चाहिए?

यह ट्रिगर के लिए एक अच्छी सीमा चुनने में कठिनाई के कारण है, कई इंजीनियर विसंगति डिटेक्टर का सपना देखते हैं, जो बिना सेटिंग्स के ही मिल जाएगा, मुझे नहीं पता कि क्या :)

पहला विचार उस दहलीज के तापमान को निर्धारित करना है जिस पर हमारी सेवा में समस्याएँ शुरू हुईं। और अगर आपने कभी ओवरहीट नहीं किया है? बेशक आप मेरे कार्यक्रम को देख सकते हैं और अपने लिए तय कर सकते हैं कि 95 ° C की आपको क्या जरूरत है, लेकिन चलिए थोड़ा और सोचते हैं।

हमारे साथ समस्या डिग्री के कारण नहीं है, लेकिन क्योंकि आवृत्ति कम हो गई है! आइए ऐसी घटनाओं की संख्या पर नज़र रखें।
लिनक्स पर, इसे sysfs से हटाया जा सकता है:

/sys/devices/system/cpu/cpu*/thermal_throttle/package_throttle_count




ईमानदार होने के लिए, हम इस मीट्रिक को कहीं भी प्रदर्शित नहीं करते हैं, हमारे पास केवल उन सभी ग्राहकों के लिए एक ऑटो-ट्रिगर है जो दहलीज "> 10 घटनाओं / सेकंड" तक पहुंचते हैं। हमारे आंकड़ों के अनुसार, इस सीमा पर व्यावहारिक रूप से कोई गलत सकारात्मकता नहीं है।

हां, यह ट्रिगर शायद ही कभी काम करता है, लेकिन जब ऐसा होता है, तो यह जीवन को बहुत आसान बना देता है!

हम okmeter.io पर अधिकांश समय ऑटो-ट्रिगर्स के हमारे डेटाबेस के विकास में लगे हुए हैं, जिससे हमारे ग्राहकों के लिए उनके लिए अज्ञात समस्याओं का पता लगाना आसान हो जाता है।