اتصال نقاط: OpenTelemetry برای مبتدیان

Summarize this content to 400 words in Persian Lang
اگر تا به حال احساس کرده اید که تحت تأثیر کلماتی مانند “گردآورنده”، “ابزارسازی” یا “ردیابی” قرار گرفته اید، تنها نیستید. من همانجا با شما هستم 😵‍💫، هنوز در حال یادگیری و جمع کردن همه چیز هستم. اما همانطور که من به اتصال نقطه ها ادامه می دهم، ابزارهایی مانند OpenTelemetry کم کم معنادارتر می شوند. شرکت در کارگاه Honeycomb برای OpenTelemetry واقعاً به ترسیم تصویری از اجزای مختلف و نحوه کار آنها با یکدیگر کمک کرد. اجازه دهید آنچه را که تا به حال فهمیده ام به ساده ترین روشی که می توانم به اشتراک بگذارم، تا شاید این پازل برای شما هم کلیک کند.

آشنایی با OpenTelemetry

OpenTelemetry (OTel) را به عنوان یک مجموعه ابزار برای درک آنچه در داخل نرم افزار شما اتفاق می افتد در نظر بگیرید. تصور کنید که در حال سازماندهی یک فرآیند پستی بزرگ هستید که در آن باید بسته هایی را برای افراد ارسال کنید. می خواهید بدانید:

وقتی هر بسته 📦 تحویل گرفت.
بعد به کجا می رود ❓
وقتی تحویل می شود.

بیایید برخی از اجزای OpenTelemetry را با استفاده از این قیاس تجزیه کنیم:

ابزار دقیق: به هر بسته یک برچسب ردیابی بچسبانید. این روشی است که شما اطلاعات سفر هر بسته را جمع آوری می کنید. در نرم افزار، این به معنای افزودن حسگرهایی به کد شما برای جمع آوری داده ها در مورد آنچه اتفاق می افتد است.

سیاههها: گزارش‌ها مانند یادداشت‌هایی هستند که هر رویدادی را که در طول سفر بسته اتفاق می‌افتد، ردیابی می‌کنند، مانند زمانی که بسته وارد یک مرکز می‌شود یا برای تحویل خارج می‌شود. می‌توانید گزارش‌ها را به باطن‌های مختلف، مانند یک سرویس گزارش، صادر کنید تا همه چیز را پیگیری کنید.
معیارها: معیارها مانند خلاصه هایی هستند که به شما می گویند چند بسته در یک روز تحویل داده شده است، تحویل چقدر طول کشیده است یا چند بسته با تأخیر مواجه شده اند. این معیارها را می توان به خدمات نظارت تخصصی برای تجزیه و تحلیل عملکرد کلی صادر کرد.
آثار: ردیابی ها مانند یک نقشه مسیر دقیق هستند که سفر کامل یک بسته را از تحویل گرفتن تا تحویل نشان می دهد. آنها را می توان به یک پلت فرم قابل مشاهده متفاوت صادر کرد که به شما کمک می کند هر مرحله از سفر را با جزئیات تجزیه و تحلیل کنید.

گردآورنده: یک هاب مرکزی را تصور کنید که در آن تمام اطلاعات ردیابی جمع آوری می شود. گردآورنده داده ها را از تمام برچسب های ردیابی جمع آوری می کند، آنها را پردازش می کند و برای تجزیه و تحلیل ارسال می کند. گردآورنده می تواند داده ها را از چندین منبع جمع آوری کرده و به مکان های مختلف ارسال کند. با این حال، همیشه لازم نیست، شما می توانید داده ها را مستقیماً از برنامه خود به یک پلت فرم مشاهده پذیری صادر کنید.

گیرنده: گردآورنده از گیرنده ها برای جمع آوری داده ها از منابع مختلف استفاده می کند. گیرنده مانند نقطه ورود داده ها به مجموعه است که به آن امکان می دهد داده های تله متری را از اجزای مختلف مانند برنامه، سرویس ها یا سیستم های دیگر دریافت کند.
پردازنده: پس از دریافت داده ها، پردازشگر مسئولیت را بر عهده می گیرد. پردازنده را به عنوان فردی در مرکز مرکزی در نظر بگیرید که اطلاعات ردیابی را قبل از ارسال سازماندهی، فیلتر و بهبود می بخشد. پردازشگرها به شما امکان می‌دهند داده‌ها را تغییر دهید، مانند افزودن ویژگی‌های اضافی یا حذف اطلاعات غیر ضروری، و اطمینان حاصل شود که فقط مرتبط‌ترین داده‌ها به جلو حرکت می‌کنند.

صادرکننده: صادرکننده داده‌های جمع‌آوری‌شده را به مقصد نهایی‌اش ارسال می‌کند، مانند یک پلت‌فرم قابل مشاهده یا پایگاه‌داده. می‌توانید برنامه‌تان را طوری پیکربندی کنید که مستقیماً به یک باطن صادر شود یا از یک جمع‌آورنده برای انجام صادرات استفاده کنید.

