एर्लांग / अमृत में गुणवत्ता समाधान के लिए संघर्ष

@jcutrer

आज हम घटनाओं के बारे में बात करेंगे, मात्रात्मक मेट्रिक्स, और इन सबकी निगरानी करेंगे ताकि टीम की घटनाओं की प्रतिक्रिया दर बढ़ाई जा सके और लक्ष्य प्रणाली के डाउनटाइम को कम किया जा सके।

Erlang / OTP एक ढांचे के रूप में और वितरित प्रणालियों के निर्माण की विचारधारा हमें मानक घटकों के विकास, उपकरण और कार्यान्वयन के लिए विनियमित दृष्टिकोण प्रदान करती है। मान लीजिए कि हमने ओटीपी की क्षमता का उपयोग किया और प्रोटोटाइप से उत्पादन तक सभी तरह से चले गए। हमारी एर्लांग परियोजना युद्ध सर्वरों पर बहुत अच्छा महसूस करती है, कोड बेस लगातार विकसित हो रहा है, नई आवश्यकताएं और कार्यक्षमता दिखाई देती हैं, नए लोग टीम में आते हैं, और सब कुछ ठीक होने लगता है। लेकिन कभी-कभी कुछ गलत हो जाता है और तकनीकी समस्याएं, मानव कारक से गुणा होती हैं, जिससे दुर्घटना हो सकती है।

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

सूचना प्रणालियों में हमेशा विभिन्न प्रकृति की विफलताओं के होने की संभावना होगी:

• हार्डवेयर विफलता और पावर विफलता
• नेटवर्क विफलताओं: कॉन्फ़िगरेशन त्रुटियों, फर्मवेयर घटता है
• लॉजिकल एरर्स: एल्गोरिथम कोडिंग एरर्स से लेकर आर्किटेक्चरल प्रॉब्लम्स जो सबसिस्टम और सिस्टम की सीमाओं पर पैदा होती हैं।
• सुरक्षा मुद्दे और संबंधित हमले और हैक, आंतरिक धोखाधड़ी सहित।

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

डेवलपर के दृष्टिकोण से, त्रुटियों और प्रदर्शन की समस्याओं का शीघ्र पता लगाने और उन्हें त्वरित प्रतिक्रिया देने के लिए पहुंच और गुणवत्ता की समस्या विमान में निहित है। इसके लिए दृष्टिकोण और मूल्यांकन के साधनों की आवश्यकता होती है। तो, चलो मात्रात्मक मैट्रिक्स प्राप्त करने की कोशिश करते हैं, जो विश्लेषण करते हैं कि परियोजना के विकास और संचालन के विभिन्न चरणों में, हम गुणवत्ता में काफी सुधार कर सकते हैं।

विधानसभा प्रणाली

सॉफ्टवेयर विकास में इंजीनियरिंग दृष्टिकोण और परीक्षण के महत्व के बारे में एक बार फिर आपको याद दिला दूं। एरलैंग / ओटीपी एक साथ दो टेस्ट फ्रेमवर्क प्रदान करता है: यूनीट और कॉमन टेस्ट।

कोड बेस की स्थिति और इसकी गतिशीलता के प्रारंभिक आकलन के लिए मैट्रिक्स के रूप में, आप सफल और समस्याग्रस्त परीक्षणों की संख्या, उनके निष्पादन समय और परीक्षणों के साथ कोड कवरेज के प्रतिशत का उपयोग कर सकते हैं। दोनों रूपरेखा जूनिट प्रारूप में परीक्षण के परिणाम को बचाने की अनुमति देते हैं।
उदाहरण के लिए, rebar3 और ct के लिए, rebar.config में निम्न पंक्तियाँ जोड़ें:

{cover_enabled, true}. {cover_export_enabled, true}. {ct_opts,[ {ct_hooks, [{cth_surefire, [{path, "report.xml"}]}]} ]}. 

सफल और असफल परीक्षणों की संख्या आपको एक ट्रेंड चार्ट बनाने की अनुमति देती है:

