🔼 🐒 🔹 GitLab में विसंगतियों का पता लगाने के लिए प्रोमेथियस का उपयोग कैसे करें 🚳 🥦 🙁

प्रोमेथियस क्वेरी भाषा की बुनियादी विशेषताओं में से एक समय श्रृंखला का वास्तविक समय एकत्रीकरण है । आप समय श्रृंखला डेटा में विसंगतियों का पता लगाने के लिए प्रोमेथियस क्वेरी भाषा का भी उपयोग कर सकते हैं। Mail.ru बादल समाधान टीम है अनुवाद GitLab बुनियादी ढांचे टीम के इंजीनियर ने एक लेख है, जहां आप कोड उदाहरण है कि आप अपने सिस्टम पर कोशिश कर सकते हैं मिल जाएगा।

विसंगति का पता लगाने के लिए क्या है?

GitLab के लिए विसंगति का पता लगाने के महत्व को निर्धारित करने वाले चार मुख्य कारण हैं:

घटना निदान : हम पता लगा सकते हैं कि कौन सी सेवाएं घटना का पता लगाने के समय (एमटीटीडी) को कम करके अपने सामान्य दायरे से बाहर चली गई हैं और, तदनुसार, समस्या का तेजी से समाधान प्रस्तुत करती हैं।
प्रदर्शन गिरावट का पता लगाना : उदाहरण के लिए, यदि एक प्रतिगमन को एक ऐसी सेवा में पेश किया जाता है जो इसे किसी अन्य सेवा तक अक्सर पहुंच देता है, तो हम जल्दी से इस समस्या का पता लगा सकते हैं और इसे ठीक कर सकते हैं।
दुरुपयोग का पता लगाने और उन्मूलन : GitLab वितरण और एकीकरण तंत्र ( GitLab CI / CD ) और होस्टिंग (GitLab Pages) और सीमित संख्या में उपयोगकर्ता प्रदान करता है जो इन तंत्रों का उपयोग कर सकते हैं।
सुरक्षा : GitLab समय श्रृंखला में असामान्य रुझानों का पता लगाने के लिए विसंगति का पता लगाना महत्वपूर्ण है।

इन और अन्य कारणों के लिए, लेख के लेखक ने यह पता लगाने का फैसला किया कि प्रोमेथियस प्रश्नों और नियमों का उपयोग करके गीतालाब समय श्रृंखला में विसंगतियों की परिभाषा को कैसे कॉन्फ़िगर किया जाए।

सही एकत्रीकरण स्तर क्या है?

सबसे पहले, टाइम सीरीज़ को सही तरीके से एकत्र किया जाना चाहिए। नीचे दिए गए उदाहरण में, हमने डेटा पुनर्प्राप्त करने के लिए मानक http_requests_total काउंटर का उपयोग किया, हालांकि कई अन्य मैट्रिक्स भी अच्छा करेंगे।

http_requests_total{
 job="apiserver",
 method="GET",
 controller="ProjectsController",
 status_code="200",
 environment="prod"
}

इस परीक्षण मीट्रिक में कई पैरामीटर हैं: विधि, नियंत्रक, स्थिति कोड (स्थिति_कोड), पर्यावरण, और साथ ही प्रोमेथियस द्वारा जोड़े गए पैरामीटर, उदाहरण के लिए, नौकरी और उदाहरण।

अब आपको डेटा एकत्रीकरण का सही स्तर चुनने की आवश्यकता है। बहुत अधिक, बहुत कम - यह सब विसंगतियों का पता लगाने के लिए महत्वपूर्ण है। यदि डेटा बहुत अधिक है, तो दो संभावित समस्याएं हैं:

आप विसंगति को छोड़ सकते हैं क्योंकि एकत्रीकरण आपके डेटा के सबसेट में आने वाली समस्याओं को छुपाता है।
यदि आप एक विसंगति पाते हैं, तो अतिरिक्त प्रयास के बिना इसे आपके सिस्टम के एक अलग हिस्से से संबंधित करना मुश्किल है।

यदि डेटा को पर्याप्त रूप से एकत्र नहीं किया जाता है, तो इससे झूठी सकारात्मक की संख्या में वृद्धि हो सकती है, साथ ही गलत डेटा की गलत व्याख्या भी हो सकती है।

हमारे अनुभव के आधार पर, एकत्रीकरण का सबसे सही स्तर सेवा का स्तर है, अर्थात्, हम कार्य (नौकरी) और पर्यावरण (पर्यावरण) के लेबल को शामिल करते हैं, और अन्य सभी लेबल को छोड़ देते हैं।

