👩🏿‍🌾 🤦🏿 👨🏻‍🎨 लॉगिंग और क्वेरी ट्रेसिंग सर्वोत्तम अभ्यास हैं। यैंडेक्स रिपोर्ट 🧗🏻 👩🏻‍🏫 🏫

Yandex.Market के पास एक बड़ी माइक्रोसवर्क वास्तुकला है। बाजार के मुख्य पृष्ठ का ब्राउज़र अनुरोध विभिन्न सेवाओं (बैकेंड) में दर्जनों एम्बेडेड अनुरोधों को जन्म देता है जो विभिन्न लोगों द्वारा विकसित किए जाते हैं। ऐसी प्रणाली में, यह समझना मुश्किल हो सकता है कि अनुरोध किस कारण से गिर गया या प्रक्रिया में लंबा समय लगा।

अनातोली ओस्त्रोवस्की megatolyaयह बताता है कि उनकी टीम ने इस समस्या को कैसे हल किया और शेयर बाजार के लिए विशिष्ट व्यवहार करती है, लेकिन आम तौर पर किसी भी महान सेवा के लिए प्रासंगिक है। उनकी रिपोर्ट काफी कम समय में एक नए बाजार को तैनात करने के अपने अनुभव पर आधारित है। कई वर्षों के लिए, टोलिया ने बाजार में इंटरफ़ेस विकास टीम का नेतृत्व किया, और अब वह मानव रहित वाहनों की दिशा में आगे बढ़ गया है।

- हमारे सभी मार्केटप्लेस सामान्य सिद्धांतों के अनुसार बनाए गए हैं। यह एक बड़ी एकल प्रणाली है। लेकिन अगर हम फ्रंटएंड के बारे में बात करते हैं, तो, उपयोगकर्ता के दृष्टिकोण से, एप्लिकेशन पूरी तरह से अलग हैं।

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

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

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

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

इस विषय में गोता लगाने के कई चरण हैं। मैं उनमें से प्रत्येक के बारे में संक्षेप में बात करूंगा।

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

एकीकृत अनुरोध पहचान प्रणाली

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

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

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

cURL

समस्या को पुन: उत्पन्न करने के लिए, हम CURL उपयोगिता का उपयोग करते हैं। यह एक कंसोल उपयोगिता है जो नेटवर्क अनुरोध - http और https बनाती है। cURL कई और अलग-अलग प्रोटोकॉल का समर्थन करता है, लेकिन वेब विकास करते समय, यह मान लेना आसान है कि यह http (s) अनुरोधों के साथ काम करने का एक उपकरण है।

CURL टीम से परिचित होने के लिए, आप किसी भी साइट पर जा सकते हैं, फिर नेटवर्क पर जाएं और cURL के रूप में किसी भी अनुरोध को कॉपी कर सकते हैं। परिणाम इतनी बड़ी रेखा है:

यदि आप इसे जानने की कोशिश करते हैं, तो चिंता की कोई बात नहीं है। आइए इसे अलग ले जाने की कोशिश करते हैं।

यहाँ market.yandex.ru से अनुरोध है।

यहां एक उपयोगकर्ता-एजेंट जोड़ा गया है, जो पहले से ही बहुत अधिक स्थान लेता है।

वास्तव में, बाकी कुकीज़ हैं। यैंडेक्स कोड में उनमें से बहुत सारे हैं। सिलसिलेवार रूप में, उनका बहुत ही शानदार रूप है। वास्तव में, उनके अलावा और कुछ नहीं है।

तो cURL किसके लिए उपयोगी है? यदि आप इसे खुद से कॉपी करते हैं और इसे चलाते हैं, तो आपको वही market.yandex.ru पेज दिखाई देगा जैसा मैंने किया था - केवल वह कंप्यूटर जिस पर वह चल रहा था वह अलग होगा। बेशक, कुछ दुष्प्रभाव आईपी पते में अंतर दे सकते हैं, लेकिन सामान्य तौर पर वे समान अनुरोध होंगे। हम उसी परिदृश्य को पुन: पेश करेंगे।

प्रत्येक बार ऐसे CURL प्रश्नों का आविष्कार न करने के लिए, आप npm-package प्रारूप-कर्ल का उपयोग कर सकते हैं।

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

