در باب OpenTelemetry

Author: امین مصباحی

Site: امین مصباحی

Source: https://mesbahi.net/fa/blog/1403/10/02/intro-opentelemetry

⚠️ Article content is partial (Telegram Instant View delivered in segments).

✨✨*** اندر باب OpenTelemetry**

از اونجایی که دورهمی بعدی‌مون در مورد سیستم‌های توزیع‌شده است، مطالب دیروز (workload) و این مطلب (OpenTelemetry) پیش‌درآمدی است برای دوستانی که آشنایی کمتری دارن ولی دوست دارن از دورهمی استفاده بیشتری ببرن.

به زبون ساده و تا حد امکان کوتاه، OpenTelemetry رو توضیح دادم و Log, Metric و Trace مرور کردم. اگر دوست داشتید مطالعه کنید (instant view تلگرام دسکتاپ مشکلاتی با فارسی داره که اگر روی دسکتاپ مطالعه می‌کنید بهتره تا لینک رو باز کنید)

📎 لینک مطلب

💬 نظر، سوال، گپ‌ و گفت؟ 😉

📢 tech-afternoon

🖼️ Photo

مقدمه
حتماً اسم OpenTelemetry (یا همون OTel) رو حول و حوش موضوعات مانیتورینگ و لاگینگ، شنیدین. هرچقدر تنوع کامپوننت‌ها، سرویس‌ها، اپلیکیشن‌ها بیشتر بیشتر بشه؛ یا به زبون ساده سیستم توزیع بشه، لزوم استفاده از یک استاندارد یا مکانیزم فراگیر، اهمیتش بیشتر می‌شه. فکر کنید لاگ رو با یه فرمتی که مختص دات‌نت باشه بنویسیم، یا اندازه‌گیری پرفرمنس سرویس دات‌نتی‌مون، مستقل از بخش فرانت که با ری‌اکت یا… نوشتیم باشه، ربط دادن و تحلیل داده‌های جمع شده چقدر دشوار می‌شه؟؟ ولی وقتی استانداردی داشته باشیم که هر بخش از نرم‌افزار با اون فرمت داده‌هاش رو به جایی ارسال کنه. و در نقطه‌ی تجمیع داده‌ها هم دستمون باز باشه تا با هر ابزاری که اون فرمت استاندارد رو می‌تونست بفهمه؛ داده‌ها رو جمع‌آوری، پردازش، نمایش و گزارش‌گیری کنیم؛ چقدر ایرادیابی و اشراف به شرایط برامون راحت‌تر می‌شه!
هدفم از این مطلب اینه که درک کنیم چرا OTel یه استاندارد مهم شده و چطوری از وابستگی به یه ابزار یا سرویس خاص برای جمع‌آوری داده‌های تل‌متری (Telemetry) نجاتمون می‌ده.

چرا OpenTelemetry به‌وجود اومد؟

تو سیستم‌های بزرگ، مخصوصاً وقتی سرویس‌های متعددی(.Distributed System, SOA, Microservices, etc) داریم، مانیتور کردن جامع و فراگیر خیلی مهمه. یه زمانی اگه کسی می‌خواست لاگ‌ها، متریک‌ها و تریس‌هاش (که بعدتر هر سه رو توضیح می‌دم) رو جمع کنه، باید ده‌جور کتابخونه و Agent می‌ذاشت که هر کدوم، داده‌هاش رو یه جور مختلف تحویل می‌داد. خلاصه آشفته می‌شد!

اینجا بود که پروژه‌های مختلفی مثل OpenTracing و OpenCensus سعی کردن این مشکل رو حل کنن اما هردوشون تا حدی موازی پیش می‌رفتن و هنوز یه استاندارد یکی نبود. Cloud Native Computing Foundation (CNCF) اومد گفت بیا این دوتا رو باهم یکی کنیم که یه استاندارد درست و حسابی و واحد درست بشه. از ترکیب این دوتا، محصول جدیدی به اسم OpenTelemetry متولد شد. حالا دیگه این استاندارد از طرف کلی شرکت و ابزار تجاری و اوپن‌سورس ساپورت می‌شه.

OpenTelemetry دقیقاً چیه؟

به زبان خیلی ساده، OpenTelemetry ابزار (یا بهتره بگیم یه مجموعه ابزار) و چهارچوبیه که کمک می‌کنه بتونیم داده‌های مربوط به لاگ‌ها، متریک‌ها و تریس‌ها رو به شکل استانداردی جمع کنیم و بفرستیم هر جایی که می‌خوایم. مثلاً می‌تونیم بفرستیم به Elastic, Prometheus, Jaeger, Datadog و… بدون اینکه مجبور بشیم توی کدمون کلی تغییرات عجیب و غریب بدیم. نکته باحال اینه که OTel خودش بک‌اند مانیتورینگ یا دیتابیس نگهداری داده‌های ما نیست؛ فقط کارش تولید، جمع‌آوری و ارسال این داده‌ها به سرویس مد نظره.