एकत्रीकरण, जिसे हम पूरे लेख में चर्चा करेंगे, इसमें शामिल हैं: नौकरी - http_request, एकत्रीकरण - पांच मिनट, जिसकी गणना कार्य और पर्यावरण के आधार पर पांच मिनट में की जाती है।

- record: job:http_requests:rate5m
expr: sum without(instance, method, controller, status_code)
(rate(http_requests_total[5m]))
# --> job:http_requests:rate5m{job="apiserver", environment="prod"}  21321
# --> job:http_requests:rate5m{job="gitserver", environment="prod"}  2212
# --> job:http_requests:rate5m{job="webserver", environment="prod"}  53091

उपरोक्त उदाहरण से, यह स्पष्ट है कि श्रृंखला से http_requests_total सबसेट को काम और पर्यावरण के संदर्भ में चुना जाता है, फिर उनकी संख्या पांच मिनट के लिए मानी जाती है।

विसंगतियों का पता लगाने के लिए जेड-स्कोर का उपयोग करना

विसंगतियों का पता लगाने के लिए सांख्यिकी के मूल सिद्धांतों को लागू किया जा सकता है।

यदि आप प्रोमेथियस श्रृंखला के माध्य और मानक विचलन को जानते हैं , तो आप z- स्कोर की गणना करने के लिए श्रृंखला के किसी भी नमूने का उपयोग कर सकते हैं।

जेड-स्कोर मनाया या मापा मूल्य के सापेक्ष प्रसार का एक माप है, जो दिखाता है कि औसत मूल्य के सापेक्ष इसके मानक विचलन कितने मानक विचलन है ।

यही है, z- स्कोर = 0 का मतलब है कि z- स्कोर मानक वितरण के साथ डाटासेट में औसत मूल्य के समान है, और z-स्कोर = 1 का मतलब है कि मानक विचलन = 1.0 औसत से।

हम मानते हैं कि मूल डेटा का एक सामान्य वितरण है, जिसका अर्थ है कि 99.7% नमूनों में 0 से 3 तक का जेड-स्कोर है। ज़ेड-स्कोर शून्य से दूर है, इसकी संभावना कम है।

हम इस संपत्ति को प्रोमेथियस डेटा श्रृंखला में विसंगतियों का पता लगाने के लिए लागू करते हैं:

हम बड़े नमूना आकार वाले डेटा का उपयोग करके मीट्रिक के लिए औसत और मानक विचलन की गणना करते हैं। इस उदाहरण के लिए, हम साप्ताहिक डेटा का उपयोग करते हैं। यदि हम मानते हैं कि रिकॉर्ड का मूल्यांकन एक मिनट में एक बार किया जाता है, तो एक हफ्ते में हमारे पास 10,000 से अधिक नमूने होंगे।
```
# Long-term average value for the series
- record: job:http_requests:rate5m:avg_over_time_1w
expr: avg_over_time(job:http_requests:rate5m[1w])

# Long-term standard deviation for the series
- record: job:http_requests:rate5m:stddev_over_time_1w
expr: stddev_over_time(job:http_requests:rate5m[1w])
```
एकत्रीकरण के लिए औसत और मानक विचलन मिलते ही हम प्रोमेथियस क्वेरी के लिए z- स्कोर की गणना कर सकते हैं।
```
# Z-Score for aggregation
(
job:http_requests:rate5m -
job:http_requests:rate5m:avg_over_time_1w
) /  job:http_requests:rate5m:stddev_over_time_1w
```

सामान्य वितरण के सांख्यिकीय सिद्धांतों के आधार पर, मान लीजिए कि +3 से -3 की सीमा के बाहर कोई भी मूल्य एक विसंगति होगी। तदनुसार, हम ऐसी विसंगतियों के बारे में एक चेतावनी बना सकते हैं। उदाहरण के लिए, जब हमारा एकत्रीकरण पाँच मिनट से अधिक समय तक इस सीमा से आगे बढ़ेगा, तो हमें एक अलर्ट प्राप्त होगा।

48 घंटे के लिए GitLab पेज सेवा प्रति सेकंड अनुरोधों की संख्या का ग्राफ। +3 से -3 तक की सीमा में जेड-स्कोर को हरे रंग में हाइलाइट किया गया है।

जेड-स्कोर ग्राफ पर व्याख्या करना मुश्किल हो सकता है, क्योंकि इस मूल्य में माप की एक इकाई नहीं है। लेकिन इस ग्राफ में विसंगतियां निर्धारित करने के लिए बहुत सरल हैं। ग्रीन ज़ोन से आगे जाने वाली हर चीज़, जो कि -3 से +3 के z-स्कोर के साथ मूल्यों के गलियारे को दिखाती है, एक अनमोल मूल्य होगा।