इसलिए, देव वातावरण में हमारे सभी लॉग में भी cURL अनुरोध होते हैं।

हमने सीधे ब्राउज़र में बैकएंड cURL अनुरोधों को भी लॉग इन किया, यह देखने के लिए कि ब्राउज़र कंसोल को देखे बिना हम अपने बैकेंड पर कैसे जाते हैं।

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

Clickhouse

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

इस स्थिति में, ClickHouse चयन उदाहरण सादा एसक्यूएल है। यहां हम आज के लिए स्थिति कोड के लिए अनुरोधों की संख्या दिखाते हैं।

नतीजतन, हमारे पास 180 हजार दो सौ और सात पांच सौ होंगे, और शेष स्थिति कोड, उदाहरण के लिए, हमारे लिए दिलचस्प नहीं हैं। लेकिन हम इसे दिलचस्प तरीके से कैसे इस्तेमाल कर सकते हैं?

हम कह सकते हैं कि कुल उत्तर के अनुपात में दो सौ का अनुपात सेवा स्तर संकेतक है, जो इस सवाल का जवाब देता है कि हमारे आवेदन स्थिति कोड के संदर्भ में कितनी अच्छी तरह काम करते हैं। हालांकि सरल, वह पहले से ही कुछ के बारे में बात कर रहा है।

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

उदाहरण के लिए, भुगतान त्रुटियां हमारे लिए महत्वपूर्ण हैं, लेकिन इस मामले में वे शून्य पर लौट आएंगे - यह भाग्यशाली है :)

आप अपने लॉग को इतने सुविधाजनक रूप में कैसे बना सकते हैं और उन्हें SQL के माध्यम से लिया जा सकता है?

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

यह हमारे लिए कई गुना अधिक काम करता है - हम एक विशिष्ट उदाहरण से ऐसे लॉग के रिमोट स्टोरेज सर्वर पर लॉग भेजते हैं।

ट्रेस का अनुरोध करें

"क्वेरी ट्रेसिंग" की कोई अवधारणा नहीं है। यह शब्द Google द्वारा गढ़ा गया था।

यदि आप "क्वेरी ट्रेसिंग" के लिए इंटरनेट पर खोज करते हैं, तो आप ट्रेसरूट कमांड देखेंगे। शायद यह क्वेरी ट्रेसिंग के समान है।

यहां तक कि एक सांत्वना कार्यक्रम भी है, और यहां मैंने वेबसाइट के लिए इसे लाया हैlyly.ru (एक सेवा जिसे हमने पिछले वसंत में विकसित किया था)। यह समझने में मदद करता है कि बैलेंसर के पास जाने से पहले अनुरोध किन मशीनों और सर्वरों के माध्यम से होता है, जो या तो लेआउट या किसी अन्य चीज से जवाब देगा।

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

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

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

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

यहाँ विपरीत स्थिति है। बैकएंड ने कहा कि कुछ गलत था और साथ ही मेटा-इनफॉर्मेशन में लिखा था कि वास्तव में क्या हुआ है - किसी तरह का स्टैक ट्रेस दिखाई दिया।

अपने आप को एक ही उपकरण कैसे बनाएं?

यहाँ सबसे महत्वपूर्ण बात डेटाबेस है। यदि आपके पास सेवा के साथ कुछ कार्यों के डेटाबेस में सबसे सरल "INSERT INTO" है, तो बाद में आप आवश्यक घटनाओं को खोजने के लिए कम से कम SQL का उपयोग कर सकते हैं। और यदि आवश्यक हो, तो आप इसके लिए एक इंटरफ़ेस बना सकते हैं।

रेखांकन

यह एक बहुत ही दिलचस्प विषय है, मैं आज इस पर विस्तार से ध्यान नहीं दूंगा, निश्चित रूप से, :)

लॉगिंग के बारे में बात करते हैं। हमारे पास बहुत सारे ग्राफ हैं, हम उन्हें देखते हैं जब हम कुछ रोल करते हैं - और समय में ऐसा शोर होता है।

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

निगरानी

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

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

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

सारांश

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

पढ़ने की सलाह देता हूं ।

लॉगिंग और क्वेरी ट्रेसिंग सर्वोत्तम अभ्यास हैं। यैंडेक्स रिपोर्ट