जिसे देखते हुए, आप टीम की गतिशीलता और परीक्षणों के प्रतिगमन का मूल्यांकन कर सकते हैं। उदाहरण के लिए, जेनकिंस में यह ग्राफ टेस्ट रिजल्ट एनालाइजर प्लगिन का उपयोग करके प्राप्त किया जा सकता है।

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

अनुप्रयोग मेट्रिक्स

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

अपनी परियोजनाओं में, मैं मेट्रिक्स के नाम के लिए ${application}.${metrics_type}.${name} जैसे टेम्पलेट का उपयोग करता हूं। यह नामकरण आपको मीट्रिक की सूची प्राप्त करने की अनुमति देता है

 messaging.systime_subs.messages.delivered = 1654 messaging.systime_subs.messages.proxied = 0 messaging.systime_subs.messages.published = 1655 messaging.systime_subs.messages.skipped = 3 

शायद अधिक मीट्रिक, यह समझना आसान है कि एक जटिल प्रणाली में क्या हो रहा है।

एर्मलैंग वीएम मेट्रिक्स

Erlang VM की निगरानी पर विशेष ध्यान दिया जाना चाहिए। इसे दुर्घटनाग्रस्त होने की विचारधारा सुंदर है, और ओटीपी के उचित उपयोग से निश्चित रूप से एर्लांग वीएम के अंदर एप्लिकेशन के गिरे हुए हिस्सों को उठाने में मदद मिलेगी। लेकिन एर्लैंग वीएम के बारे में खुद को मत भूलना, क्योंकि इसे गिराना मुश्किल है, लेकिन यह संभव है। सभी विकल्प संसाधनों की थकावट पर आधारित हैं। हम मुख्य सूची:

• परमाणु तालिका अतिप्रवाह।
  परमाणु पहचानकर्ता हैं जिनका प्राथमिक उद्देश्य कोड पठनीयता में सुधार करना है। एर्लांग वीएम उदाहरण की स्मृति में एक बार निर्मित परमाणु हमेशा के लिए रह जाते हैं, क्योंकि वे कचरा संग्रहकर्ता द्वारा साफ नहीं किए जाते हैं। ऐसा क्यों हो रहा है? कचरा कलेक्टर इस प्रक्रिया के डेटा के साथ प्रत्येक प्रक्रिया में अलग-अलग काम करता है, जबकि परमाणुओं को कई प्रक्रियाओं के डेटा संरचनाओं में वितरित किया जा सकता है।
  डिफ़ॉल्ट रूप से, 1,048,576 परमाणु बनाए जा सकते हैं। Erlang VM को मारने के बारे में लेखों में, आप आमतौर पर ऐसा कुछ पा सकते हैं।

  
  

   [list_to_atom(integer_to_list(I)) || I <- lists:seq(erlang:system_info(atom_count), erlang:system_info(atom_limit))] 

  
  

  इस आशय का चित्रण के रूप में। ऐसा लगता है कि एक कृत्रिम समस्या वास्तविक प्रणालियों में अप्राप्य है, लेकिन ऐसे मामले हैं ... उदाहरण के लिए, बाहरी एपीआई हैंडलर में, जब पार्सिंग अनुरोध, binary_to_atom/2 बजाय binary_to_atom/2 या list_to_atom/1 बजाय list_to_existing_atom/1 ।
  परमाणुओं की स्थिति की निगरानी के लिए निम्नलिखित मापदंडों का उपयोग किया जाना चाहिए:

  
  
  1. erlang:memory(atom_used) - परमाणुओं के लिए उपयोग की जाने वाली मेमोरी की मात्रा
  2. erlang:system_info(atom_count) - सिस्टम में निर्मित परमाणुओं की संख्या। erlang:system_info(atom_limit) साथ मिलकर erlang:system_info(atom_limit) , परमाणु उपयोग की गणना की जा सकती है।
  
  