यदि डेटा वितरण सामान्य नहीं है तो क्या करें

हम मानते हैं कि डेटा का वितरण सामान्य है। अन्यथा, हमारा जेड-स्कोर गलत होगा।

डेटा वितरण की सामान्यता निर्धारित करने के लिए बहुत सारे सांख्यिकीय ट्रिक्स हैं, लेकिन सबसे अच्छा तरीका यह है कि आपका डेटा z- स्कोर -4.0 से +4.0 तक होता है।

न्यूनतम और अधिकतम z- स्कोर दिखाने वाले दो प्रोमेथियस प्रश्न:

(
max_over_time(job:http_requests:rate5m[1w]) - avg_over_time(job:http_requests:rate5m[1w])
) / stddev_over_time(job:http_requests:rate5m[1w])
# --> {job="apiserver", environment="prod"}  4.01
# --> {job="gitserver", environment="prod"}  3.96
# --> {job="webserver", environment="prod"}  2.96

(
 min_over_time(job:http_requests:rate5m[<1w]) - avg_over_time(job:http_requests:rate5m[1w])
) / stddev_over_time(job:http_requests:rate5m[1w])
# --> {job="apiserver", environment="prod"}  -3.8
# --> {job="gitserver", environment="prod"}  -4.1
# --> {job="webserver", environment="prod"}  -3.2

यदि आपके परिणाम -20 से +20 तक हैं, तो इसका मतलब है कि बहुत अधिक डेटा का उपयोग किया गया है और परिणाम विकृत हैं। यह भी याद रखें कि आपको एकत्रित पंक्तियों के साथ काम करना होगा। जिन मेट्रिक्स में सामान्य वितरण नहीं होता है, उनमें त्रुटि दर, देरी, कतार की लंबाई और इतने पर जैसे पैरामीटर शामिल हैं। लेकिन इनमें से कई मेट्रिक्स फिक्स्ड अलर्ट थ्रेसहोल्ड के साथ बेहतर काम करेंगे।

सांख्यिकीय मौसम संबंधी विसंगति का पता लगाना

यद्यपि z- स्कोर की गणना समय-श्रृंखला डेटा के सामान्य वितरण के साथ अच्छी तरह से काम करती है, एक दूसरी विधि है जो और भी अधिक सटीक विसंगति का पता लगा सकती है। यह सांख्यिकीय मौसम का उपयोग है।

मौसमी एक समय श्रृंखला मीट्रिक की एक विशेषता है जब यह मीट्रिक नियमित और अनुमानित परिवर्तन से गुजरता है जो प्रत्येक चक्र में दोहराया जाता है।

लगातार चार हफ्तों के लिए सोमवार से रविवार तक प्रति सेकंड (आरपीएस) अनुरोधों का

चार्ट ऊपर के चार्ट आरपीएस को दर्शाता है - सात दिनों के लिए आरपीएस (प्रति सेकंड अनुरोधों की संख्या) - सोमवार से रविवार तक, लगातार चार सप्ताह तक। इस सात-दिवसीय श्रेणी को "ऑफ़सेट" कहा जाता है, अर्थात, माप के लिए उपयोग किया जाने वाला पैटर्न।

चार्ट पर प्रत्येक सप्ताह एक अलग रंग है। डेटा की मौसमीता ग्राफ पर दर्शाए गए रुझानों में अनुक्रम द्वारा इंगित की जाती है - प्रत्येक सोमवार सुबह हम आरपीएस में समान वृद्धि का निरीक्षण करते हैं, और शुक्रवार को शाम को हम हमेशा आरपीएस में कमी का निरीक्षण करते हैं।

हमारे समय श्रृंखला डेटा में सीज़नसिटी का उपयोग करते हुए, हम विसंगतियों की घटना और उनके पता लगाने की अधिक सटीक भविष्यवाणी कर सकते हैं।

मौसमी का उपयोग कैसे करें

प्रोमेथियस मौसमी की गणना के लिए कई अलग-अलग सांख्यिकीय तंत्र का उपयोग करता है।

पहले, हम एक गणना करते हैं, पिछले सप्ताह के परिणामों के लिए सप्ताह के लिए विकास की प्रवृत्ति को जोड़ते हैं। विकास की प्रवृत्ति की गणना निम्न प्रकार से की जाती है: पिछले सप्ताह की चलती औसत को पिछले सप्ताह की चलती औसत से घटाएं।

