| 👀 خبر در یک نگاه:
مطالعه بنچمارک Coroot نشان می‌دهد که هرچند OpenTelemetry در اپلیکیشن‌های Go بینش دقیقی فراهم می‌کند، اما باعث حدود ۳۵٪ سربار CPU و افزایش تاخیر می‌شود. با وجود مزایای تریسینگ، جامعه توسعه‌دهندگان بر نیاز به بهینه‌سازی SDK و بررسی گزینه‌های سبک‌تری مانند eBPF برای حفظ کارایی سیستم تاکید دارد. |
مطالعه بنچمارک جدیدی از پلتفرم مشاهده‌پذیری Coroot، به بررسی هزینه‌های عملکردی پیاده‌سازی OpenTelemetry در برنامه‌های Go با ترافیک بالا پرداخته است. نتایج نشان می‌دهد که اگرچه OpenTelemetry دید عمیقی در سطح تریس فراهم می‌کند، اما سربار قابل‌توجهی به‌همراه دارد؛ از جمله افزایش مصرف CPU، رشد ترافیک شبکه و افزایش تاخیر در زمان بار.
اثرات فعال‌سازی تریسینگ
در این بررسی، از یک سرویس ساده HTTP با پایگاه‌داده درون‌حافظه‌ای استفاده شد و عملکرد پایه آن با نسخه مجهز به ابزارهای کامل OpenTelemetry مقایسه شد. آزمایش‌ها در کانتینرهای Docker روی چهار میزبان لینوکسی اجرا شد.
نتایج اندازه‌گیری شده پس از فعال‌سازی تریسینگ:
- مصرف CPU از ۲ هسته به ۲.۷ هسته افزایش یافت (حدود ۳۵٪ رشد)،
- مصرف حافظه بین ۵ تا ۸ مگابایت بیشتر شد،
- تاخیر صدک ۹۹ از حدود ۱۰ میلی‌ثانیه به ۱۵ میلی‌ثانیه رسید،
- داده‌های تریسینگ حدود ۴ مگابایت بر ثانیه ترافیک خروجی شبکه ایجاد کردند.
این موارد نشان‌دهنده سربار قابل توجه ابزارهای مشاهده‌پذیری در سطح درخواست هستند.
مقایسه تریسینگ مبتنی بر SDK و روش‌های مبتنی بر eBPF
در ادامه، این مطالعه مقایسه‌ای میان تریسینگ مبتنی بر SDK و روش‌های مبتنی بر eBPF انجام داد؛ البته با توجه به این‌که Coroot خود ارائه‌دهنده راهکار مبتنی بر eBPF است، باید این مقایسه را با دقت بیشتری بررسی کرد. eBPF بدون نیاز به تغییر در کد برنامه عمل می‌کند و حتی تحت بار سنگین، در حالتی که تنها متریک‌ها جمع‌آوری می‌شدند، مصرف CPU کمتر از ۰.۳ هسته داشت. Coroot نتیجه‌گیری می‌کند که اگرچه SDK در ارائه جزئیات تریس‌ها برتری دارد، اما سربار آن باید با نیازهای هر سیستم به‌درستی سنجیده شود. در سناریوهایی با منابع محدود و نیاز به تاخیر پایین، استفاده از eBPF ممکن است انتخاب بهتری باشد.
کاربران چه می‌گویند؟
انتشار این ارزیابی بحث‌های زیادی را در جامعه Go به‌راه انداخت. در Hacker News پیشنهاد شد که با بهینه‌سازی‌هایی مانند استفاده از توابع زمان سریع‌تر، جایگزینی Mutexها با Atomicها و بهبود فرایند سریال‌سازی داده‌ها می‌توان عملکرد SDK را ارتقا داد. در Reddit نیز کاربران تاکید کردند که حتی بدون نمونه‌گیری (Zero Sampling)، سربار ناشی از انتشار Context و مدیریت Spanها محسوس است. این دیدگاه‌ها نشان می‌دهند که OpenTelemetry در کنار مزایایش، نیازمند پیاده‌سازی و تنظیمات دقیق برای کاهش بار منابع است.
کاربری با نام FZambia نوشت:
«در ابتدا نسبت به تریسینگ تردید داشتم، چه از نظر سربار منابع و چه کدگذاری نظارتی، در مقایسه با اپلیکیشنی که به‌درستی با متریک‌ها کدگذاری نظارتی شده باشد. اما هرچه زمان گذشت، موارد بیشتری دیدم که تریسینگ در بررسی رخدادها و شناسایی مشکلات واقعا مفید بود. تصویرسازی تریس‌ها در ساده‌سازی ارتباط بین تیم‌ها نقش مهمی دارد. البته Spanها اغلب شامل تگ‌هایی هستند که چندان ضروری نیستند و جمع‌آوری آن‌ها در هر درخواست، کاری زمان‌بر است، به‌ویژه وقتی که از ۹۹.۹۹۹٪ آن‌ها استفاده نمی‌کنید. فعال‌سازی نمونه‌گیری هم مسئله‌ساز است؛ ممکن است دقیقا همان Span موردنیاز را نداشته باشید؛ حتی در صورت موفق بودن درخواست. بنابراین بررسی دقیق سربار تریسینگ، واقعا مفید است.»
در نهایت، بنچمارک‌های Coroot نشان می‌دهد که OpenTelemetry در Go مشاهده‌پذیری قدرتمندی فراهم می‌کند، اما با هزینه‌ای قابل اندازه‌گیری. با وجود تلاش‌ها برای بهینه‌سازی، تیم‌ها باید بین سطح دید موردنیاز و محدودیت‌های عملکردی تعادل ایجاد کرده و در صورت نیاز، گزینه‌های سبک‌تری مانند eBPF را مدنظر قرار دهند.
منبع:
دیدگاهتان را بنویسید