वितरित अनुरेखण: अतीत, वर्तमान और भविष्य

वितरित ट्रेसिंग एक विभाजनकारी विषय है। एक बार प्रत्येक KubeCon की अग्रणी , प्रौद्योगिकी से अवलोकन क्षमता में क्रांति लाने की उम्मीद की गई थी।

5 वर्षों में तेजी से आगे बढ़ते हुए, प्रचार कुछ हद तक कम हो गया है, दर्द के बारे में बहुत अधिक चर्चा हो रही है, और गोद लेना मध्यम है। इस बीच, प्रौद्योगिकी के विस्तार और मानकीकरण के आसपास लगातार गतिविधि जारी है - ओपन टेलीमेट्री (ओपनट्रेसिंग पर आधारित) कुबेरनेट्स के बाद दूसरी सबसे बड़ी सीएनसीएफ परियोजना है। तो डिस्ट्रीब्यूटेड ट्रेसिंग के साथ क्या डील है? क्या इसे तुरंत लागू करना चाहिए या इंतजार करके देखना चाहिए?

इस लेख में, आइए वितरित अनुरेखण के बारे में गहराई से जानें

1. डिस्ट्रीब्यूटेड ट्रेसिंग के बारे में क्या खास है और हमें इसकी आवश्यकता क्यों है?
2. आज वितरित अनुरेखण में क्या समस्याएँ हैं?
3. आगामी विकास क्या हैं और वे मौजूदा चुनौतियों का समाधान कैसे करते हैं?

परिचय - वितरित अनुरेखण कैसे काम करता है

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

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

एक वितरित ट्रेस अनुरोध पथ का प्रतिनिधित्व कैसे करता है

हमें सबसे पहले वितरित अनुरेखण की आवश्यकता क्यों है?

वितरित ट्रेसिंग अद्वितीय है क्योंकि यह अवलोकन के लिए इकाई के रूप में अनुरोध पर केंद्रित है। मॉनिटरिंग/मेट्रिक्स प्लेटफ़ॉर्म में, एक घटक (उदाहरण के लिए, एक सेवा, होस्ट) मूलभूत इकाई है जिसका अवलोकन किया जा रहा है। कोई भी इन प्लेटफार्मों से समय के साथ समग्र रूप से इस इकाई के व्यवहार के बारे में प्रश्न पूछ सकता है। उदाहरण के लिए, किसी विशिष्ट समय सीमा में इस सेवा का स्वास्थ्य/थ्रूपुट/त्रुटि दर क्या है?

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

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

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

वितरित अनुरेखण का विकास

पिछले दशक में वितरित सॉफ़्टवेयर आर्किटेक्चर को व्यापक रूप से अपनाने के कारण वितरित ट्रेसिंग का महत्व बढ़ गया है।

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

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

- डिस्ट्रिब्यूटेड ट्रेसिंग इन प्रैक्टिस, ओ'रेली मीडिया

इन माइक्रोसर्विसेज आर्किटेक्चर में, हर एक अनुरोध कई (10 या यहां तक कि 100 माइक्रोसर्विसेज) को प्रभावित करता है, जिससे बीच में कई नेटवर्क कॉल होते हैं। उबर के माइक्रोसर्विसेज आर्किटेक्चर के लिए नीचे देखें, जिसमें 3000+ सेवाएँ हैं।

2018 से उबर का माइक्रोसर्विसेज आर्किटेक्चर। स्रोत: https://www.uber.com/en-IN/blog/microservice-architecture/

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

• 2010 में जारी Google का डैपर पेपर वितरित ट्रेसिंग की शुरुआत थी

  
  

• अगले कुछ वर्षों में, दो और कंपनियों ने अपने स्वयं के वितरित ट्रेसिंग सिस्टम (2012 में ट्विटर ओपन-सोर्स जिपकिन और 2017 में उबर ओपन-सोर्स जैगर) को ओपन-सोर्स किया। ज़िपकिन और जैगर आज भी सबसे लोकप्रिय वितरित ट्रेसिंग टूल में से एक बने हुए हैं

  
  

• 2016 से, ओपनट्रेसिंग परियोजना के माध्यम से घटकों में वितरित ट्रेसिंग को मानकीकृत करने का एक महत्वपूर्ण प्रयास किया गया है। ओपनट्रेसिंग अंततः 2019 में ओपनटेलीमेट्री बन गया। ओपनटेलीमेट्री व्यापक रूप से लोकप्रिय है और विश्व स्तर पर इसके हजारों योगदानकर्ता हैं

  
  

• अब वितरित ट्रेसिंग को व्यापक रूप से मेट्रिक्स और लॉग के साथ अवलोकन का तीसरा "स्तंभ" माना जाता है। अधिकांश प्रमुख निगरानी और अवलोकन संबंधी खिलाड़ी अपने उत्पादों के हिस्से के रूप में वितरित ट्रेसिंग उपकरण प्रदान करते हैं।

वितरित अनुरेखण की स्थिति: सिद्धांत बनाम वास्तविकता