- record: job:http_requests:rate5m_prediction
  expr: >
    job:http_requests:rate5m offset 1w          # Value from last period
    + job:http_requests:rate5m:avg_over_time_1w # One-week growth trend
    — job:http_requests:rate5m:avg_over_time_1w offset 1w

पहला पुनरावृति कुछ हद तक "संकीर्ण" हो जाता है - हम अपने पूर्वानुमान प्राप्त करने के लिए इस सप्ताह की पांच मिनट की खिड़की और पिछले सप्ताह का उपयोग करते हैं।

दूसरी पुनरावृत्ति में, हम पिछले सप्ताह के लिए चार घंटे की अवधि का औसत और वर्तमान सप्ताह के साथ तुलना करके अपने कवरेज का विस्तार करते हैं।

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

- record: job:http_requests:rate5m_prediction
  expr: >
    avg_over_time(job:http_requests:rate5m[4h] offset 166h) # Rounded value from last period
    + job:http_requests:rate5m:avg_over_time_1w    # Add 1w growth trend
    - job:http_requests:rate5m:avg_over_time_1w offset 1w

अनुरोध में 166 घंटे का संकेत दिया गया है, जो एक पूर्ण सप्ताह (7 * 24 = 168) से दो घंटे कम है, क्योंकि हम वर्तमान समय के आधार पर चार घंटे की अवधि का उपयोग करना चाहते हैं, इसलिए हमें पूर्ण सप्ताह की तुलना में दो घंटे कम होने की आवश्यकता है।

दो सप्ताह में वास्तविक आरपीएस (पीला) और अनुमानित (नीला)

हमारे पूर्वानुमान के साथ वास्तविक आरपीएस की तुलना से पता चलता है कि हमारी गणना काफी सटीक थी। हालाँकि, इस पद्धति में एक खामी है।

उदाहरण के लिए, 1 मई, GitLab को बुधवार के दिन सामान्य से कम इस्तेमाल किया गया था, क्योंकि यह दिन एक दिन की छुट्टी थी। चूंकि अनुमानित वृद्धि की प्रवृत्ति इस बात पर निर्भर करती है कि पिछले सप्ताह में सिस्टम का उपयोग कैसे किया गया था, अगले सप्ताह के लिए हमारे पूर्वानुमान, अर्थात, 8 मई, बुधवार को वास्तव में कम आरपीएस दिया गया।

बुधवार, 1 मई से पहले लगातार तीन सप्ताह तक तीन पूर्वानुमान लगाकर इस त्रुटि को सुधारा जा सकता है। अनुरोध समान है, लेकिन ऑफसेट समायोजित है।

- record: job:http_requests:rate5m_prediction
  expr: >
   quantile(0.5,
     label_replace(
       avg_over_time(job:http_requests:rate5m[4h] offset 166h)
       + job:http_requests:rate5m:avg_over_time_1w — job:http_requests:rate5m:avg_over_time_1w offset 1w
       , "offset", "1w", "", "")
     or
     label_replace(
       avg_over_time(job:http_requests:rate5m[4h] offset 334h)
       + job:http_requests:rate5m:avg_over_time_1w — job:http_requests:rate5m:avg_over_time_1w offset 2w
       , "offset", "2w", "", "")
     or
     label_replace(
       avg_over_time(job:http_requests:rate5m[4h] offset 502h)
       + job:http_requests:rate5m:avg_over_time_1w — job:http_requests:rate5m:avg_over_time_1w offset 3w
       , "offset", "3w", "", "")
   )
   without (offset)

8 मई से पहले तीन सप्ताह के लिए चार्ट पर तीन पूर्वानुमान हैं, बुधवार, 8 मई के लिए वास्तविक आरपीएस के साथ। आप देख सकते हैं कि दो पूर्वानुमान बहुत सटीक हैं, लेकिन 1 मई के सप्ताह का पूर्वानुमान गलत है।

इसके अलावा, हमें तीन पूर्वानुमानों की आवश्यकता नहीं है, हमें एक पूर्वानुमान की आवश्यकता है। औसत मूल्य एक विकल्प नहीं है, क्योंकि यह 1 मई से हमारे विकृत आरपीएस डेटा द्वारा धुंधला हो जाएगा। इसके बजाय, आपको माध्य की गणना करने की आवश्यकता है। प्रोमेथियस में माध्यिका क्वेरी नहीं है, लेकिन हम माध्यिका के बजाय क्वांटाइल एकत्रीकरण का उपयोग कर सकते हैं।

