👜 🌴 ⛵️ प्रोमेथियस के साथ समय के संदर्भ में विकृत नहीं किए गए मैट्रिक्स को कैसे इकट्ठा किया जाए 👇🏻 🤷🏼 👎

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

यह लेख उन ट्रैप्स के लिए समर्पित है जो अतुल्यकालिक हैंडलर का मूल्यांकन करने की प्रक्रिया में सबसे आम हैं, उत्पादन वातावरण में एक घटना का एक उदाहरण का उपयोग करते हुए, जहां मैट्रिक्स के साथ भी, यह निर्धारित करना असंभव था कि हैंडलर क्या कर रहे थे। मैट्रिक्स के उपयोग ने फ़ोकस को इतना अधिक स्थानांतरित कर दिया है कि मैट्रिक्स स्वयं खुले तौर पर झूठ बोलते हैं, वे कहते हैं, आपके हैंडलर नरक में हैं।

हम देखेंगे कि सटीक अनुमान प्रदान करने के लिए इस तरह से मेट्रिक्स का उपयोग कैसे किया जाता है, और निष्कर्ष में हम ओपन सोर्स प्रोमेथियस-क्लाइंट-ट्रेसर के संदर्भ कार्यान्वयन को दिखाएंगे, जिसे आप अपने अनुप्रयोगों में उपयोग कर सकते हैं।

घटना

मशीन-गन गति से अलर्ट आए: HTTP त्रुटियों की संख्या में तेजी से वृद्धि हुई, और नियंत्रण पैनलों ने पुष्टि की कि अनुरोध कतारें बढ़ रही थीं, और प्रतिक्रिया समय चल रहा था। लगभग 2 मिनट बाद, कतारें साफ हो गईं, और सब कुछ सामान्य हो गया।

करीब से निरीक्षण करने पर, यह पता चला कि हमारे एपीआई सर्वर खड़े थे, जो एक डीबी प्रतिक्रिया की प्रतीक्षा कर रहा था, जिसके कारण यह रुक गया और अचानक सभी गतिविधि उठ गई। और जब आप समझते हैं कि सबसे भारी लोड अतुल्यकालिक प्रोसेसर के स्तर पर अधिक बार गिरता है, तो वे मुख्य संदिग्ध बन गए हैं। तार्किक सवाल था: वे वहाँ क्या कर रहे हैं?

प्रोमेथियस मैट्रिक दिखाता है कि इस प्रक्रिया में कितना समय लगता है, यहाँ यह है:

# HELP job_worked_seconds_total Sum of the time spent processing each job class # TYPE job_worked_seconds_total counter job_worked_seconds_total{job}

प्रत्येक कार्य के कुल निष्पादन समय और आवृत्ति जिसके साथ मीट्रिक में परिवर्तन होता है, पर नज़र रखने से, हमें पता चलेगा कि काम का समय कितना खर्च किया गया है। यदि 15 सेकंड की अवधि के लिए। संख्या में 15 की वृद्धि हुई, इसका अर्थ है 1 व्यस्त हैंडलर (प्रत्येक पिछले सेकंड के लिए एक सेकंड), जबकि 30 की वृद्धि का अर्थ है 2 गेंदबाज़, आदि।

घटना के दौरान एक कार्य शेड्यूल दिखाएगा कि हम क्या सामना कर रहे हैं। परिणाम निराशाजनक हैं; घटना का समय (16: 02–16: 04) चिंताजनक लाल रेखा द्वारा चिह्नित है:

घटना के दौरान हैंडलर गतिविधि: एक ध्यान देने योग्य अंतर दिखाई देता है।

इस दुःस्वप्न के बाद डिबेट करने वाले व्यक्ति के रूप में, मुझे यह देखकर दुख हुआ कि घटना के दौरान गतिविधि वक्र एकदम नीचे था। यह वेब हुक के साथ काम करने का समय है, जिसमें हमारे पास 20 समर्पित हैंडलर हैं। लॉग से, मुझे पता है कि वे सभी व्यवसाय में थे, और मुझे उम्मीद थी कि वक्र लगभग 20 सेकंड पर होगा, और मैंने लगभग सीधी रेखा देखी। इसके अलावा, 16:05 पर इस बड़ी नीली चोटी को देखें? शेड्यूल को देखते हुए, 20 सिंगल-थ्रेडेड प्रोसेसर ने 45 सेकंड खर्च किए। गतिविधि के हर दूसरे के लिए, लेकिन क्या यह संभव है?!

