ओपनटेलीमेट्री कलेक्टर में गहराई से जाना

ओपनटेलीमेट्री कलेक्टर ओपनटेलीमेट्री आर्किटेक्चर के केंद्र में बैठता है लेकिन W3C ट्रेस संदर्भ से असंबंधित है। अपने में, मैं कलेक्टर के बजाय जैगर का उपयोग करता हूं। फिर भी, यह सर्वव्यापी है, जैसा कि प्रत्येक ओपनटेलीमेट्री-संबंधित पोस्ट में होता है। मैं इसे और अधिक जानना चाहता था। ट्रेसिंग डेमो इस पोस्ट में, मैं कलेक्टर के विभिन्न पहलुओं का पता लगाता हूँ: डेटा प्रकार: लॉग, मेट्रिक्स और ट्रेस मॉडलों को धकेलें और खींचें संचालन: पढ़ता है, परिवर्तन करता है, और लिखता है पहले कदम बहुत समय पहले, , जैसा कि हम जानते हैं, अस्तित्व में नहीं थी; इसके बजाय हमारे पास थी। उस समय, निगरानी करने वाले लोगों का एक समूह डैशबोर्ड प्रदर्शित करने वाली स्क्रीन को देखता था। डैशबोर्ड में स्वयं मेट्रिक्स और केवल सिस्टम मेट्रिक्स शामिल होते हैं: मुख्य रूप से सीपीयू, मेमोरी और डिस्क उपयोग। इस कारण से, हम मेट्रिक्स से शुरुआत करेंगे। अवलोकनशीलता निगरानी प्राथमिक निगरानी समाधानों में से एक है। यह एक पुल-आधारित मॉडल पर काम करता है: प्रोमेथियस आपके एप्लिकेशन के संगत एंडपॉइंट्स को स्क्रैप करता है और उन्हें आंतरिक रूप से संग्रहीत करता है। प्रोमेथियस हम प्रोमेथियस-संगत एंडपॉइंट को स्क्रैप करने और कंसोल में परिणाम प्रिंट करने के लिए ओटीईएल कलेक्टर का उपयोग करेंगे। ग्राफाना लैब्स एक पेश करता है जो खेलने के लिए यादृच्छिक मेट्रिक्स उत्पन्न करता है। सरलता के लिए, मैं डॉकर कंपोज़ का उपयोग करूँगा; सेटअप निम्न जैसा दिखता है: प्रोजेक्ट version: "3" services: fake-metrics: build: ./fake-metrics-generator #1 collector: image: otel/opentelemetry-collector:0.87.0 #2 environment: #3 - METRICS_HOST=fake-metrics - METRICS_PORT=5000 volumes: - ./config/collector/config.yml:/etc/otelcol/config.yaml:ro #4 नकली मेट्रिक्स प्रोजेक्ट के लिए कोई डॉकर छवि उपलब्ध नहीं है; इसलिए, हमें इसे बनाने की आवश्यकता है इस लेखन के समय ओटेल कलेक्टर का नवीनतम संस्करण निम्नलिखित कॉन्फ़िगरेशन फ़ाइल को पैरामीटराइज़ करें यहां सब कुछ होता है जैसा कि मैंने ऊपर बताया, OTEL कलेक्टर बहुत कुछ कर सकता है। इसलिए, कॉन्फ़िगरेशन ही सब कुछ है। receivers: #1 prometheus: #2 config: scrape_configs: #3 - job_name: fake-metrics #4 scrape_interval: 3s static_configs: - targets: [ "${env:METRICS_HOST}:${env:METRICS_PORT}" ] exporters: #5 logging: #6 loglevel: debug service: pipelines: #7 metrics: #8 receivers: [ "prometheus" ] #9 exporters: [ "logging" ] #9 प्राप्तकर्ताओं की सूची. एक रिसीवर डेटा पढ़ता है; यह या तो पुश-आधारित या पुल-आधारित हो सकता है। हम पूर्व-परिभाषित रिसीवर का उपयोग करते हैं prometheus पुल जॉब्स को परिभाषित करें नौकरी का विन्यास निर्यातकों की सूची. रिसीवर्स के विपरीत, एक निर्यातक डेटा लिखता है। सबसे सरल निर्यातक मानक आउट पर डेटा लिखना है पाइपलाइन रिसीवर्स और निर्यातकों को इकट्ठा करती हैं मीट्रिक-संबंधित पाइपलाइन को परिभाषित करें पाइपलाइन पहले से परिभाषित रिसीवर से डेटा प्राप्त करती है और इसे निर्यातक को भेजती है, उन्हें प्रिंट करती है prometheus logging यानी यहाँ परिणाम का एक नमूना है: 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 83.090000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #1 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__embrace_world_class_systems: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__exploit_magnetic_applications: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__facilitate_wireless_architectures: Str(extranet) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(challenge) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__reinvent_revolutionary_applications: Str(support) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__strategize_strategic_initiatives: Str(internet_solution) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__target_customized_eyeballs: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__transform_turn_key_technologies: Str(framework) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__whiteboard_innovative_partnerships: Str(matrices) 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 53.090000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #2 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__expedite_distributed_partnerships: Str(approach) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__facilitate_wireless_architectures: Str(graphical_user_interface) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(policy) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__reinvent_revolutionary_applications: Str(algorithm) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__transform_turn_key_technologies: Str(framework) 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 16.440000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #3 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__exploit_magnetic_applications: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(graphical_user_interface) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__target_customized_eyeballs: Str(extranet) मुद्रण से परे उपरोक्त एक उत्कृष्ट पहला कदम है, लेकिन कंसोल पर प्रिंट करने के अलावा और भी बहुत कुछ है। हम नियमित प्रोमेथियस उदाहरण द्वारा स्क्रैप किए जाने वाले मेट्रिक्स को उजागर करेंगे; हम उन्हें देखने के लिए एक जोड़ सकते हैं। हालाँकि यह निरर्थक लग सकता है, लेकिन इसे सहन करें, क्योंकि यह केवल एक कदम है। ग्राफाना डैशबोर्ड उपरोक्त प्राप्त करने के लिए, हम केवल OTEL कलेक्टर कॉन्फ़िगरेशन को बदलते हैं: exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" #2 service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus" ] #3 एक निर्यातक जोड़ें prometheus प्रोमेथियस-संगत समापन बिंदु को उजागर करें प्रिंटिंग को एक्सपोज़िंग से बदलें इतना ही। ओटेल कलेक्टर बहुत लचीला है। ध्यान दें कि कलेक्टर मल्टी-इनपुट, मल्टी-आउटपुट है। डेटा को प्रिंट करने और उसे एंडपॉइंट के माध्यम से प्रदर्शित करने के लिए, हम उन्हें पाइपलाइन में जोड़ते हैं: exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" logging: #2 loglevel: debug service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus", "logging" ] #3 डेटा उजागर करें डेटा प्रिंट करें पाइपलाइन डेटा प्रिंट करेगी और उन्हें प्रदर्शित करेगी प्रोमेथियस निर्यातक कॉन्फ़िगर होने के साथ, हम ग्राफाना में मेट्रिक्स की कल्पना कर सकते हैं। ध्यान दें कि प्राप्तकर्ता और निर्यातक अपना प्रकार निर्दिष्ट करते हैं उनमें से प्रत्येक अद्वितीय होना चाहिए। अंतिम आवश्यकता का अनुपालन करने के लिए, हम उनके बीच अंतर करने के लिए एक क्वालीफायर जोड़ सकते हैं, , और और यानी prometheus/foo prometheus/bar. मध्यस्थ डेटा प्रोसेसिंग एक वैध प्रश्न यह होगा कि ओटीईएल कलेक्टर को स्रोत और प्रोमेथियस के बीच क्यों सेट किया गया है, क्योंकि यह समग्र डिजाइन को और अधिक नाजुक बनाता है। इस स्तर पर, हम ओटेल कलेक्टर की वास्तविक शक्ति का लाभ उठा सकते हैं: डेटा प्रोसेसिंग। अब तक, हमने कच्चे मेट्रिक्स को शामिल कर लिया है, लेकिन स्रोत प्रारूप को हम जिस तरह से डेटा को विज़ुअलाइज़ करना चाहते हैं, उसके अनुरूप नहीं बनाया जा सकता है। उदाहरण के लिए, हमारे सेटअप में, मेट्रिक्स हमारे नकली जनरेटर, "व्यवसाय" और अंतर्निहित NodeJS प्लेटफ़ॉर्म, "तकनीकी" से आते हैं। यह मेट्रिक्स के नाम में परिलक्षित होता है। हम एक समर्पित स्रोत लेबल जोड़ सकते हैं और अधिक कुशलता से फ़िल्टर करने के लिए अनावश्यक उपसर्ग को हटा सकते हैं। आप कॉन्फ़िगरेशन फ़ाइल के अनुभाग में डेटा प्रोसेसर घोषित करते हैं। कलेक्टर उन्हें घोषित क्रम में निष्पादित करता है। आइए उपरोक्त परिवर्तन को लागू करें। processors हमारे लक्ष्य की ओर पहला कदम यह समझना है कि संग्राहक के दो स्वाद हैं: एक "नंगे" और एक योगदान जो उस पर बनता है। पूर्व में शामिल प्रोसेसर संख्या और क्षमताओं दोनों में सीमित हैं; इसलिए, हमें योगदान संस्करण को स्विच करने की आवश्यकता है। collector: image: otel/opentelemetry-collector-contrib:0.87.0 #1 environment: - METRICS_HOST=fake-metrics - METRICS_PORT=5000 - PROMETHEUS_PORT=8889 volumes: - ./config/collector/config.yml:/etc/otelcol-contrib/config.yaml:ro #2 स्वाद का प्रयोग करें contrib अतिरिक्त मनोरंजन के लिए, कॉन्फ़िगरेशन फ़ाइल दूसरे पथ पर है इस बिंदु पर, हम प्रोसेसर को स्वयं जोड़ सकते हैं: processors: metricstransform: #1 transforms: #2 - include: ^fake_(.*)$ #3 match_type: regexp #3 action: update operations: #4 - action: add_label #5 new_label: origin new_value: fake - include: ^fake_(.*)$ match_type: regexp action: update #6 new_name: $${1} #6-7 # Do the same with metrics generated by NodeJS मेट्रिक्स ट्रांसफॉर्म प्रोसेसर को आमंत्रित करें क्रम में लागू परिवर्तनों की सूची परिभाषित regexp के साथ सभी मेट्रिक्स से मेल खाता है क्रम में लागू कार्यों की सूची लेबल जोड़ें regexp समूह उपसर्ग को हटाकर मीट्रिक का नाम बदलें मज़ेदार सामग्री: वाक्यविन्यास है $${x} अंत में, हम परिभाषित प्रोसेसर को पाइपलाइन में जोड़ते हैं: service: pipelines: metrics: receivers: [ "prometheus" ] processors: [ "metricstransform" ] exporters: [ "prometheus" ] यहाँ परिणाम हैं: रिसीवर्स और निर्यातकों को जोड़ना एक कनेक्टर एक रिसीवर एक निर्यातक दोनों है और दो पाइपलाइनों को जोड़ता है। दस्तावेज़ीकरण से उदाहरण स्पैन की संख्या (ट्रेसिंग) प्राप्त करता है और गिनती निर्यात करता है, जिसमें एक मीट्रिक होता है। मैंने 500 त्रुटियों के साथ इसे हासिल करने की कोशिश की - स्पॉइलर: यह इरादे के मुताबिक काम नहीं करता है। और आइए सबसे पहले एक लॉग रिसीवर जोड़ें: receivers: filelog: include: [ "/var/logs/generated.log" ] फिर, हम एक कनेक्टर जोड़ते हैं: connectors: count: requests.errors: description: Number of 500 errors condition: [ "status == 500 " ] अंत में, हम लॉग रिसीवर और मेट्रिक्स निर्यातक को जोड़ते हैं: service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "count" ] metrics: receivers: [ "prometheus", "count" ] मीट्रिक का नाम है, लेकिन इसका मान 1 ही रहता है। log_record_count_total लॉग हेरफेर प्रोसेसर डेटा हेरफेर की अनुमति देते हैं; ऑपरेटर विशेष प्रोसेसर हैं जो लॉग पर काम करते हैं। यदि आप इलास्टिक्स खोज लॉगस्टैश किबाना स्टैक से परिचित हैं, तो वे लॉगस्टैश के समकक्ष हैं। अभी तक, लॉग टाइमस्टैम्प अंतर्ग्रहण टाइमस्टैम्प है। हम इसे इसके निर्माण के टाइमस्टैम्प में बदल देंगे। receivers: filelog: include: [ "/var/logs/generated.log" ] operators: - type: json_parser #1 timestamp: #2 parse_from: attributes.datetime #3 layout: "%d/%b/%Y:%H:%M:%S %z" #4 severity: #2 parse_from: attributes.status #3 mapping: #5 error: 5xx #6 warn: 4xx info: 3xx debug: 2xx - id: remove_body #7 type: remove field: body - id: remove_datetime #7 type: remove field: attributes.datetime - id: remove_status #7 type: remove field: attributes.status लॉग JSON प्रारूप में है; हम दिए गए JSON पार्सर का उपयोग कर सकते हैं सेट करने के लिए मेटाडेटा विशेषताएँ पढ़ने के लिए फ़ील्ड पार्सिंग पैटर्न मानचित्रण तालिका एक सीमा स्वीकार करें, , । HTTP स्थितियों के लिए ऑपरेटर के पास एक विशेष व्याख्यात्मक मान (और समान) है। उदाहरण के लिए 501-599 5xx डुप्लिकेट किया गया डेटा हटाएं लॉग्स इस बिंदु पर, हम लॉग को किसी भी लॉग एकत्रीकरण घटक को भेज सकते हैं। हम ग्राफाना लैब्स क्षेत्र में रहेंगे और लोकी का उपयोग करेंगे। exporters: loki: endpoint: "http://loki:3100/loki/api/v1/push" हम स्वयं संग्राहक से लॉग का भी उपयोग कर सकते हैं: service: telemetry: logs: अंत में, आइए एक और पाइपलाइन जोड़ें: service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "loki" ] ग्राफाना लॉग्स की कल्पना भी कर सकता है। लोकी को डेटास्रोत के रूप में चुनें। निष्कर्ष इस पोस्ट में, हमने ओपनटेलीमेट्री कलेक्टर के बारे में विस्तार से बताया। हालाँकि यह OTEL आर्किटेक्चर का अनिवार्य हिस्सा नहीं है, यह आपकी सभी डेटा प्रोसेसिंग आवश्यकताओं के लिए एक उपयोगी स्विस चाकू है। यदि आप किसी विशिष्ट स्टैक से बंधे नहीं हैं या नहीं रहना चाहते हैं, तो यह एक जबरदस्त मदद है। इस पोस्ट का संपूर्ण स्रोत कोड पर पाया जा सकता है। GitHub आगे जाने के लिए: ओपनटेलीमेट्री कलेक्टर ओपनटेलीमेट्री ऑपरेटर्स मूल रूप से 12 नवंबर, 2023 को में ए जावा गीक प्रकाशित