विगतमा, जब हामीले ब्याकइन्डको बारेमा कुरा गर्यौं, हामीले सामान्यतया एउटा ठूलो एप्लिकेसनलाई एकल, ठूला डाटाबेसको साथ उल्लेख गर्यौं, र लगिङ अनुगमनको लागि पर्याप्त थियो। अब, Kubernetes जस्ता प्रविधिहरूको लागि धन्यवाद, माइक्रोसर्भिसेसहरू मानक भएका छन्। अनुप्रयोगहरू धेरै संख्यामा र वितरित छन्, र परम्परागत लगिङ अब हाम्रो अनुप्रयोगहरूमा समस्याहरू डिबग गर्न र निदान गर्न पर्याप्त छैन।
निगरानी व्यवस्थित गर्नको लागि एक उत्कृष्ट समाधान OpenTelemetry हो - एक आधुनिक टुलकिट जुन डिबगिङ र वितरित प्रणालीहरूको प्रदर्शन विश्लेषणको लागि प्रयोग गर्न सकिन्छ।
यो लेख ब्याकएन्ड अप्टिमाइजेसनमा आफ्नो ज्ञान विस्तार गर्न खोज्ने IT पेशेवरहरूको लागि हो। तल, हामी OpenTelemetry के हो, यसको मुख्य अवधारणाहरू, र यसले समाधान गर्न मद्दत गर्ने समस्याहरूको विवरण दिनेछौं। यदि तपाइँ कसरी OpenTelemetry ले ब्याकएन्ड प्रणालीहरूको निगरानी र डिबगिङको लागि तपाइँको दृष्टिकोण परिवर्तन गर्न सक्नुहुन्छ, तिनीहरूको विश्वसनीयता र दक्षता बृद्धि गर्नमा रुचि राख्नुहुन्छ भने - पढ्नुहोस्।
ठूला प्राविधिक कम्पनीहरूले पहिलो पटक २००० को दशकको अन्तमा वितरित लगिङ र ट्रेसिङको चुनौती सामना गरे। 2010 मा, गुगलले एउटा पेपर प्रकाशित गर्यो,
2014 मा, Kubernetes देखा पर्यो, जसले माइक्रोसर्भिसेस र अन्य क्लाउड-वितरण प्रणालीहरूको विकासलाई महत्त्वपूर्ण रूपमा सरल बनायो। यसले धेरै कम्पनीहरूलाई माइक्रो सेवाहरूमा वितरित लगिङ र ट्रेसिङमा समस्याहरूको सामना गर्न निम्त्यायो। वितरित ट्रेसिङलाई मानकीकरण गर्न, CNCF द्वारा अपनाएको OpenTracing मानक, र Google को OpenCensus परियोजना सिर्जना गरिएको थियो।
2019 मा, OpenTracing र OpenCensus परियोजनाहरूले OpenTelemetry नाम अन्तर्गत मर्जरको घोषणा गरे। यो प्लेटफर्मले धेरै वर्षहरूमा संचित उत्कृष्ट अभ्यासहरूलाई संयोजन गर्दछ, कुनै पनि प्रणालीमा ट्रेसिङ, लगिङ, र मेट्रिक्सको सहज एकीकरणलाई अनुमति दिँदै, तिनीहरूको जटिलताको पर्वाह नगरी।
आज, OpenTelemetry एक परियोजना मात्र होइन; यो टेलिमेट्री डाटा सङ्कलन र प्रसारणको लागि एक उद्योग मानक हो। यो Google र Microsoft जस्ता विशेषज्ञहरू र बजार-अग्रणी कम्पनीहरूको समुदायद्वारा विकसित र समर्थित छ। एकीकरण र प्रयोग प्रक्रियालाई सरल बनाउन नयाँ क्षमताहरू प्राप्त गर्दै, परियोजना विकसित हुन जारी छ।
OpenTelemetry अभ्यासहरू र उपकरणहरूको एक विस्तृत सेट हो जसले बाह्य संसारसँग अन्तरक्रिया गर्न अनुप्रयोगले कुन संकेतहरू उत्पन्न गर्न सक्छ, र कसरी यी सङ्केतहरू सङ्कलन गर्न सकिन्छ र अनुप्रयोगहरूको अवस्था र प्रणालीलाई समग्र रूपमा निगरानी गर्नको लागि भिजुअलाइज गर्न सकिन्छ भनेर परिभाषित गर्दछ। तीन मुख्य प्रकारका संकेतहरू ट्रेसिङ, लगिङ र मेट्रिक्स सङ्कलन हुन्।
** प्रत्येक घटकलाई नजिकबाट हेरौं: \
OpenTelemetry ले सञ्चालन सन्दर्भहरूको अवधारणा परिचय गर्दछ। सन्दर्भले मुख्य रूपमा विशेषताहरू समावेश गर्दछ जस्तै `trace_id`
(हालको सञ्चालनको लागि पहिचानकर्ता) र `span_id`
(उप-अनुरोधको लागि पहिचानकर्ता, प्रत्येक उप-अनुरोधको पुन: प्रयासको साथ अद्वितीय `span_id`
)।
थप रूपमा, सन्दर्भमा स्थिर जानकारी समावेश हुन सक्छ, जस्तै नोड नाम जहाँ अनुप्रयोग तैनात गरिएको छ वा वातावरण नाम (prod/qa)। यी क्षेत्रहरू, OpenTelemetry शब्दावलीमा स्रोतहरू भनेर चिनिन्छ, सजिलो खोज योग्यताका लागि प्रत्येक लग, मेट्रिक, वा ट्रेसमा संलग्न हुन्छन्। सन्दर्भहरूले हालको अन्तिम बिन्दु ( `http_path: "GET /user/:id/info"`
) को पहिचानकर्ता जस्तै गतिशील डेटा पनि समावेश गर्न सक्छ, जुन लग, मेट्रिक्स, वा ट्रेसहरूको समूहहरूमा चयन रूपमा संलग्न गर्न सकिन्छ।
OpenTelemetry सन्दर्भहरू सन्दर्भ प्रचार प्रोटोकलहरू प्रयोग गरेर विभिन्न अनुप्रयोगहरू बीच पास गर्न सकिन्छ। यी प्रोटोकलहरूमा हेडर सेटहरू हुन्छन् जुन प्रत्येक HTTP वा gRPC अनुरोध वा लामहरूका लागि सन्देशहरूको हेडरहरूमा थपिन्छन्। यसले डाउनस्ट्रीम एपहरूलाई यी हेडरहरूबाट सञ्चालन सन्दर्भलाई पुन: निर्माण गर्न अनुमति दिन्छ।
यहाँ सन्दर्भ प्रचारका केही उदाहरणहरू छन्:
B3-प्रसार यो हेडरहरूको सेट हो ( x-b3-*
) मूल रूपमा Zipkin ट्रेसिङ प्रणालीको लागि विकसित। यसलाई OpenTracing मा रूपान्तरण गरिएको थियो र धेरै उपकरण र पुस्तकालयहरू द्वारा प्रयोग गरिएको थियो। B3-प्रसारमा trace_id
/ span_id
र नमूना आवश्यक छ कि छैन भनेर संकेत गर्ने झण्डा बोक्छ।
W3C ट्रेस कन्टेक्स्ट W3C कार्य समूह द्वारा विकसित, यो मानकले विभिन्न सन्दर्भ प्रसार दृष्टिकोणहरूलाई एकल मानकमा एकीकृत गर्दछ र OpenTelemetry मा पूर्वनिर्धारित हो। यी मापदण्डहरू लागू गर्ने एउटा राम्रो उदाहरण भनेको अनुगमन र डिबगिङ शुद्धतामा सम्झौता नगरी विभिन्न प्रविधिहरूसँग लागू गरिएका माइक्रोसर्भिसेसहरूमार्फत अनुरोधको कार्यान्वयन ट्र्याक गर्नु हो।
ट्रेसिङ भनेको रेकर्डिङ गर्ने प्रक्रिया हो र त्यसपछि धेरै माइक्रोसर्भिसेसहरू मार्फत अनुरोधको मार्गको टाइमलाइन दृश्यावलोकन गर्ने प्रक्रिया हो।
भिजुअलाइजेशनमा, प्रत्येक पट्टीलाई "span" भनिन्छ र एउटा अद्वितीय "span_id" हुन्छ। रूट स्प्यानलाई "ट्रेस" भनिन्छ र यसमा "ट्रेस_आईडी" छ, जसले सम्पूर्ण अनुरोधको लागि पहिचानकर्ताको रूपमा कार्य गर्दछ।
यस प्रकारको दृश्यले तपाईंलाई अनुमति दिन्छ:
trace_id
र span_id
उत्पन्न गर्दछ।
यसको स्पष्ट सरलताको बावजुद, लगिङ समस्याहरूको निदानको लागि सबैभन्दा शक्तिशाली उपकरणहरू मध्ये एक हो। OpenTelemetry ले सान्दर्भिक जानकारी थपेर परम्परागत लगिङ बढाउँछ। विशेष रूपमा, यदि सक्रिय ट्रेस अवस्थित छ भने, `trace_id` र `span_id` विशेषताहरू स्वचालित रूपमा लगहरूमा थपिन्छन्, तिनीहरूलाई ट्रेस टाइमलाइनमा लिङ्क गर्दै। यसबाहेक, लग विशेषताहरूले OpenTelemetry सन्दर्भबाट स्थिर जानकारी समावेश गर्न सक्छ, जस्तै नोड पहिचानकर्ता, साथै हालको HTTP अन्त्य बिन्दु पहिचानकर्ता (`http_path: "GET /user/:id"`) जस्तै गतिशील जानकारी।
`trace_id` प्रयोग गरेर, तपाईँले हालको अनुरोधसँग सम्बन्धित सबै माइक्रोसर्भिसेसहरूबाट लगहरू फेला पार्न सक्नुहुन्छ, जबकि `span_id` ले तपाईंलाई उप-अनुरोधहरू बीच फरक गर्न अनुमति दिन्छ। उदाहरण को लागी, पुन: प्रयास को मामला मा, विभिन्न प्रयासहरु को लगहरु फरक `span_id`s हुनेछ। यी पहिचानकर्ताहरूको प्रयोगले वास्तविक-समयमा सम्पूर्ण प्रणालीको व्यवहारको द्रुत विश्लेषणलाई सक्षम बनाउँछ, समस्या निदानलाई गति दिन्छ र स्थिरता र विश्वसनीयता बढाउँछ।
मेट्रिक्स सङ्कलनले प्रणाली कार्यसम्पादनमा मात्रात्मक डेटा प्रदान गर्दछ, जस्तै विलम्बता, त्रुटि दरहरू, स्रोतको प्रयोग, र थप। मेट्रिक्सको वास्तविक-समय अनुगमनले तपाईंलाई कार्यसम्पादन परिवर्तनहरूमा तुरुन्तै प्रतिक्रिया दिन, असफलता र स्रोतको थकान रोक्न, र प्रयोगकर्ताहरूको लागि अनुप्रयोगको उच्च उपलब्धता र विश्वसनीयता सुनिश्चित गर्न अनुमति दिन्छ।
प्रोमेथियस र ग्राफाना जस्ता मेट्रिक भण्डारण र भिजुअलाइजेसन प्रणालीहरूसँगको एकीकरणले यो डेटालाई भिजुअलाइज गर्न सजिलो बनाउँछ, महत्त्वपूर्ण रूपमा अनुगमनलाई सरल बनाउँछ।
OpenTelemetry मेट्रिक कलेक्टरहरू Prometheus र OpenMetrics मापदण्डहरूसँग उपयुक्त छन्, महत्त्वपूर्ण परिवर्तनहरू बिना OpenTelemetry समाधानहरूमा सजिलो संक्रमण सक्षम पार्दै। OpenTelemetry SDK ले ट्रेस_आईडी उदाहरणहरूलाई मेट्रिक्सको साथमा निर्यात गर्न अनुमति दिन्छ, यसले मेट्रिक्सलाई लग उदाहरणहरू र ट्रेसहरूसँग सम्बद्ध गर्न सम्भव बनाउँछ।
सँगै, लगहरू, मेट्रिक्स, र ट्रेसिङले प्रणालीको अवस्थाको विस्तृत दृश्य सिर्जना गर्दछ:
तीन मुख्य कम्पोनेन्टहरूका अतिरिक्त, OpenTelemetry ले नमूना, सामान, र सञ्चालन सन्दर्भ व्यवस्थापनको अवधारणाहरू समावेश गर्दछ।
उच्च-लोड प्रणालीहरूमा, लगहरू र ट्रेसहरूको मात्रा ठूलो हुन्छ, पूर्वाधार र डेटा भण्डारणको लागि पर्याप्त स्रोतहरू चाहिन्छ। यस मुद्दालाई सम्बोधन गर्न, OpenTelemetry मापदण्डहरूले संकेत नमूना समावेश गर्दछ — ट्रेस र लगहरूको मात्र अंश निर्यात गर्ने क्षमता। उदाहरणका लागि, तपाईंले अनुरोधहरूको प्रतिशत, लामो समयदेखि चलिरहेका अनुरोधहरू, वा त्रुटि अनुरोधहरूबाट विस्तृत संकेतहरू निर्यात गर्न सक्नुहुन्छ। यस दृष्टिकोणले महत्त्वपूर्ण स्रोतहरू बचत गर्दा तथ्याङ्कहरू निर्माण गर्न पर्याप्त नमूनाहरूको लागि अनुमति दिन्छ।
यद्यपि, यदि प्रत्येक प्रणालीले स्वतन्त्र रूपमा कुन अनुरोधहरूलाई विस्तृत रूपमा निगरानी गर्ने निर्णय गर्छ भने, हामी प्रत्येक अनुरोधको खण्डित दृश्यको साथ अन्त्य गर्छौं। केही प्रणालीहरूले विस्तृत डेटा निर्यात गर्न सक्छन् जबकि अरूले आंशिक रूपमा मात्र निर्यात गर्न सक्छन् वा निर्यात नगर्न सक्छन्।
यो समस्या समाधान गर्न, OpenTelemetry को सन्दर्भ प्रचार संयन्त्रले `trace_id`/`span_id` सँग नमूना झण्डा पठाउँछ। यसले सुनिश्चित गर्दछ कि यदि प्रयोगकर्ता अनुरोध प्राप्त गर्ने प्रारम्भिक सेवाले अनुरोधलाई विस्तृत रूपमा अनुगमन गरिनुपर्छ भन्ने निर्णय गर्छ भने, अन्य सबै प्रणालीहरूले त्यसलाई पछ्याउनेछन्। अन्यथा, सबै प्रणालीहरूले स्रोतहरू संरक्षण गर्न आंशिक रूपमा वा संकेतहरू निर्यात गर्नु हुँदैन। यस दृष्टिकोणलाई "हेड नमूना" भनिन्छ - अनुरोध प्रशोधनको सुरुमा गरिएको निर्णय, या त अनियमित रूपमा वा केही इनपुट विशेषताहरूमा आधारित।
साथै, OpenTelemetry ले "टेल नमूना" लाई समर्थन गर्दछ, जहाँ सबै अनुप्रयोगहरूले सधैं विस्तारमा सबै संकेतहरू निर्यात गर्दछ, तर एक मध्यवर्ती बफर अवस्थित छ। सबै डाटा सङ्कलन गरेपछि, यो बफरले पूर्ण डाटा राख्ने वा आंशिक नमूना मात्र राख्ने निर्णय गर्छ। यो विधिले प्रत्येक अनुरोध श्रेणीको थप प्रतिनिधि नमूनाको लागि अनुमति दिन्छ (सफल/लामो/त्रुटि) तर थप पूर्वाधार सेटअप आवश्यक छ।
ब्यागेज मेकानिजमले स्वेच्छाचारी कुञ्जी-मान जोडीहरूलाई trace_id
/ span_id
को साथमा पठाउन अनुमति दिन्छ, अनुरोध प्रशोधन गर्दा स्वचालित रूपमा सबै माइक्रोसेवाहरू बीचमा जान्छ। यो अनुरोध मार्गमा आवश्यक थप जानकारी पठाउनको लागि उपयोगी छ — जस्तै प्रयोगकर्ता जानकारी वा रनटाइम वातावरण सेटिङहरू।
W3C मानक अनुसार सामान पठाउनको लागि हेडरको उदाहरण: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5
यहाँ सामान प्रयोगका केही उदाहरणहरू छन्:
पास गर्दै व्यापार सन्दर्भ जानकारी जस्तै userId
, productId
, वा deviceId
सबै माइक्रो सेवाहरू मार्फत पास गर्न सकिन्छ। अनुप्रयोगहरूले स्वचालित रूपमा यो जानकारी लग गर्न सक्छन्, मूल अनुरोधको लागि प्रयोगकर्ता सन्दर्भद्वारा लग खोजहरूको लागि अनुमति दिँदै।
SDK हरू वा पूर्वाधारका लागि विशिष्ट कन्फिगरेसन प्यारामिटर सेटिङहरू।
राउटिङ फ्ल्याग फ्ल्यागहरू जसले ब्यालेन्सरहरूलाई राउटिंग निर्णयहरू गर्न मद्दत गर्दछ। परीक्षणको क्रममा, केही अनुरोधहरूलाई नक्कली ब्याकएन्डहरूमा रुट गर्न आवश्यक हुन सक्छ। सामान सबै सेवाहरू मार्फत स्वचालित रूपमा प्रसारित भएको हुनाले, त्यहाँ अतिरिक्त प्रोटोकलहरू सिर्जना गर्न आवश्यक पर्दैन — लोड ब्यालेन्सरमा मात्र नियम सेट गर्नुहोस्।
नोट गर्नुहोस् कि ब्यागेजको कार्यसम्पादन प्रभाव न्यून छ, तर अत्यधिक प्रयोगले नेटवर्क र सेवा लोडलाई उल्लेखनीय रूपमा बढाउन सक्छ। कार्यसम्पादन समस्याहरूबाट बच्नको लागि तपाईंले वास्तवमै ब्यागेज मार्फत कुन डेटा पास गर्न आवश्यक छ भनी सावधानीपूर्वक छनौट गर्नुहोस्।
पूर्वाधार स्तरमा OpenTelemetry लागू गर्नाले OpenTelemetry ब्याकएन्डहरूलाई एप्लिकेसन आर्किटेक्चरमा एकीकृत गर्ने र डेटा एकत्रीकरणको लागि पूर्वाधार कन्फिगर गर्ने समावेश गर्दछ।
प्रक्रिया चार चरणहरू हुन्छन्:
अनुप्रयोग एकीकरण पहिलो चरणमा, OpenTelemetry SDK हरू मेट्रिक्स, लगहरू, र ट्रेसहरू सङ्कलन गर्न अनुप्रयोगहरूमा प्रत्यक्ष रूपमा एकीकृत हुन्छन्, प्रत्येक प्रणाली कम्पोनेन्टको कार्यसम्पादनको बारेमा डाटाको निरन्तर प्रवाह सुनिश्चित गर्दै।
निर्यातकर्ताहरू कन्फिगर गर्दै सङ्कलन गरिएको डाटालाई तपाईंको आवश्यकताहरूमा निर्भर गर्दै लगिङ, अनुगमन, ट्रेसिङ वा एनालिटिक्स प्रणालीहरू जस्ता थप प्रशोधनका लागि निर्यातकर्ताहरू मार्फत बाह्य प्रणालीहरूमा पठाइन्छ।
एकत्रीकरण र भण्डारण यस चरणमा डेटालाई सामान्यीकरण गर्ने, थप जानकारीको साथ यसलाई समृद्ध बनाउने, र प्रणालीको अवस्थाको एकीकृत दृश्य सिर्जना गर्न विभिन्न स्रोतहरूबाट डाटा मर्ज गर्ने समावेश हुन सक्छ।
डाटा भिजुअलाइजेसन अन्तमा, प्रशोधित डाटा ग्राफाना (मेट्रिक्स र ट्रेसहरूको लागि) वा किबाना (लगहरूको लागि) जस्ता प्रणालीहरूमा ड्यासबोर्डको रूपमा प्रस्तुत गरिन्छ। यसले टोलीहरूलाई प्रणालीको स्वास्थ्यको द्रुत रूपमा मूल्याङ्कन गर्न, समस्याहरू र प्रवृत्तिहरू पहिचान गर्न, र उत्पन्न संकेतहरूमा आधारित अलर्टहरू सेट अप गर्न अनुमति दिन्छ।
एप्लिकेसनसँग एकीकृत गर्नको लागि, तपाईंले प्रयोगमा रहेको प्रोग्रामिङ भाषाको लागि उपयुक्त OpenTelemetry SDK जडान गर्न वा OpenTelemetry लाई प्रत्यक्ष समर्थन गर्ने पुस्तकालयहरू र फ्रेमवर्कहरू प्रयोग गर्न आवश्यक छ। OpenTelemetry प्रायः ज्ञात पुस्तकालयहरूबाट व्यापक रूपमा प्रयोग गरिएको इन्टरफेसहरू लागू गर्दछ, ड्रप-इन प्रतिस्थापनहरूलाई अनुमति दिँदै। उदाहरणका लागि, माइक्रोमिटर लाइब्रेरी सामान्यतया जाभा इकोसिस्टममा मेट्रिक्स सङ्कलनका लागि प्रयोग गरिन्छ। OpenTelemetry SDK ले मुख्य एप्लिकेसन कोड परिवर्तन नगरी मेट्रिक निर्यात सक्षम पार्दै माइक्रोमिटर इन्टरफेसहरूको कार्यान्वयन प्रदान गर्दछ। यसबाहेक, OpenTelemetry ले पुरानो OpenTracing र OpenCensus इन्टरफेसहरूको कार्यान्वयन प्रस्ताव गर्दछ, OpenTelemetry मा सहज माइग्रेसनको सुविधा दिन्छ।
IT प्रणालीहरूमा, OpenTelemetry विश्वसनीय र कुशल ब्याकएन्डहरूको भविष्यको लागि कुञ्जी बन्न सक्छ। यो उपकरणले डिबगिङ र निगरानीलाई सरल बनाउँछ र नयाँ स्तरमा अनुप्रयोग प्रदर्शन र अप्टिमाइजेसनको गहिरो समझको लागि अवसरहरू पनि खोल्छ। OpenTelemetry समुदायमा सामेल हुनुहोस् भविष्यलाई आकार दिन मद्दत गर्न जहाँ ब्याकएन्ड विकास सरल र अधिक प्रभावकारी छ!