हम ग्रेफाइट और मोइरा के साथ समस्याग्रस्त रिलीज़ कैसे पाते हैं। Yandex.Money का अनुभव करें

नमस्कार, हेब्र! लंबी छुट्टियों के बाद पर्याप्त आराम करने के बाद, हम सभी उपलब्ध तरीकों से आपको फिर से अच्छा करने के लिए तैयार हैं। आईटी विभाग के सहकर्मियों के पास हमेशा बताने के लिए कुछ होता है, और आज हम आपके साथ जावाजैम बैठक के सिकंदर प्रिज़ोव, यैंडेक्स.मनी सिस्टम एडमिनिस्ट्रेटर की एक रिपोर्ट साझा कर रहे हैं।

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

- सभी को नमस्कार, मेरा नाम अलेक्जेंडर प्रेज़ोव है, मैं Yandex.Money में ऑपरेशन स्वचालन विभाग में काम करता हूं, और आज मैं आपको बताऊंगा कि हम कैसे इकट्ठा करते हैं, प्रक्रिया करते हैं, हमारे सिस्टम के बारे में जानकारी का विश्लेषण करते हैं।

आप शायद सोच रहे होंगे कि रिपोर्ट को दूसरा तरीका क्यों कहा जाता है (बैठक पर रिपोर्ट का नाम एड है।)। सब कुछ काफी सरल है। DevOps के केंद्र में कई सिद्धांत हैं जो सशर्त रूप से तीन समूहों में विभाजित हैं।

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

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

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

हम क्या मैट्रिक्स एकत्र करते हैं?

हम तीन स्तरों से मैट्रिक्स एकत्र करते हैं।

व्यवसाय स्तर में संकेतक शामिल हैं जो किसी भी व्यावसायिक कार्यों के दृष्टिकोण से दिलचस्प हैं। उदाहरण के लिए, हम प्रश्नों के उत्तर प्राप्त कर सकते हैं जैसे कि हमने कितने उपयोगकर्ताओं को पंजीकृत किया है, कितनी बार उपयोगकर्ता हमारे सिस्टम में लॉग इन करते हैं, हमारे मोबाइल एप्लिकेशन में कितने सक्रिय उपयोगकर्ता हैं।

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

और अंत में, बुनियादी ढांचे का स्तर । यहाँ सब कुछ बहुत स्पष्ट है। इन मेट्रिक्स का उपयोग करके, हम उपभोग किए गए संसाधनों की मात्रा का अनुमान लगा सकते हैं कि उनकी भविष्यवाणी कैसे करें और बुनियादी ढांचे से संबंधित समस्याओं की पहचान कैसे करें।

अब, संक्षेप में, मैं बताऊंगा कि हम कैसे भेजते हैं, प्रक्रिया करते हैं, और हम इन मैट्रिक्स को कहाँ संग्रहीत करते हैं। आवेदन के आगे, हमारे पास एक मैट्रिक्स कलेक्टर है। हमारे मामले में, यह हेका सेवा है, जो यूडीपी पोर्ट को सुनता है और इनपुट के लिए स्टैट्सड प्रारूप में मीट्रिक की अपेक्षा करता है।

StatsD का प्रारूप इस प्रकार है:

यही है, हम मीट्रिक के नाम को निर्धारित करते हैं, इस मीट्रिक के मूल्य को इंगित करते हैं, यह 1, 26 और इसी तरह का है, और इसके प्रकार को इंगित करता है। कुल मिलाकर, StatsD में लगभग चार या पाँच प्रकार होते हैं। यदि आप अचानक रुचि रखते हैं, तो आप इन प्रकारों के विवरण को विस्तार से देख सकते हैं।

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

हम मीट्रिक का विश्लेषण कैसे करते हैं?

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

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

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

कोई बग नहीं - हम रिलीज प्रक्रिया को धीमा कर देते हैं
बग के साथ - उपयोगकर्ता स्नेह

इस समस्या की समझ के साथ, हमने यह पता लगाने का निर्णय लिया कि क्या यह निर्णय लेने की प्रक्रिया को स्वचालित करना संभव है कि क्या कोई समस्या समस्याग्रस्त है या नहीं।

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

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

लोचदार क्यों नहीं?

सबसे पहले, हम चिंतित थे कि हम इलास्टिक से डेटा जल्दी से प्राप्त करने में सक्षम नहीं हो सकते हैं। ऐसे मामले हैं, उदाहरण के लिए, तनाव परीक्षण के दौरान, जब हमारे पास डेटा का एक बड़ा प्रवाह होता है, और क्लस्टर सामना नहीं कर सकता है, और अंततः, लगभग 10-15 मिनट के लिए लॉग भेजने में देरी होती है।

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

हमने सोचा, क्यों न किसी तरह के मेट्रिक्स बनाने की कोशिश की जाए, जिसके आधार पर हम यह तय कर सकें कि रिलीज समस्याग्रस्त है या नहीं। उसी समय, हम कोड बेस में बदलाव करने के लिए अपने डेवलपर्स को बोझ नहीं बनाना चाहते थे। और, जैसा कि यह हमें लगता है, हमने log4j में एक अतिरिक्त परिशिष्ट जोड़कर एक शानदार समाधान पाया।

यह कैसा दिखता है

<?xml version="1.0" encoding="UTF-8" ?> <Configuration status="warn" name="${sys:application.name}" > <Properties> <Property name="logsCountStatsDFormat">app_name.logs.%level:1|c</Property> </Properties> ... <Appenders> <Socket name="STATSD" host="127.0.0.1" port="8125" protocol="UDP"> <PatternLayout pattern="${logsCountStatsDFormat}"/> </Socket> </Appenders> <Loggers> <Root level="INFO"> <AppenderRef ref="STATSD"/> </Root> </Loggers> </Configuration> 

सबसे पहले, हम उस मीट्रिक का प्रारूप निर्धारित करते हैं जिसे हम भेज रहे हैं। निम्नलिखित एक अतिरिक्त परिशिष्ट है जो उस प्रारूप में रिकॉर्ड भेजता है जिसे हमने UDP पर 8125 पोर्ट करने के लिए ऊपर दिया है, अर्थात हेका को। यह हमें क्या देता है? Log4j निर्दिष्ट रिकॉर्ड स्तर ERROR, INFO, WARN, और इसी तरह प्रत्येक लॉग प्रविष्टि के लिए काउंटर का एक मीट्रिक भेजता है।

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

स्वचालन

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

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

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

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

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

मेरे लिए शायद यही है। आपका धन्यवाद

उपयोगी लिंक

Log4j गिनती-appender
मोइरा