OpenTelemetry সংগ্রাহক OpenTelemetry আর্কিটেকচারের কেন্দ্রে বসে কিন্তু W3C ট্রেস প্রসঙ্গের সাথে সম্পর্কহীন। আমার ট্রেসিং ডেমোতে , আমি কালেক্টরের পরিবর্তে Jaeger ব্যবহার করি। তবুও, এটি সর্বব্যাপী, যেমন প্রতিটি OpenTelemetry-সম্পর্কিত পোস্টে। আমি এটা আরো অন্বেষণ করতে চেয়েছিলেন.
এই পোস্টে, আমি কালেক্টরের বিভিন্ন দিক অন্বেষণ করি:
বহুকাল আগে, পর্যবেক্ষণযোগ্যতা যেমন আমরা জানি এর অস্তিত্ব ছিল না; আমরা পরিবর্তে কি ছিল নিরীক্ষণ ছিল. তখন, মনিটরিং ছিল ড্যাশবোর্ড প্রদর্শনকারী স্ক্রিনের দিকে একগুচ্ছ মানুষ। ড্যাশবোর্ডগুলি নিজেই মেট্রিক্স এবং শুধুমাত্র সিস্টেম মেট্রিক্স নিয়ে গঠিত: প্রধানত CPU, মেমরি এবং ডিস্ক ব্যবহার। এই কারণে, আমরা মেট্রিক্স দিয়ে শুরু করব।
প্রমিথিউস প্রাথমিক পর্যবেক্ষণ সমাধানগুলির মধ্যে একটি। এটি একটি পুল-ভিত্তিক মডেলে কাজ করে: প্রমিথিউস আপনার অ্যাপ্লিকেশন(গুলি) এর সামঞ্জস্যপূর্ণ শেষ পয়েন্টগুলিকে স্ক্র্যাপ করে এবং সেগুলি অভ্যন্তরীণভাবে সংরক্ষণ করে।
আমরা একটি প্রমিথিউস-সামঞ্জস্যপূর্ণ এন্ডপয়েন্ট স্ক্র্যাপ করতে এবং কনসোলে ফলাফল প্রিন্ট করতে OTEL কালেক্টর ব্যবহার করব। Grafana Labs একটি প্রকল্প অফার করে যা খেলার জন্য র্যান্ডম মেট্রিক্স তৈরি করে। সরলতার জন্য, আমি ডকার কম্পোজ ব্যবহার করব; সেটআপ নিম্নলিখিত মত দেখায়:
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)
উপরেরটি একটি দুর্দান্ত প্রথম পদক্ষেপ, তবে কনসোলে মুদ্রণের চেয়ে আরও অনেক কিছু রয়েছে। আমরা একটি নিয়মিত প্রমিথিউস দৃষ্টান্ত দ্বারা স্ক্র্যাপ করা মেট্রিক্স প্রকাশ করব; আমরা তাদের কল্পনা করতে একটি Grafana ড্যাশবোর্ড যোগ করতে পারি। যদিও এটি অর্থহীন বলে মনে হতে পারে, এটি সহ্য করুন, কারণ এটি শুধুমাত্র একটি ধাপ।
উপরেরটি অর্জন করতে, আমরা শুধুমাত্র OTEL কালেক্টর কনফিগারেশন পরিবর্তন করি:
exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" #2 service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus" ] #3
prometheus
রপ্তানিকারক যোগ করুন
এটাই. OTEL কালেক্টর খুবই নমনীয়।
উল্লেখ্য যে কালেক্টর হল মাল্টি-ইনপুট, মাল্টি-আউটপুট। উভয় ডেটা মুদ্রণ করতে এবং এন্ডপয়েন্টের মাধ্যমে তাদের প্রকাশ করতে, আমরা সেগুলিকে পাইপলাইনে যুক্ত করি:
exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" logging: #2 loglevel: debug service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus", "logging" ] #3
Prometheus রপ্তানিকারক কনফিগার করা হলে, আমরা Grafana-এ মেট্রিক্স কল্পনা করতে পারি।
নোট করুন যে রিসিভার এবং রপ্তানিকারীরা তাদের ধরন নির্দিষ্ট করে এবং তাদের প্রত্যেককে অবশ্যই অনন্য হতে হবে। শেষ প্রয়োজনীয়তা মেনে চলার জন্য, আমরা তাদের মধ্যে পার্থক্য করার জন্য একটি কোয়ালিফায়ার যোগ করতে পারি, যেমন , prometheus/foo
এবং prometheus/bar.
একটি বৈধ প্রশ্ন হবে কেন OTEL কালেক্টরকে উৎস এবং প্রমিথিউসের মধ্যে সেট করা হয়েছে, কারণ এটি সামগ্রিক নকশাকে আরও ভঙ্গুর করে তোলে। এই পর্যায়ে, আমরা OTEL কালেক্টরের সত্যিকারের শক্তিকে কাজে লাগাতে পারি: ডেটা প্রসেসিং। এখন পর্যন্ত, আমরা কাঁচা মেট্রিক্স গ্রহণ করেছি, কিন্তু উৎস বিন্যাস আমরা কীভাবে ডেটা কল্পনা করতে চাই তার সাথে মানিয়ে নাও যেতে পারে। উদাহরণস্বরূপ, আমাদের সেটআপে, মেট্রিকগুলি আমাদের জাল জেনারেটর, "ব্যবসা" এবং অন্তর্নিহিত 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
$${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" ]
মেট্রিকটির নাম দেওয়া হয়েছে log_record_count_total
, কিন্তু এর মান 1 এ থাকে।
প্রসেসর ডেটা ম্যানিপুলেশন অনুমতি দেয়; অপারেটরগুলি বিশেষায়িত প্রসেসর যা লগগুলিতে কাজ করে। আপনি যদি Elasticsearch Logstash Kibana স্ট্যাকের সাথে পরিচিত হন, তাহলে তারা Logstash এর সমতুল্য।
এখন পর্যন্ত, লগ টাইমস্ট্যাম্প হল ইনজেশন টাইমস্ট্যাম্প৷ আমরা এটিকে এর সৃষ্টির টাইমস্ট্যাম্পে পরিবর্তন করব।
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
501-599
। এইচটিটিপি স্ট্যাটাসের জন্য অপারেটরের একটি বিশেষ ব্যাখ্যা করা মান 5xx
(এবং অনুরূপ) রয়েছে।এই মুহুর্তে, আমরা লগগুলিকে যেকোন লগ অ্যাগ্রিগেশন কম্পোনেন্টে পাঠাতে পারি। আমরা Grafana ল্যাব গোলক মধ্যে থাকব এবং Loki ব্যবহার.
exporters: loki: endpoint: "http://loki:3100/loki/api/v1/push"
আমরা সংগ্রাহকের নিজেই লগগুলি ব্যবহার করতে পারি:
service: telemetry: logs:
অবশেষে, আরেকটি পাইপলাইন যোগ করা যাক:
service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "loki" ]
গ্রাফানা লগগুলিকে কল্পনাও করতে পারে। একটি ডেটাসোর্স হিসাবে লোকি নির্বাচন করুন।
এই পোস্টে, আমরা ওপেনটেলিমেট্রি সংগ্রাহক নিয়ে আলোচনা করেছি। যদিও এটি OTEL আর্কিটেকচারের একটি বাধ্যতামূলক অংশ নয়, এটি আপনার সমস্ত ডেটা প্রক্রিয়াকরণের প্রয়োজনের জন্য একটি দরকারী সুইস ছুরি। যদি আপনি একটি নির্দিষ্ট স্ট্যাকে আটকে না থাকেন বা চান না, এটি একটি অসাধারণ সাহায্য।
এই পোস্টের জন্য সম্পূর্ণ সোর্স কোড GitHub এ পাওয়া যাবে।
আরো যেতে:
মূলত 12ই নভেম্বর, 2023-এ A Java Geek- এ প্রকাশিত