हालाँकि, वादे, उत्साह और सामुदायिक प्रयास के बावजूद, आज वितरित ट्रेसिंग को अपनाना लगभग ~25% है। माइक्रोसर्विसेज आर्किटेक्चर पर ऐसी कंपनियों को ढूंढना असामान्य नहीं है जो लॉग और मेट्रिक्स के साथ काम कर रही हैं, भले ही उन्हें स्पष्ट रूप से वितरित ट्रेसिंग की आवश्यकता हो।

साथ ही, आज दुनिया में मीन-टाइम-टू-रिज़ॉल्यूशन उत्पादन त्रुटियाँ बढ़ रही हैं। 73% कंपनियों की रिपोर्ट है कि आज उत्पादन संबंधी समस्याओं को हल करने में एक घंटे से अधिक का समय लगता है ।

किसी भी डेवलपर से पूछें कि उनके जीवन में सबसे दर्दनाक क्षण क्या हैं और वे उत्पादन में सेव-1 त्रुटि को डीबग करने में लगने वाले समय के बारे में बात करेंगे, ऐसा प्रतीत होता है कि कुछ सौ लोग अपनी गर्दन झुका रहे थे।

ऐसा लगता है, कि कोई भी कंपनी जो अपने एमटीटीआर (जो लगभग हर कंपनी है) की परवाह करती है, उसे वितरित ट्रेसिंग का उपयोग करना चाहिए, और इस माहौल में इसे अपनाने में तेजी आनी चाहिए। लेकिन वास्तविक संख्याएँ इसका समर्थन नहीं करतीं - तो क्या देता है?

आज वितरित अनुरेखण की चुनौतियाँ

आज वितरित ट्रेसिंग के साथ कई समस्याएं हैं जिन्हें कंपनियों को मूल्य प्राप्त करने के लिए दूर करना होगा - जिनमें से सभी पर मुख्यधारा की कथा में व्यापक रूप से चर्चा नहीं की जाती है।

1. कार्यान्वयन कठिन है!

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

कोई केवल एक ही सेवा के साथ शुरुआत नहीं कर सकता - जैसा कि कोई निगरानी या लॉगिंग के साथ कर सकता है - और मूल्य का एहसास कर सकता है। वितरित ट्रेसिंग के लिए प्रयोग करने योग्य ट्रेस उत्पन्न करने के लिए सेवाओं के सामूहिक सेट में इंस्ट्रूमेंटेशन की आवश्यकता होती है।

इसके लिए अपनी सेवाओं में बदलाव करने के लिए कई टीमों और सेवा मालिकों के बीच समन्वय की आवश्यकता होती है। तो यह एक संगठनात्मक समस्या बन जाती है - कल्पना करें कि आपको मूल्य का एहसास होने से पहले कई महीनों तक सैकड़ों टीमों को अपनी सेवाएं प्रदान करनी होंगी।

आज वितरित ट्रेसिंग के साथ यह सबसे बड़ी चुनौती है।

2. जटिल नमूनाकरण निर्णयों की आवश्यकता

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

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

लागत की इस समस्या से निपटने के लिए, आज सभी वितरित ट्रेसिंग प्रणालियाँ नमूनाकरण का उपयोग करती हैं और केवल निशानों का एक सबसेट रिकॉर्ड करती हैं। आज व्यवहार में सामान्य नमूना दरें 0.1% से 2% के बीच हैं। तर्क यह है कि 1% नमूने भी प्रदर्शन बाधाओं की एक अच्छी समग्र तस्वीर देने के लिए पर्याप्त हैं।

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

3. लेकिन नमूनाकरण सार्थक रूप से मूल्य को कम कर देता है

आइए मान लें कि एक कंपनी प्रत्येक सेवा/घटक को इंस्ट्रुमेंट करने के प्रयास से गुजरती है और फिर यह सुनिश्चित करने के लिए नमूनाकरण रणनीति तय करती है कि वे बैंक को न तोड़ें।

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

एक डेवलपर के अनुभव की कल्पना करें - "मुझे वह समस्या नहीं मिल रही है जिसके बारे में मुझे पता है कि वह मौजूद है। मैंने त्रुटि उत्पन्न की है, लेकिन मुझे संबंधित ट्रेस नहीं मिल रहा है"।

तो क्या होता है? डेवलपर्स वितरित ट्रेसिंग डेटा की गुणवत्ता पर भरोसा करना बंद कर देते हैं और डिबगिंग/समस्या निवारण के लिए अपने नियमित तरीकों पर वापस लौट आते हैं (यानी, लॉग का उपयोग करना)

4. डेवलपर का उपयोग कम आवृत्ति वाला है

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

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

एक सामान्य कंपनी में, प्रदर्शन संबंधी समस्याएँ कुल का <10% होने की संभावना होती है। तो वास्तव में, वितरित ट्रेसिंग केवल मुद्दों के इस छोटे खंड के लिए उपयोगी है।

औसत डेवलपर जो किसी सेवा को शिप करता है और उसका मालिक है, वह वर्ष में शायद 2-3 बार वितरित ट्रेसिंग टूल का उपयोग कर रहा है।

