OpenTelemetry چیست و چگونه می تواند کیفیت Backend شما را بهبود بخشد؟

در گذشته، وقتی در مورد باطن صحبت میکردیم، معمولاً به یک برنامه بزرگ با یک پایگاه داده واحد و بزرگ اشاره میکردیم و لاگ برای نظارت کافی بود. اکنون، به لطف فناوریهایی مانند ، به استاندارد تبدیل شدهاند. تعداد برنامهها و توزیعشدهتر هستند و ثبتنام سنتی دیگر برای و تشخیص مشکلات در برنامههای ما کافی نیست. Kubernetes میکروسرویسها اشکالزدایی یک راه حل عالی برای سازماندهی نظارت OpenTelemetry است - یک ابزار مدرن که می تواند برای اشکال زدایی و تجزیه و تحلیل عملکرد سیستم های توزیع شده استفاده شود. این مقاله برای متخصصان فناوری اطلاعات در نظر گرفته شده است که به دنبال گسترش دانش خود در بهینه سازی باطن هستند. در زیر، OpenTelemetry چیست، مفاهیم کلیدی آن، و مشکلاتی که به حل آن کمک می کند را به تفصیل شرح خواهیم داد. اگر علاقه مند هستید که OpenTelemetry چگونه می تواند رویکرد شما به نظارت و اشکال زدایی سیستم های باطن را تغییر دهد و قابلیت اطمینان و کارایی آنها را افزایش دهد - ادامه مطلب را بخوانید. تاریخچه مختصری از OpenTelemetry شرکت های بزرگ فناوری ابتدا در اواخر دهه 2000 با چالش ثبت و ردیابی توزیع شده مواجه شدند. در سال 2010، گوگل مقاله ای منتشر کرد، ، که اساس ابزار ردیابی توییتر، Zipkin را ایجاد کرد که در سال 2012 منتشر شد. Dapper، یک زیرساخت ردیابی سیستم های توزیع شده در مقیاس بزرگ در سال 2014، Kubernetes ظهور کرد، که به طور قابل توجهی توسعه میکروسرویس ها و سایر سیستم های توزیع شده در ابر را ساده کرد. این امر باعث شد که بسیاری از شرکتها با مشکلات ثبت و ردیابی توزیع شده در میکروسرویسها مواجه شوند. برای استانداردسازی ردیابی توزیع شده، استاندارد OpenTracing که توسط CNCF و پروژه OpenCensus گوگل پذیرفته شده است ایجاد شد. در سال 2019، پروژه های OpenTracing و OpenCensus ادغام با نام OpenTelemetry را اعلام کردند. این پلتفرم بهترین شیوههای انباشتهشده در طول سالهای متمادی را ترکیب میکند و امکان ادغام یکپارچه ردیابی، ورود به سیستم و معیارها را در هر سیستمی بدون در نظر گرفتن پیچیدگی آنها فراهم میکند. امروزه OpenTelemetry فقط یک پروژه نیست. این یک استاندارد صنعتی برای جمع آوری و انتقال داده های تله متری است. این توسط جامعه ای از متخصصان و شرکت های پیشرو در بازار مانند گوگل و مایکروسافت توسعه یافته و پشتیبانی می شود. این پروژه همچنان به تکامل خود ادامه میدهد و قابلیتهای جدیدی برای سادهسازی فرآیند یکپارچهسازی و استفاده به دست میآورد. داخل چیست؟ OpenTelemetry مجموعهای جامع از شیوهها و ابزارهایی است که مشخص میکند یک برنامه چه سیگنالهایی را میتواند برای تعامل با دنیای خارج تولید کند و چگونه این سیگنالها را میتوان جمعآوری و تجسم کرد تا وضعیت برنامهها و سیستم را بهعنوان یک کل کنترل کند. سه نوع اصلی سیگنال عبارتند از و . ردیابی، ورود به سیستم جمع آوری معیارها ** بیایید نگاهی دقیق تر به هر مؤلفه بیندازیم: \ زمینه ها OpenTelemetry مفهوم زمینه های عملیات را معرفی می کند. یک زمینه عمدتاً شامل ویژگیهایی مانند (شناسه برای عملیات جاری) و (شناسه برای یک درخواست فرعی، با هر تلاش مجدد از یک درخواست فرعی دارای یک » منحصربهفرد است. `trace_id` `span_id` `span_id` علاوه بر این، یک زمینه می تواند حاوی اطلاعات ثابت باشد، مانند نام گره ای که برنامه در آن مستقر است یا نام محیط (prod/qa). این فیلدها که در اصطلاحات OpenTelemetry به عنوان منابع شناخته می شوند، برای جستجوی آسان تر به هر گزارش، متریک یا ردیابی متصل می شوند. زمینهها همچنین میتوانند شامل دادههای پویا باشند، مانند شناسه نقطه پایانی فعلی ( )، که میتواند بهطور انتخابی به گروههایی از گزارشها، معیارها یا ردیابیها متصل شود. `http_path: "GET /user/:id/info"` زمینه های OpenTelemetry را می توان با استفاده از پروتکل های انتشار متن بین برنامه های مختلف ارسال کرد. این پروتکلها شامل مجموعههای هدر هستند که به هر درخواست HTTP یا gRPC یا سرصفحههای پیامها برای صفها اضافه میشوند. این به برنامه های کاربردی پایین دستی اجازه می دهد تا زمینه عملیات را از این هدرها بازسازی کنند. در اینجا چند نمونه از انتشار متن آورده شده است: این مجموعه ای از هدرها ( ) است که در ابتدا برای سیستم ردیابی Zipkin توسعه یافته است. با OpenTracing تطبیق داده شد و توسط بسیاری از ابزارها و کتابخانه ها استفاده شد. B3- Propagation حاوی / و یک پرچم است که نشان می دهد آیا نمونه برداری ضروری است یا خیر. B3-Propagation x-b3-* trace_id span_id که توسط گروه کاری W3C توسعه یافته است، این استاندارد رویکردهای مختلف انتشار زمینه را در یک استاندارد واحد متحد می کند و پیش فرض در OpenTelemetry است. یک مثال خوب از بکارگیری این استانداردها، ردیابی اجرای درخواستی است که از طریق میکروسرویسهای پیادهسازی شده با فناوریهای مختلف بدون به خطر انداختن دقت نظارت و اشکالزدایی عبور میکند. W3C Trace Context ردیابی ردیابی فرآیند ثبت و متعاقباً تجسم جدول زمانی مسیر درخواست از طریق چندین میکروسرویس است. در تجسم، هر نوار یک "span" نامیده می شود و یک منحصر به فرد دارد. دهانه ریشه به عنوان نامیده می شود و دارای است که به عنوان شناسه برای کل درخواست عمل می کند. "span_id" "trace" "trace_id" این نوع تجسم به شما امکان می دهد: برای شناسایی تنگناهایی که نیاز به بهینه سازی دارند، زمان اجرای درخواست ها را در سیستم ها و پایگاه های مختلف تجزیه و تحلیل کنید. وابستگی های چرخه ای بین سرویس ها را تشخیص دهید. درخواست های تکراری را پیدا کنید با استفاده از دادههای ردیابی، میتوانید تجزیه و تحلیلهای اضافی مانند ایجاد یک نقشه میکروسرویس یا توزیع زمان در سیستمهای مختلف در طول پردازش عملیات ایجاد کنید. حتی اگر از دادههای ردیابی برای تجسم خطوط زمانی استفاده نکنید، OpenTelemetry همچنان و برای استفاده در سیگنالهای دیگر تولید میکند. trace_id span_id سیاههها علیرغم سادگی ظاهری آن، ثبت گزارش یکی از قدرتمندترین ابزارها برای تشخیص مشکلات است. OpenTelemetry با افزودن اطلاعات متنی، ورود به سیستم سنتی را افزایش می دهد. به طور خاص، اگر یک ردیابی فعال وجود داشته باشد، ویژگیهای «trace_id» و «span_id» بهطور خودکار به گزارشها اضافه میشوند و آنها را به خط زمانی ردیابی پیوند میدهند. علاوه بر این، ویژگیهای گزارش میتوانند شامل اطلاعات استاتیک از زمینه OpenTelemetry، مانند شناسه گره، و همچنین اطلاعات پویا، مانند شناسه نقطه پایانی HTTP («http_path: «GET /user/:id»») باشند. با استفاده از «trace_id»، میتوانید گزارشهایی را از همه میکروسرویسهای مرتبط با درخواست فعلی پیدا کنید، در حالی که «span_id» به شما امکان میدهد بین درخواستهای فرعی تفاوت قائل شوید. برای مثال، در مورد تلاشهای مجدد، گزارشهای حاصل از تلاشهای مختلف، «span_id» متفاوتی خواهند داشت. استفاده از این شناسه ها تجزیه و تحلیل سریع رفتار کل سیستم را در زمان واقعی امکان پذیر می کند، تشخیص مشکل را تسریع می بخشد و ثبات و قابلیت اطمینان را افزایش می دهد. معیارها مجموعه معیارها داده های کمی را در مورد عملکرد سیستم، مانند تأخیر، نرخ خطا، استفاده از منابع و موارد دیگر ارائه می دهد. نظارت بر زمان واقعی معیارها به شما امکان می دهد به سرعت به تغییرات عملکرد پاسخ دهید، از خرابی ها و فرسودگی منابع جلوگیری کنید و از در دسترس بودن و قابلیت اطمینان بالای برنامه برای کاربران اطمینان حاصل کنید. ادغام با ذخیرهسازی متریک و سیستمهای تجسم مانند Prometheus و Grafana تجسم این دادهها را آسانتر میکند و نظارت را به طور قابل توجهی ساده میکند. کلکسیونرهای متریک کلکسیونرهای متریک OpenTelemetry با استانداردهای Prometheus و OpenMetrics سازگار هستند و امکان انتقال آسان به راه حل های OpenTelemetry را بدون تغییرات قابل توجه فراهم می کنند. OpenTelemetry SDK به نمونههای trace_id اجازه میدهد تا همراه با معیارها صادر شوند و این امکان را فراهم میکند که معیارها را با نمونههای گزارش و ردیابی مرتبط کنیم. همبستگی سیگنال گزارشها، متریکها و ردیابی با هم یک نمای جامع از وضعیت سیستم ایجاد میکنند: گزارشها اطلاعاتی در مورد رویدادهای سیستم ارائه میدهند که امکان شناسایی و حل سریع خطاها را فراهم میکند. معیارها شاخص های عملکرد کمی و کیفی سیستم مانند زمان پاسخ یا نرخ خطا را منعکس می کنند. ردیابی این دیدگاه را با نشان دادن مسیر اجرای درخواست از طریق اجزای مختلف سیستم تکمیل می کند و به درک روابط متقابل آنها کمک می کند. ارتباط واضح بین گزارشها، ردیابیها و متریکها یکی از ویژگیهای متمایز OpenTelemetry است. به عنوان مثال، Grafana به کاربران این امکان را می دهد که هنگام مشاهده یک گزارش، معیارهای ردیابی و درخواست مربوطه را مشاهده کنند، که کاربرد و کارایی پلت فرم را بسیار افزایش می دهد. علاوه بر سه جزء اصلی، OpenTelemetry شامل مفاهیم نمونه برداری، چمدان و مدیریت زمینه عملیات است. نمونه برداری در سیستمهای با بار بالا، حجم گزارشها و ردیابیها بسیار زیاد میشود و به منابع قابل توجهی برای زیرساخت و ذخیرهسازی داده نیاز دارد. برای پرداختن به این مشکل، استانداردهای OpenTelemetry شامل نمونهبرداری سیگنال میشوند - توانایی صادر کردن تنها بخشی از ردیابیها و گزارشها. به عنوان مثال، می توانید سیگنال های دقیق را از درصدی از درخواست ها، درخواست های طولانی مدت یا درخواست های خطا صادر کنید. این رویکرد امکان نمونه گیری کافی را برای ایجاد آمار و در عین حال صرفه جویی در منابع قابل توجه می دهد. با این حال، اگر هر سیستم به طور مستقل تصمیم بگیرد که کدام درخواست ها را با جزئیات نظارت کند، در نهایت با یک نمای تکه تکه از هر درخواست مواجه می شویم. برخی از سیستم ها ممکن است داده های دقیق را صادر کنند در حالی که برخی دیگر ممکن است فقط تا حدی صادر کنند یا اصلاً صادر نکنند. برای حل این مشکل، مکانیسمهای انتشار متن OpenTelemetry یک پرچم نمونه را همراه با «trace_id»/«span_id» ارسال میکند. این تضمین می کند که اگر سرویس اولیه دریافت کننده درخواست کاربر تصمیم بگیرد که درخواست باید با جزئیات نظارت شود، همه سیستم های دیگر از این روش پیروی خواهند کرد. در غیر این صورت، همه سیستم ها باید به طور جزئی سیگنال ها را برای حفظ منابع صادر کنند یا ندهند. این رویکرد "نمونه گیری سر" نامیده می شود - تصمیمی که در ابتدای پردازش درخواست، به صورت تصادفی یا بر اساس برخی ویژگی های ورودی گرفته می شود. علاوه بر این، OpenTelemetry از "Tail Sampling" پشتیبانی می کند، جایی که همه برنامه ها همیشه همه سیگنال ها را با جزئیات صادر می کنند، اما یک بافر میانی وجود دارد. پس از جمع آوری تمام داده ها، این بافر تصمیم می گیرد که آیا کل داده ها را حفظ کند یا فقط یک نمونه جزئی را نگه دارد. این روش اجازه می دهد تا نمونه ای نماینده تر از هر دسته درخواست (موفق/طولانی/خطا) ارائه شود، اما نیاز به راه اندازی زیرساخت اضافی دارد. چمدان مکانیسم چمدان اجازه می دهد تا جفت های کلید-مقدار دلخواه به همراه / منتقل شوند و به طور خودکار بین همه میکروسرویس ها در طول پردازش درخواست منتقل شوند. این برای انتقال اطلاعات اضافی مورد نیاز در طول مسیر درخواست مفید است - مانند اطلاعات کاربر یا تنظیمات محیط زمان اجرا. trace_id span_id نمونه ای از هدر برای انتقال بار طبق استاندارد W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5 در اینجا چند نمونه از استفاده از چمدان آورده شده است: مانند ، ، یا را می توان از طریق همه میکروسرویس ها منتقل کرد. برنامهها میتوانند بهطور خودکار این اطلاعات را ثبت کنند و امکان جستجوی گزارش بر اساس بافت کاربر برای درخواست اصلی را فراهم کنند. انتقال اطلاعات زمینه کسب و کار userId productId deviceId تنظیمات برای SDK یا زیرساخت. پارامترهای پیکربندی خاص پرچمهایی که به متعادلکنندههای بار در تصمیمگیری مسیریابی کمک میکنند. در طول آزمایش، برخی از درخواستها ممکن است نیاز به مسیریابی به backendهای ساختگی داشته باشند. از آنجایی که چمدان به طور خودکار از طریق همه سرویسها منتقل میشود، نیازی به ایجاد پروتکلهای اضافی نیست-فقط یک قانون را در بار متعادلکننده تنظیم کنید. پرچمهای مسیریابی توجه داشته باشید که در حالی که تأثیر عملکرد چمدان حداقل است، استفاده بیش از حد می تواند به طور قابل توجهی بار شبکه و خدمات را افزایش دهد. برای جلوگیری از مشکلات عملکرد، دادههایی را که واقعاً باید از طریق چمدان ارسال کنید، با دقت انتخاب کنید. پیاده سازی زیرساخت پیادهسازی OpenTelemetry در سطح زیرساخت شامل ادغام پشتیبانهای OpenTelemetry در معماری برنامه و پیکربندی زیرساخت برای تجمیع دادهها است. این فرآیند شامل چهار مرحله است: در مرحله اول، OpenTelemetry SDK مستقیماً در برنامهها ادغام میشوند تا معیارها، گزارشها و ردیابیها را جمعآوری کنند و از جریان مداوم دادهها در مورد عملکرد هر جزء سیستم اطمینان حاصل کنند. یکپارچهسازی برنامهها دادههای جمعآوریشده بسته به نیاز شما، از برنامهها از طریق صادرکنندگان به سیستمهای خارجی برای پردازش بیشتر، مانند ثبت گزارش، نظارت، ردیابی یا سیستمهای تحلیلی هدایت میشوند. پیکربندی صادرکنندگان این مرحله ممکن است شامل عادی سازی داده ها، غنی سازی آن با اطلاعات اضافی و ادغام داده ها از منابع مختلف برای ایجاد یک نمای واحد از وضعیت سیستم باشد. تجمیع و ذخیره سازی در نهایت، داده های پردازش شده به عنوان داشبورد در سیستم هایی مانند Grafana (برای معیارها و ردیابی ها) یا Kibana (برای گزارش ها) ارائه می شوند. این به تیم ها اجازه می دهد تا به سرعت سلامت سیستم را ارزیابی کنند، مسائل و روندها را شناسایی کنند و هشدارها را بر اساس سیگنال های تولید شده تنظیم کنند. تجسم داده ها پیاده سازی اپلیکیشن برای ادغام با یک برنامه، باید OpenTelemetry SDK مناسب را برای زبان برنامه نویسی در حال استفاده وصل کنید یا از کتابخانه ها و چارچوب هایی استفاده کنید که به طور مستقیم از OpenTelemetry پشتیبانی می کنند. OpenTelemetry اغلب رابطهای پرکاربرد را از کتابخانههای شناختهشده پیادهسازی میکند و امکان جایگزینیهای drop-in را میدهد. به عنوان مثال، کتابخانه Micrometer معمولاً برای جمع آوری معیارها در اکوسیستم جاوا استفاده می شود. OpenTelemetry SDK پیادهسازیهای خود را از رابطهای Micrometer ارائه میکند و امکان صادرات متریک را بدون تغییر کد برنامه اصلی فراهم میکند. علاوه بر این، OpenTelemetry پیادهسازی رابطهای OpenTracing و OpenCensus قدیمیتر را ارائه میدهد، که مهاجرت آرام به OpenTelemetry را تسهیل میکند. نتیجه گیری در سیستمهای فناوری اطلاعات، OpenTelemetry میتواند به کلید آینده پشتیبانهای قابل اعتماد و کارآمد تبدیل شود. این ابزار اشکال زدایی و نظارت را ساده می کند و همچنین فرصت هایی را برای درک عمیق عملکرد برنامه و بهینه سازی در سطح جدیدی باز می کند. به جامعه OpenTelemetry بپیوندید تا به شکل دادن به آینده ای کمک کنید که در آن توسعه Backend ساده تر و موثرتر باشد!