پلت فرم مشاهده پذیری: این مانند داشبوردی است که پیشرفت همه بسته ها را نشان می دهد. داده‌های جمع‌آوری‌شده را به بینش، نمودار، هشدار و داشبورد تبدیل می‌کند تا بتوانید بفهمید چه اتفاقی می‌افتد.

با استفاده از OpenTelemetry

در حال حاضر با:

سرویس Azure Kubernetes (AKS)
پایگاه داده: برای ذخیره سازی داده ها.
Redis: برای ذخیره سازی.
Azure App Configuration: برای مدیریت تنظیمات برنامه به صورت مرکزی.
جاوا با SpringBoot

ما به راهی برای ردیابی تعاملات و جریان بین همه این مؤلفه ها نیاز داریم. این به ما کمک می‌کند بفهمیم که آنها چگونه با هم کار می‌کنند و بینش‌های ارزشمندی به دست می‌آورند، نه فقط مسائل بالقوه را شناسایی کنیم.

شروع با مانیتور Azure

سفر من با کتابخانه ابزار دقیق Azure Monitor در برنامه Spring Boot من آغاز شد. این رویکرد به من این امکان را داد که خدمات خود را به صورت خودکار ابزار کنم و داده های تله متری را مستقیماً به Azure Application Insights بدون هیچ تغییری در کد ارسال کنم. برای جزئیات راه اندازی، می توانید به مستندات راه اندازی رسمی مانیتور Azure مراجعه کنید.

محدودیت ها

من می‌خواستم ویژگی‌های سفارشی را به داده‌های تله‌متری اضافه کنم و با داده‌هایی که می‌فرستیم عمدی‌تر رفتار کنم، و اطمینان حاصل کنم که فقط موارد ضروری و معنی‌دار را جمع‌آوری می‌کنیم.

تغییرات کد:افزودن ویژگی های سفارشی آنطور که من امیدوار بودم ساده نبود. (توجه: ممکن است راهی برای انجام این کار بدون تغییر کد وجود داشته باشد، اما من نتوانستم آن را به کار ببرم.). برای بینش عمدی بیشتر متناسب با نیازهای تجاری ما، ابزار دقیق دستی مورد نیاز است.

قفل فروشنده: من همچنین می خواستم از قفل شدن در یک فروشنده خاص جلوگیری کنم.

آزمایش: من با OpenTelemetry در کناری آزمایش می‌کردم، به‌ویژه از ابزار ابزار خودکار برای پایتون در یکی از سرویس‌های FastAPI خود استفاده می‌کردم.

تغییر به OpenTelemetry

هدف اولیه: من می‌خواستم از استفاده از جمع‌آور اجتناب کنم و در عوض داده‌های تله‌متری را مستقیماً به Azure صادر کنم. Collector یک لایه اضافی از تنظیمات و پیکربندی را اضافه می کند، که در حالی که من هنوز در تلاش برای درک همه اینها هستم، احساس طاقت فرسا می کند.

محدودیت: کتابخانه ابزار خودکار Spring OpenTelemetry به طور پیش‌فرض از OTLP به عنوان صادرکننده استفاده می‌کند، و من نتوانستم راه ساده‌ای برای پیکربندی آن برای صادرات مستقیم به Azure پیدا کنم.

صادر کننده مانیتور Azure: من فکر کردم می‌توان از Azure Monitor Exporter برای ارسال مستقیم داده‌ها به Azure و اجتناب از Collector در حین استفاده از راه‌انداز خودکار ابزار Spring Spring برای OpenTelemetry استفاده کرد.

معرفی گردآورنده: اگرچه هدف اولیه من اجتناب از اضافه کردن یک کلکتور بود، اما در نهایت یکی را برای حل چالش صادرات مستقیم به Azure Monitor معرفی کردم. معلوم شد که قابل کنترل تر از چیزی بود که پیش بینی می کردم 😮‍💨.

توجه: اگر کسی می داند چگونه این کار را بدون کلکتور انجام دهد، دوست دارم بدانم!

استقرار کلکتور

نمودار هلم OTel: من از نمودار OpenTelemetry Helm برای استقرار Collector در خوشه AKS خود استفاده کردم.

تصویر مشارکت گردآورنده: من به تصویر مشارکت جمع‌آوری اشاره کردم که شامل مانیتور Azure به عنوان صادرکننده موجود است.

نتیجه: از آنجایی که ما خدمات زیادی داریم، مجموعه به ما این امکان را می دهد که داده ها را قبل از صادرات تبدیل و غنی سازی کنیم. علاوه بر این، داشتن یک مکان مرکزی برای پردازش داده ها، مدیریت و مقیاس دهی تله متری در چندین سرویس را بسیار آسان تر می کند.