कहां और क्या गलत हुआ?

घटना की अनुसूची झूठ बोल रही है: यह काम करने वाली गतिविधि को छिपाती है और एक ही समय में सुपरफ्लस को दर्शाती है - जहां पर मापना है। ऐसा क्यों होता है, यह जानने के लिए, आपको मीट्रिक ट्रैकिंग के कार्यान्वयन को ध्यान में रखना होगा और यह प्रोमेथियस एकत्रित मैट्रिक्स के साथ कैसे इंटरैक्ट करता है।

हैंडलर मेट्रिक्स कैसे इकट्ठा करते हैं, इसके साथ शुरू करके, आप एक अनुमानित वर्कफ़्लो कार्यान्वयन योजना को स्केच कर सकते हैं (नीचे देखें)। नोट: हैंडलर केवल एक कार्य पूरा होने पर मैट्रिक्स को अपडेट करते हैं।

 class Worker JobWorkedSecondsTotal = Prometheus::Client::Counter.new(...) def work job = acquire_job start = Time.monotonic_now job.run ensure # run after our main method block duration = Time.monotonic_now - start JobWorkedSecondsTotal.increment(by: duration, labels: { job: job.class }) end end

प्रोमेथियस (मैट्रिक्स निकालने के अपने दर्शन के साथ) हर 15 सेकंड में प्रत्येक हैंडलर को एक जीईटी अनुरोध भेजता है, अनुरोध के समय मैट्रिक्स के मूल्यों को रिकॉर्ड करता है। हैंडलर लगातार पूर्ण किए गए कार्यों के मैट्रिक्स को अपडेट करते हैं, और समय के साथ हम मूल्यों में परिवर्तन की गतिशीलता को ग्राफिक रूप से प्रदर्शित कर सकते हैं।

अंडर- और पुनर्मूल्यांकन के साथ समस्या तब दिखाई देने लगती है जब भी किसी कार्य को पूरा करने में लगने वाला समय प्रत्येक 15 सेकंड में आने वाले अनुरोध के लिए प्रतीक्षा समय से अधिक हो जाता है। उदाहरण के लिए, एक कार्य अनुरोध के 5 सेकंड पहले शुरू होता है और 1 सेकंड के बाद समाप्त होता है। पूरी तरह से और आम तौर पर, यह 6 सेकंड तक रहता है, लेकिन यह समय केवल अनुरोध के बाद किए गए समय की लागत का आकलन करते समय दिखाई देता है, जबकि इन 6 सेकंड में से 5 अनुरोध से पहले खर्च किए जाते हैं।

यदि कार्य रिपोर्टिंग अवधि (15 सेकंड) से अधिक समय लेते हैं, तो संकेतक और भी ईश्वरीय झूठ बोलते हैं। 1 मिनट के लिए कार्य के निष्पादन के दौरान, प्रोमेथियस के पास प्रोसेसर के लिए 4 अनुरोध भेजने का समय होगा, लेकिन मीट्रिक केवल चौथे के बाद अपडेट किया जाएगा।

वर्किंग एक्टिविटी की टाइमलाइन तैयार करने के बाद, हम देखेंगे कि जिस क्षण मैट्रिक अपडेट किया गया है वह प्रोमेथियस क्या देखता है। नीचे दिए गए आरेख में, हम दो संचालकों के समय को कई खंडों में तोड़ते हैं जो विभिन्न अवधि के कार्यों को प्रदर्शित करते हैं। लाल (15 सेकंड) और नीले (30 सेकंड) टैग 2 प्रोमेथियस डेटा नमूनों को इंगित करते हैं; मूल्यांकन के लिए डेटा स्रोत के रूप में कार्य करने वाले कार्यों को क्रमशः रंग में हाइलाइट किया गया है।

भले ही हैंडलर पूरे भार पर क्या कर रहे हैं, वे हर 15-सेकंड के अंतराल पर 30 सेकंड का काम करेंगे। चूंकि प्रोमेथियस ने काम पूरा होने तक इसे नहीं देखा है, इसलिए मेट्रिक्स को देखते हुए, 14 सेकंड का काम पहली बार के अंतराल में और दूसरे में 42 सेकंड में पूरा हुआ। यदि प्रत्येक हैंडलर एक बड़ा काम करता है, तो कुछ घंटों के बाद भी, बहुत अंत तक, हम रिपोर्ट नहीं देखेंगे कि काम चल रहा है।