• प्रक्रिया लीक।
  मैं तुरंत यह कहना चाहूंगा कि जब process_limit (+ P तक पहुँच जाता है, तो erlang) erlang vm तर्क क्रैश नहीं होता है, लेकिन यह एक आपातकालीन स्थिति में चला जाता है, उदाहरण के लिए, इससे जुड़ने की संभावना सबसे अधिक असंभव होगी। अंततः, लीक की गई प्रक्रियाओं को आवंटित करते समय उपलब्ध मेमोरी से बाहर निकलने से एर्गैंग vm क्रैश हो जाएगा।

  
  
  1. erlang:system_info(process_count) - इस समय सक्रिय प्रक्रियाओं की संख्या। erlang:system_info(process_limit) साथ मिलकर erlang:system_info(process_limit) , प्रक्रिया उपयोग की गणना की जा सकती है।
  2. erlang:memory(processes) - प्रक्रियाओं के लिए आवंटित मेमोरी
  3. erlang:memory(processes_used) - प्रक्रियाओं के लिए उपयोग की जाने वाली मेमोरी।
  
  

• मेलबॉक्स प्रक्रिया अतिप्रवाह।
  ऐसी समस्या का एक विशिष्ट उदाहरण है प्रेषक प्रक्रिया पुष्टि के लिए प्रतीक्षा किए बिना प्राप्तकर्ता प्रक्रिया को संदेश भेजता है, जबकि प्राप्तकर्ता प्रक्रिया में प्राप्त एक लापता या गलत पैटर्न के कारण इन सभी संदेशों को अनदेखा करता है। परिणामस्वरूप, मेलबॉक्स में संदेश जमा होते हैं। यद्यपि एरलैंग में प्रेषक को धीमा करने के लिए एक तंत्र है यदि हैंडलर प्रसंस्करण को नहीं संभाल सकता है, वैसे भी, उपलब्ध मेमोरी के समाप्त होने के बाद, वीएम क्रैश हो जाता है।
  यह समझने के लिए कि क्या मेलबॉक्स के अतिप्रवाह में कोई समस्या है, तो etop मदद करेगा।

  
  

   $ erl -name etop@host -hidden -s etop -s erlang halt -output text -node dest@host -setcookie some_cookie -tracing off -sort msg_q -interval 1 -lines 25 

  
  

  
  निरंतर निगरानी के लिए एक मीट्रिक के रूप में, आप समस्या प्रक्रियाओं की संख्या ले सकते हैं। उन्हें पहचानने के लिए, आप निम्नलिखित फ़ंक्शन का उपयोग कर सकते हैं:

  
  

   top_msq_q()-> [{P, RN, L, IC, ST} || P <- processes(), { _, L } <- [ process_info(P, message_queue_len) ], L >= 1000, [{_, RN}, {_, IC}, {_, ST}] <- [process_info(P, [registered_name, initial_call, current_stacktrace]) ] ]. 

  
  

  साथ ही, इस सूची को लॉग किया जा सकता है, फिर निगरानी से सूचना प्राप्त करने पर, समस्या का विश्लेषण सरल हो जाता है।

  
  

• लीक करने वाला बायनेरी।
  बड़े के लिए मेमोरी (64 से अधिक बाइट्स) बायनेरी को सामान्य ढेर में आवंटित किया जाता है। आबंटित ब्लॉक में एक संदर्भ काउंटर होता है, जिसमें उन प्रक्रियाओं की संख्या दर्शायी जाती है, जिन तक इसकी पहुँच होती है। काउंटर को रीसेट करने के बाद, सफाई होती है। सबसे सरल प्रणाली, लेकिन, जैसा कि वे कहते हैं, बारीकियां हैं। सिद्धांत रूप में, ढेर पर एक कचरा उत्पन्न करने वाली प्रक्रिया की संभावना है कि सिस्टम में सफाई करने के लिए पर्याप्त मेमोरी नहीं है।
  erlang:memory(binary) निगरानी के लिए एक मीट्रिक के रूप में कार्य करता है, जो बायनेरिज़ के लिए आवंटित मेमोरी दिखाती है।

  
  