इन सभी चुनौतियों का असर

सारांश:

1. वितरित ट्रेसिंग को लागू करना कठिन है
2. वितरित ट्रेसिंग को लागत नियंत्रित करने के लिए व्यापक नमूने की आवश्यकता है
3. लेकिन नमूनाकरण से मूल्य काफी कम हो जाता है
4. परिणामस्वरूप, डेवलपर्स केवल विषम एकमुश्त प्रदर्शन उपयोग के मामले के लिए ट्रेसिंग का उपयोग करते हैं

यह सब वितरित ट्रेसिंग के लिए आरओआई मामले को काफी अस्पष्ट बनाता है।

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

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

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

वितरित अनुरेखण का भविष्य

बिना किसी कोड परिवर्तन के त्वरित उपकरणीकरण

एक एजेंट को शामिल करने और कोड में बदलाव किए बिना एक ही बार में संपूर्ण वितरित सिस्टम (सभी सेवाओं, घटकों) को कवर करने में सक्षम होने की कल्पना करें।

यह अगले 2-3 वर्षों में वास्तविक रूप से संभव दिखता है।

ओपनटेलीमेट्री की ऑटो-इंस्ट्रूमेंटेशन लाइब्रेरी पहले से ही कुछ प्रोग्रामिंग भाषाओं के लिए इसे सक्षम करती है (हालांकि गो जैसी संकलित भाषाओं में यह कम है)। समानांतर में, बिना किसी कोड परिवर्तन के सिस्टम-वाइड इंस्ट्रूमेंटेशन को सक्षम करने के लिए eBPF जैसी प्रौद्योगिकियां विकसित हो रही हैं। दोनों के बीच, हम सुरक्षित रूप से उम्मीद कर सकते हैं कि इंस्ट्रूमेंटेशन समस्या कुछ वर्षों में हल हो जाएगी।

नमूनाकरण एआई-आधारित रुचि के अनुरोधों के चयन का मार्ग प्रशस्त करता है

एलएलएम की दुनिया में, यादृच्छिक नमूनाकरण अंधकार युग के अवशेष जैसा लगने लगता है। आदर्श रूप से, हमें 100% निशानों को देखने, असामान्य दिखने वाली किसी भी चीज़ की पहचान करने और भविष्य की जांच के लिए उसे संग्रहीत करने में सक्षम होना चाहिए। कोई और यादृच्छिक नमूनाकरण नहीं.

यदि हम इसके बारे में सोचते हैं, तो हमें वास्तव में ~95% "खुश अनुरोधों" की परवाह नहीं है। हम केवल ~5% विसंगतिपूर्ण निशानों की परवाह करते हैं - त्रुटियाँ, अपवाद, उच्च विलंबता, या कुछ प्रकार की सॉफ्ट त्रुटियाँ। तो हमें बस 100% देखने और दिलचस्प 5% चुनने का एक तरीका चाहिए।

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

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

ओपनटेलीमेट्री में एक टेल-आधारित सैंपलिंग कलेक्टर है, हालांकि, यह अभी तक परिपक्व नहीं है और इसमें कई स्केलेबिलिटी चुनौतियां हैं (ऊपर उल्लिखित समस्या के कारण)। इस बीच, ZeroK.ai सहित कई कंपनियां विसंगति का पता लगाने को कुशल और स्केलेबल बनाने के लिए AI का उपयोग करने पर काम कर रही हैं।

इस क्षेत्र में विकास की तेज गति के साथ, हम उम्मीद कर सकते हैं कि अगले 3-5 वर्षों में यह समस्या भी हल हो जाएगी।

"समृद्ध" वितरित निशानों का उद्भव जो सभी डिबगिंग को सक्षम बनाता है

ट्रेसिंग की अगली पीढ़ी में एक सच्ची छलांग तब होगी जब ट्रेसिंग "केवल प्रदर्शन के मुद्दों" के दायरे से "सभी मुद्दों" तक विकसित होगी। तभी वितरित अनुरेखण की वास्तविक शक्ति उजागर होती है।

इसे संभव बनाने के लिए, प्रत्येक ट्रेस का समृद्ध संदर्भ होना आवश्यक है।

एक ऐसे परिदृश्य की कल्पना करें जहां प्रत्येक ट्रेस में प्रत्येक स्पैन में:

• अनुरोध एवं प्रतिक्रिया पेलोड (पीआईआई मास्किंग के साथ)

• किसी भी अपवाद के लिए स्टैक निशान

• लॉग्स

• कुबेरनेट्स घटनाएँ

• पॉड बताता है

• और उस अवधि में जो कुछ भी घटित हुआ

  
  

सभी एक एकीकृत, निर्बाध प्रवाह में।

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

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

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

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

सारांश

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

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

हालाँकि, इस क्षेत्र में कई रोमांचक विकास हो रहे हैं जिनसे उम्मीद है कि ट्रेसिंग आज की तुलना में आसान, सरल और अधिक शक्तिशाली हो जाएगी, जिससे भविष्य में अवलोकन और अधिक सहज हो जाएगा।