इस आशय को प्रदर्शित करने के लिए, मैंने उन दस हैंडलर के साथ एक प्रयोग किया, जो ऐसे कामों में लगे हुए हैं जिनकी लंबाई अलग है और अर्ध-सामान्य 0.1 सेकंड और थोड़ा अधिक मूल्य ( यादृच्छिक कार्यों को देखें) के बीच वितरित किया जाता है । नीचे 3 रेखांकन कार्य गतिविधि को दर्शाते हैं; लंबाई में बढ़ते क्रम में दिखाया गया है।

1 सेकंड तक चलने वाले कार्य।

पहला ग्राफ़ दिखाता है कि प्रत्येक हैंडलर प्रत्येक सेकंड में लगभग 1 सेकंड का काम पूरा करता है - यह समतल लाइनों पर दिखाई देता है, और काम की कुल मात्रा हमारी क्षमताओं के बराबर है (10 हैंडलर प्रति सेकंड काम का एक सेकंड देते हैं)। वास्तव में, यह, कार्य की लंबाई की परवाह किए बिना, हम उम्मीद कर रहे हैं: छोटे और लंबे कार्यों पर बस इतना, निरंतर लोड वाले प्रोसेसर को बाहर करना चाहिए।

15 सेकंड तक चलने वाले कार्य।

कार्यों की अवधि बढ़ती है, और शेड्यूल में गड़बड़ी दिखाई देती है: हमारे पास अभी भी 10 प्रोसेसर हैं, उनमें से सभी पूरी तरह से कब्जे में हैं, लेकिन काम की कुल राशि - या तो उपयोगी क्षमता सीमा (10 सेकंड) से कम या अधिक है।

30 सेकंड तक चलने वाले कार्य।

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

विश्वास बहाल करें

यह हमारे लिए पर्याप्त नहीं था, इसलिए इन दीर्घकालिक कार्यों के साथ एक और बहुत बड़ी समस्या है, जो हमारे मैट्रिक्स को खराब करती है। जब भी कोई दीर्घकालिक कार्य पूरा हो जाता है - कहते हैं, अगर कुबेरनेट्स एक फली को पूल से बाहर फेंक देते हैं, या जब एक नोड मर जाता है - तो मैट्रिक्स का क्या होता है? यह कार्य पूरा होने पर तुरंत उन्हें अपडेट करने के लायक है, क्योंकि वे बताते हैं कि उन्होंने काम बिल्कुल नहीं किया था ।

मेट्रिक्स झूठ नहीं बोलना चाहिए। यह लैपटॉप अविश्वसनीय रूप से चमकता है, जिससे अस्तित्वगत आतंक और निगरानी उपकरण पैदा होते हैं, जो दुनिया की तस्वीर को विकृत करते हैं, एक जाल हैं और काम के लिए अनुपयुक्त हैं।

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

पेश है ... ट्रेसर

विकृत मेट्रिक्स समस्या का एक समाधान है Tracer , एक अमूर्त रूप से डिजाइन किया गया है जो प्रोमेथियस से संबंधित मेट्रिक्स को लगातार अपडेट करके लंबे समय तक चलने वाले कार्यों पर गतिविधि का मूल्यांकन करता है।

 class Tracer def trace(metric, labels, &block) ... end def collect(traces = @traces) ... end end

ट्रेसर एक अनुरेखण विधि प्रदान करता है जो प्रोमेथियस मैट्रिक्स और ट्रैक करने के लिए कार्य करता है। trace कमांड दिए गए ब्लॉक को निष्पादित करेगा (अनाम रूबी फ़ंक्शंस) और यह सुनिश्चित करेगा कि निष्पादन के दौरान tracer.collect अनुरोध, संबंधित मेट्रिक्स को अद्यतन करेगा चाहे वह अंतिम अनुरोध collect करने के collect कितना समय बीत चुका हो।

हमें कार्य की अवधि और प्रोमिथियस मेट्रिक्स अनुरोधों को पूरा करने वाले समापन बिंदु को ट्रैक करने के लिए tracer को हैंडलर से कनेक्ट करना होगा। हम हैंडलर से शुरू करते हैं, एक नए ट्रेसर को शुरू करते हैं और उसे acquire_job.run के निष्पादन को ट्रैक करने के लिए acquire_job.run ।

 class Worker def initialize @tracer = Tracer.new(self) end def work @tracer.trace(JobWorkedSecondsTotal, labels) { acquire_job.run } end # Tell the tracer to flush (incremental) trace progress to metrics def collect @tracer.collect end end