एकमात्र समस्या यह है कि हम तीन श्रृंखलाओं को एकत्रीकरण में शामिल करने की कोशिश कर रहे हैं, और ये तीन श्रृंखलाएं वास्तव में तीन सप्ताह में एक ही श्रृंखला हैं। दूसरे शब्दों में, उनके पास समान लेबल हैं, इसलिए उन्हें एक साथ रखना मुश्किल है।

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

- record: job:http_requests:rate5m_prediction
  expr: >
   quantile(0.5,
     label_replace(
       avg_over_time(job:http_requests:rate5m[4h] offset 166h)
       + job:http_requests:rate5m:avg_over_time_1w — job:http_requests:rate5m:avg_over_time_1w offset 1w
       , "offset", "1w", "", "")
     or
     label_replace(
       avg_over_time(job:http_requests:rate5m[4h] offset 334h)
       + job:http_requests:rate5m:avg_over_time_1w — job:http_requests:rate5m:avg_over_time_1w offset 2w
       , "offset", "2w", "", "")
     or
     label_replace(
       avg_over_time(job:http_requests:rate5m[4h] offset 502h)
       + job:http_requests:rate5m:avg_over_time_1w — job:http_requests:rate5m:avg_over_time_1w offset 3w
       , "offset", "3w", "", "")
   )
   without (offset)

अब तीन समुच्चय के माध्य के साथ हमारा पूर्वानुमान अधिक सटीक हो गया है।

मेडियन पूर्वानुमान बनाम वास्तविक आरपीएस

कैसे पता करें कि हमारा पूर्वानुमान वास्तव में सटीक है

पूर्वानुमान की सटीकता की जांच करने के लिए, हम जेड-स्कोर पर लौट सकते हैं। इसका उपयोग मानक विचलन में इसके पूर्वानुमान के साथ नमूने की विसंगति को मापने के लिए किया जाता है। पूर्वानुमान से मानक विचलन जितना बड़ा होता है, उतनी ही अधिक संभावना है कि एक विशेष मूल्य एक बाहरी है।

अनुमानित विचलन सीमा +1.5 से -1.5 तक है।

आप एक साप्ताहिक चलती औसत के बजाय एक मौसमी पूर्वानुमान का उपयोग करने के लिए हमारे ग्राफा चार्ट को बदल सकते हैं। दिन के एक विशिष्ट समय के लिए सामान्य मूल्यों की सीमा हरे रंग में छायांकित होती है। ग्रीन ज़ोन से आगे जाने वाली हर चीज़ को एक बाहरी चीज़ माना जाता है। इस मामले में, रविवार की दोपहर को आउटलाइन हुई, जब हमारे क्लाउड प्रदाता को कुछ नेटवर्क समस्याएं थीं।

मौसमी पूर्वानुमानों के लिए-2 z- स्कोर का उपयोग करना अच्छा है।

प्रोमेथियस के साथ अलर्ट कैसे सेट करें

यदि आप असामान्य घटनाओं के लिए एक चेतावनी सेट करना चाहते हैं, तो आप काफी सरल प्रोमेथियस नियम लागू कर सकते हैं, जो यह जांचता है कि किसी संकेतक का जेड-स्कोर +2 और -2 के बीच की सीमा में है या नहीं।

- alert: RequestRateOutsideNormalRange
  expr: >
   abs(
     (
       job:http_requests:rate5m - job:http_requests:rate5m_prediction
     ) / job:http_requests:rate5m:stddev_over_time_1w
   ) > 2
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: Requests for job {{ $labels.job }} are outside of expected operating parameters

GitLab में, हम एक कस्टम रूटिंग नियम का उपयोग करते हैं जो किसी भी विसंगति का पता लगाने पर स्लैक के माध्यम से एक अलर्ट भेजता है, लेकिन हमारी सहायता टीम से संपर्क नहीं करता है।

प्रोमेथियस का उपयोग करके गिटलैब में विसंगतियों का पता कैसे लगाया जाए

प्रोमेथियस का उपयोग कुछ असामान्यताओं का पता लगाने के लिए किया जा सकता है।
उचित एकत्रीकरण विसंगतियों को खोजने की कुंजी है।
यदि आपके डेटा का सामान्य वितरण है तो Z- स्कोरिंग प्रभावी है।
सांख्यिकीय मौसमीता विसंगतियों का पता लगाने के लिए एक शक्तिशाली तंत्र है।

Mail.ru Cloud Solutions के समर्थन से अनुवादित ।

फिर भी उपयोगी :

GitLab में विसंगतियों का पता लगाने के लिए प्रोमेथियस का उपयोग कैसे करें