فایده‌اش؟

• استاندارد کردن فرمت داده‌ها (یعنی هر کی و هر سرویسی گفت لاگ، تریس، متریک؛ دیگه مشخصه چی رو چه شکلی می‌فرسته، حالا می خواد یه نرم‌افزار جاوایی باشه، یا یه کد دات‌نت یا نرم‌افزار IoT).
• جداکردن ابزار جمع‌آوری داده از محل ذخیره و تحلیل داده. یعنی می‌تونید خیلی راحت ابزار بک‌اندتون رو عوض کنید (ابزار دریافت و ذخیره‌سازی و تحلیل داده‌های دریافت شده با استاندارد OpenTelemetry).
• پشتیبانی توسط اکثر زبان‌ها و فریم‌ورک‌ها؛ پس اگه یه گوشه پروژه‌تون با Go نوشته شده و یه گوشه دیگه با دات‌نت، باز همه‌اش می‌تونه داده‌ها رو یکپارچه بده بیرون.

سه پایه‌ی اصلی: لاگ‌ها، متریک‌ها و تریس‌ها

1. لاگ‌ها (Logs):
   یه جورایی ساده‌ترین نوع داده. وقتی یه چیزی تو سیستم اتفاق می‌افته، ما میایم می‌نویسیمش. مثلاً «کاربر فلانی لاگین کرد»، «خطای ۵۰۰ پیش اومد»، «سرویس ایمیل فلان پیام را ارسال کرد» و … به کمک لاگ‌ها می‌فهمیم که چه وقایعی در چه زمانی رخ داده. (دو جور لاگ هم داریم، لاگ ساختارمند و غیرساختاری -> Structured Log, Unstructured Log)
2. متریک‌ها (Metrics):
   عدد و رقم‌های زمان‌بندی‌شده. مثلاً نرخ درخواست در ثانیه (RPS) چقدره؟ CPU یا مموری مصرفی چقدره؟ پینگ یک سرویس دیگه چقدره؟ با متریک‌ها می‌تونیم وضعیت عملکرد سیستم رو تو بازه‌های زمانی مختلف مانیتور کنیم. حتی داده‌های بیزنسی: تعداد خریدهای موفق در یک ساعت، تعداد خروجی از انبار در یک دقیقه، مرخصی‌های ثبت شده در یک هفته و…) که باهاشون میشه BAM (Business Activity Monitor) و Business Dashboard ساخت.
3. تریس‌ها (Traces):
   ردگیری جریانِ درخواست‌ها، توی سرویس‌های مختلف. مخصوصاً وقتی داریم تو یه معماری مایکروسرویسی کار می‌کنیم، هر درخواست ممکنه از ده‌ها سرویس رد بشه. با تریس‌ها راحت می‌فهمیم که این درخواست کجا چرخیده و اگه مشکلی پیش اومده، کجا کندی یا خطا داشته. توی سیستم‌های توزیع‌شده این ماجرا حیاتیه وگرنه به کابوس شبانه سلام کنید!

هر سه تای این‌ها «سیگنال»های مهمی هستن برای اینکه سیستم رو Observable کنیم. یعنی بتونیم از بیرون بفهمیم داخل چه خبره.

ساختار کلی OpenTelemetry

پکیج‌های مختلفی داره که هر کدوم یه کاری می‌کنن:

• API: این بخش در زبان‌های مختلف ارائه شده؛ در دات‌نت هم APIهایی داریم که اجازه می‌ده کدمون رو برای جمع‌آوری تریس و متریک و لاگ تجهیز کنیم. (OpenTelemetry.Api)
• SDK: پیاده‌سازی همون API و مسئولیت مدیریت و ارسال این داده‌ها رو داره.
• Instrumentation: کتابخونه‌های آماده‌ای که برای کار با ASP.NET Core, HttpClient, SqlClient و… ارائه شدن تا بدون دردسر اضافه، بشه درخواست‌ها و متریک‌ها رو جمع کرد.
• Collector: یه سرویس مجزاست که داده‌هایی که OTel تولید می‌کنه رو دریافت می‌کنه، پردازش می‌کنه و می‌فرسته به هر بک‌اندی که دوست داشته باشید. این وسط می‌تونین داده‌ها رو فیلتر، غنی‌سازی (داده اضافه کنین، enrich کنین) یا یه جای دیگه بفرستین.

مثال کد در .NET برای تریس و متریک