इस स्तर पर, ट्रैसर केवल मेट्रिक्स को अपडेट किए गए कार्य पर खर्च किए गए सेकंड में अपडेट करेगा - जैसा कि हमने मेट्रिक्स के प्रारंभिक कार्यान्वयन में किया था। प्रोमेथियस के अनुरोध को निष्पादित करने से पहले हमें अपने मैट्रिक्स को अपडेट करने के लिए ट्रेसर से पूछना चाहिए। यह मिडलवेयर रैक स्थापित करके किया जा सकता है।

 # config.ru # https://rack.imtqy.com/ class WorkerCollector def initialize(@app, workers: @workers); end def call(env) workers.each(&:collect) @app.call(env) # call Prometheus::Exporter end end # Rack middleware DSL workers = start_workers # Array[Worker] # Run the collector before serving metrics use WorkerCollector, workers: workers use Prometheus::Middleware::Exporter

रैक रूबी वेब सर्वर के लिए एक इंटरफ़ेस है जो आपको एक ही समापन बिंदु में कई रैक हैंडलर को संयोजित करने की अनुमति देता है। config.ru कमांड यह निर्धारित करती है कि रैक अनुप्रयोग - जब भी यह अनुरोध प्राप्त होता है - collect कमांड को पहले हैंडलर को भेजता है, और उसके बाद ही प्रोमेथियस क्लाइंट को संग्रह परिणाम config.ru के collect कहता है।

हमारे चार्ट के अनुसार, हम मेट्रिक्स को अपडेट करते हैं जब भी कार्य पूरा होता है या जब हमें मैट्रिक्स के लिए अनुरोध प्राप्त होता है। ऐसे कार्य जिनमें कई क्वेरीज़ समान रूप से सभी सेगमेंट पर डेटा भेजती हैं: जैसा कि उन कार्यों द्वारा दिखाया गया है जिनकी अवधि को 15-सेकंड के अंतराल में विभाजित किया गया था।

क्या यह बेहतर है?

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

तुलनात्मक (बाएं) पर निर्मित मैट्रिक्स और ट्रेसर (दाएं) द्वारा नियंत्रित, एक काम के प्रयोग से लिया गया।

प्रारंभिक माप के स्पष्ट रूप से गलत और अराजक अनुसूची की तुलना में, ट्रेसर द्वारा एकत्र किए गए मेट्रिक्स चिकनी और सुसंगत हैं। अब हम न केवल प्रत्येक मीट्रिक अनुरोध को सही ढंग से टाई करते हैं, बल्कि किसी भी हैंडलर की अचानक मौत के बारे में भी चिंता नहीं करते हैं: प्रोमेथियस मेट्रिक्स को तब तक रिकॉर्ड करता है जब तक हैंडलर गायब नहीं हो जाता है, अपने सभी काम का मूल्यांकन करता है।

क्या इसका उपयोग किया जा सकता है?

हाँ! Tracer इंटरफ़ेस कई परियोजनाओं में मेरे लिए उपयोगी साबित हुआ, इसलिए यह एक अलग रूबी रत्न, प्रोमेथियस-क्लाइंट-ट्रेसर है । यदि आप अपने रूबी अनुप्रयोगों में प्रोमेथियस क्लाइंट का उपयोग करते हैं, तो बस prometheus-client-tracer को अपने मोबाइल एप्लिकेशन में जोड़ें:

 require "prometheus/client" require "prometheus/client/tracer" JobWorkedSecondsTotal = Prometheus::Client::Counter.new(...) Prometheus::Client.trace(JobWorkedSecondsTotal) do sleep(long_time) end

यदि यह आपके लिए उपयोगी है और यदि आप चाहते हैं कि आधिकारिक प्रोमेथियस रूबी क्लाइंट Tracer में दिखाई दे, तो क्लाइंट_रुबी # 135 में एक समीक्षा छोड़ दें।

और अंत में, कुछ विचार

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

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

प्रोमेथियस के साथ समय के संदर्भ में विकृत नहीं किए गए मैट्रिक्स को कैसे इकट्ठा किया जाए