راه اندازی بدون کلکتور

+—————————————-+
| Instrumented Applications |
| (e.g., FastAPI, Spring Boot with OTel) |
|—————————————-|
| – Generates telemetry (traces, metrics,|
| logs) using OTel SDK |
| – Has its own Exporter 🚀 |
+—————–|———————-+
|
v
+—————————————-+
| 🛰️ Observability Backend |
|—————————————-|
| – Data Storage |
| – Query & Visualization (e.g.,Azure |
| Honeycomb, Grafana, Prometheus |
| 📊 Insights and Monitoring |
+—————————————-+

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

راه اندازی با Collector

+—————————————-+
| Instrumented Applications |
| (e.g., FastAPI, Spring Boot with OTel) |
|—————————————-|
| – Generates telemetry (traces, metrics,|
| logs) using OTel SDK |
| – Has simple Exporter to Collector 🚀 |
+—————–|———————-+
|
v
+—————————————-+
| 🚀 OpenTelemetry Collector |
|—————————————-|
| 📥 Receivers |
| – Collect telemetry data from apps |
| |
| 🔄 Processors |
| – Transform and enrich data |
| |
| 📤 Exporters |
| – Send data to observability backend |
+—————–|———————-+
|
v
+—————————————-+
| 🛰️ Observability Backend |
|—————————————-|
| – Data Storage |
| – Query & Visualization (e.g., Azure |
| Honeycomb, Prometheus, Grafana) |
| 📊 Insights and Monitoring |
+—————————————-+

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

نمونه values.yaml برای استقرار کلکتور به AKS با استفاده از Helm

image:
repository: “otel/opentelemetry-collector-contrib”
tag: “latest”
config:
receivers:
otlp:
protocols:
http:
endpoint: “0.0.0.0:4318”
grpc:
endpoint: “0.0.0.0:4317”

processors:
batch:
send_batch_size: 1024

exporters:
azuremonitor:
connection_string: “”

service:
pipelines:
traces:
receivers: [otlp] processors: [batch] exporters: [azuremonitor] metrics:
receivers: [otlp] processors: [batch] exporters: [azuremonitor] logs:
receivers: [otlp] processors: [batch] exporters: [azuremonitor] extensions:
health_check:
endpoint: “0.0.0.0:13133”

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

+----------------------------------------+
|          Instrumented Applications     |
| (e.g., FastAPI, Spring Boot with OTel) |
|----------------------------------------|
| - Generates telemetry (traces, metrics,|
|   logs) using OTel SDK                 |
| - Has its own Exporter 🚀              |
+-----------------|----------------------+
                  |
                  v
+----------------------------------------+
|         🛰️ Observability Backend       |
|----------------------------------------|
| - Data Storage                         |
| - Query & Visualization (e.g.,Azure    |
| Honeycomb, Grafana, Prometheus         |
| 📊 Insights and Monitoring             |
+----------------------------------------+

+----------------------------------------+
|          Instrumented Applications     |
| (e.g., FastAPI, Spring Boot with OTel) |
|----------------------------------------|
| - Generates telemetry (traces, metrics,|
|   logs) using OTel SDK                 |
| - Has simple Exporter to Collector 🚀  |
+-----------------|----------------------+
                  |
                  v
+----------------------------------------+
|       🚀 OpenTelemetry Collector       |
|----------------------------------------|
| 📥 Receivers                           |
|   - Collect telemetry data from apps   |
|                                        |
| 🔄 Processors                          |
|   - Transform and enrich data          |
|                                        |
| 📤 Exporters                           |
|   - Send data to observability backend |
+-----------------|----------------------+
                  |
                  v
+----------------------------------------+
|          🛰️ Observability Backend      |
|----------------------------------------|
| - Data Storage                         |
| - Query & Visualization (e.g., Azure   |
|   Honeycomb, Prometheus, Grafana)      |  
| 📊 Insights and Monitoring             |
+----------------------------------------+

image:
  repository: "otel/opentelemetry-collector-contrib"
  tag: "latest"
config:
  receivers:
    otlp:
      protocols:
        http:
          endpoint: "0.0.0.0:4318"
        grpc:
          endpoint: "0.0.0.0:4317"

  processors:
    batch:
      send_batch_size: 1024

  exporters:
    azuremonitor:
      connection_string: ""

  service:
    pipelines:
      traces:
        receivers: [otlp]
        processors: [batch]
        exporters: [azuremonitor]
      metrics:
        receivers: [otlp]
        processors: [batch]
        exporters: [azuremonitor]
      logs:
        receivers: [otlp]
        processors: [batch]
        exporters: [azuremonitor]
  extensions:
    health_check:
        endpoint: "0.0.0.0:13133"