इसलिए, vm के पतन की ओर ले जाने वाले मामलों को सुलझा लिया जाता है, हालांकि, उनके अलावा, यह कम महत्वपूर्ण मापदंडों की निगरानी करने में अच्छा नहीं है जो प्रत्यक्ष या अप्रत्यक्ष रूप से आपके अनुप्रयोगों के सही कामकाज को प्रभावित करते हैं:

• ETS द्वारा उपयोग की जाने वाली मेमोरी: erlang:memory(ets) ।
• संकलित मॉड्यूल के लिए मेमोरी: erlang:memory(code) ।
  यदि आपके समाधान गतिशील कोड संकलन का उपयोग नहीं करते हैं, तो इस विकल्प को बाहर रखा जा सकता है।
  मैं erlydtl का भी उल्लेख करना चाहूंगा। यदि आप गतिशील रूप से टेम्पलेट्स संकलित करते हैं, तो संकलन एक बीम बनाता है जिसे vm मेमोरी में लोड किया जाता है। यह मेमोरी लीक का कारण भी बन सकता है।
• सिस्टम मेमोरी: erlang:memory(system) । एर्गैंग रनटाइम मेमोरी खपत दिखाता है।
• कुल मेमोरी भस्म: erlang:memory(total) । यह प्रक्रियाओं और रनटाइम द्वारा खपत की गई मेमोरी की मात्रा है।
• कटौती के बारे में जानकारी: erlang:statistics(reductions) ।
• निष्पादन के लिए तैयार प्रक्रियाओं और बंदरगाहों की संख्या: erlang:statistics(run_queue) ।
• Vm का अपटाइम: erlang:statistics(runtime) उदाहरण आपको यह समझने की अनुमति देता है कि लॉग विश्लेषण के बिना कोई पुनरारंभ था या नहीं।
• नेटवर्क गतिविधि: erlang:statistics(io) ।

मेट्रिक्स को zabbix में सबमिट करना

हम एप्लिकेशन मेट्रिक्स और erlang vm मेट्रिक्स युक्त एक फाइल बनाएंगे, जिसे हम हर N सेकंड में अपडेट करेंगे। प्रत्येक erlang नोड के लिए, मीट्रिक फ़ाइल में उस पर चलने वाले एप्लिकेशन के मैट्रिक्स और erangang vm उदाहरण के मीट्रिक होने चाहिए। परिणाम कुछ इस तरह होना चाहिए:

 messaging.systime_subs.messages.delivered = 1654 messaging.systime_subs.messages.proxied = 0 messaging.systime_subs.messages.published = 1655 messaging.systime_subs.messages.skipped = 3 …. erlang.io.input = 2205723664 erlang.io.output = 1665529234 erlang.memory.binary = 1911136 erlang.memory.ets = 1642416 erlang.memory.processes = 23596432 erlang.memory.processes_used = 23598864 erlang.memory.system = 50883752 erlang.memory.total = 74446048 erlang.processes.count = 402 erlang.processes.run_queue = 0 erlang.reductions = 148412771 .... 

zabbix_sender का उपयोग करते zabbix_sender हम इस फ़ाइल को zabbix पर भेजेंगे, जहाँ एक चित्रमय प्रतिनिधित्व और स्वचालन और सूचना ट्रिगर बनाने की क्षमता पहले से ही उपलब्ध होगी।

अब जब हमारे पास मॉनिटरिंग सिस्टम और ऑटोमेशन ट्रिगर्स और नोटिफिकेशन इवेंट्स में मेट्रिक्स हैं, तो हमारे पास पूरी तरह कार्यात्मक स्थिति से सभी खतरनाक विचलन के लिए पहले से प्रतिक्रिया करके दुर्घटनाओं से बचने का एक मौका है।

लॉग की केंद्रीय सभा

जब किसी परियोजना में 1-2 सर्वर होते हैं, तो आप शायद केंद्रीय लॉग संग्रह के बिना भी रह सकते हैं, लेकिन जैसे ही कई सर्वर, क्लस्टर और वातावरण के साथ एक वितरित प्रणाली दिखाई देती है, लॉग की एकत्रित और सुविधाजनक देखने की समस्या को हल करना आवश्यक हो जाता है।

मेरी परियोजनाओं में लॉग लिखने के लिए, मैं लेगर का उपयोग करता हूं। अक्सर प्रोटोटाइप से उत्पादन के रास्ते पर, परियोजनाएं लॉग एकत्र करने के निम्नलिखित चरणों से गुजरती हैं:

• किसी स्थानीय फ़ाइल या यहां तक ​​कि stdout (lager_file_backend) के आउटपुट के साथ सबसे सरल लॉगिंग
• कलेक्टर के लिए लॉग का उपयोग, उदाहरण के लिए, syslogd और स्वचालित भेजने के केंद्रीकृत संग्रह। ऐसी योजना के लिए, lager_syslog उपयुक्त है।
  योजना का मुख्य नुकसान यह है कि आपको लॉग संग्रह सर्वर पर जाने की आवश्यकता है, आवश्यक लॉग के साथ फ़ाइल ढूंढें और किसी तरह डिबगिंग के लिए आवश्यक लोगों की तलाश में घटनाओं को फ़िल्टर करें।
• अभिलेखों को फ़िल्टर करने और खोजने की क्षमता के साथ भंडार में भंडारण के साथ लॉग का केंद्रीकृत संग्रह।

Minuses, pluses और मात्रात्मक मेट्रिक्स के बारे में जिन्हें बाद का उपयोग करके लागू किया जा सकता है, और हम एक विशिष्ट कार्यान्वयन के प्रिज्म में बात करेंगे - lager_clickhouse , जो मैं विकास के तहत अधिकांश परियोजनाओं में उपयोग करता हूं। lager_clickhouse बारे में कुछ शब्द। यह क्लिकहाउस में घटनाओं को बचाने के लिए लेगर बैकएंड है। फिलहाल, यह एक आंतरिक परियोजना है, लेकिन इसे खोलने की योजना है। जब lager_clickhouse का विकास हो रहा है, तो मुझे क्लिकहाउस की कुछ विशेषताओं को बायपास करना होगा, उदाहरण के लिए, क्लिकहाउस में लगातार अनुरोध करने से बचने के लिए इवेंट बफरिंग का उपयोग करें। स्थिर संचालन और अच्छे प्रदर्शन के साथ खर्च किए गए प्रयास।

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

लेकिन पेशेवरों, यह मुझे लगता है, सभी संभावित नुकसान पल्ला झुकना।

• आसान और त्वरित घटना खोज:

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

  स्क्रीनशॉट में लॉग देखने के इंटरफ़ेस का एक उदाहरण दिखाया गया है:
  

  
  

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

  
  
  • जब कोई महत्वपूर्ण त्रुटि होती है।
  • बड़े पैमाने पर त्रुटियों के मामले में (समय व्युत्पन्न एक निश्चित सीमा से अधिक तेजी से बढ़ता है)।
  • एक अलग मीट्रिक इवेंट जनरेशन की दर है, यानी इवेंट लॉग में कितने नए ईवेंट दिखाई देते हैं। आप समय की प्रति इकाई किसी परियोजना द्वारा उत्पन्न लॉग की अनुमानित राशि को लगभग हमेशा जान सकते हैं। यदि यह कई बार पार हो जाता है, तो सबसे अधिक संभावना है कि कुछ गलत हो रहा है।
  
  

आपातकालीन घटनाओं से निपटने के स्वचालन के विषय का और अधिक विकास लुआ लिपियों का उपयोग था। कोई भी डेवलपर या व्यवस्थापक प्रसंस्करण लॉग और मैट्रिक्स के लिए एक स्क्रिप्ट लिख सकता है। लिपियों में लचीलापन आता है और आपको वैयक्तिकृत ऑटोमेशन स्क्रिप्ट और नोटिफिकेशन बनाने की अनुमति मिलती है।

परिणाम

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

और आप एरलांग / एलिक्ज़िर पर समाधान कैसे संचालित करते हैं और उत्पादन में किन दिलचस्प मामलों में आपका सामना हुआ?