معرفی
یگر (Jaeger) سامانه‌ای متن‌باز برای جمعآوری، ذخیره، جست‌وجو و نمایش تریسهای توزیع‌شده است. تریس توزیع‌شده مسیر یک درخواست را هنگام عبور از سرویسها، پایگاه‌های داده و صف‌های پیام نشان میدهد، بنابراین میتوانید ببینید هر بخش از درخواست چه مدت زمان برده و خطا در کجا رخ داده است.
این ابزار در معماری میکروسرویس، سامانههای مبتنی بر API و سرویس‌هایی که چند وابستگی داخلی یا خارجی دارند کاربرد زیادی دارد. یک تریس از چند اسپن (Span) تشکیل می‌شود و هر اسپن بخشی از کار، مانند پردازش یک درخواست HTTP، اجرای پرس‌وجوی پایگاه داده یا فراخوانی سرویس دیگر را ثبت میکند. مسیر و وابستگیهای نمایش‌داده‌شده فقط بخشهایی را پوشش می‌دهند که ابزارسازی شده‌اند و کانتکست تریس را به بخش بعدی منتقل می‌کنند.
مهندسان دواپس، توسعه‌دهندگان بک‌اند و تیم‌های پلتفرم معمولا یگر را کنار ابزارهای متریک و لاگ به‌کار می‌گیرند. یگر جایگزین لاگ‌نویسی یا پایش متریک نیست؛ برای پاسخ به این پرسش مناسب است که «این درخواست مشخص، چرا کند یا ناموفق شد؟» اگر شناسه تریس در لاگ ثبت شود و پیوند میان داده‌ها پیکربندی شود، می‌توان از لاگ‌های Loki یا داشبوردهای Grafana به تریس همان درخواست رسید و جریان عیبیابی را کامل‌تر کرد.
شروع عملی با یگر
از یک مسیر API پرتکرار یا مسئله‌دار شروع کنید. سرویس ورودی و دست‌کم یک سرویس یا وابستگی بعدی در همان مسیر را با OpenTelemetry ابزارسازی کنید، داده را از طریق OTLP به یگر بفرستید و یک درخواست آزمایشی اجرا کنید.
سپس traceId همان درخواست را جست‌وجو کنید. معیار موفقیت اولیه این است که زنجیره کامل اسپن‌های ابزارسازی‌شده، ترتیب فراخوانی‌ها و زمان هر اسپن را ببینید. این کار به تغییر کد یا تنظیمات ابزارسازی، انتشار کانتکست میان سرویسها و نگهداری مسیر دریافت و ذخیره داده نیاز دارد؛ سرویسهای ابزارسازی‌نشده یا مسیرهایی که کانتکست را منتقل نمی‌کنند، نقطه کور تریس خواهند بود.
انتخاب ابزار جایگزین
Zipkin برای تیمی مناسب است که پیش‌تر ابزارسازی یا زیرساخت Zipkin دارد و می‌خواهد با اکوسیستم موجود سازگار بماند. Grafana Tempo برای تیمی قابل بررسی است که Grafana را مرکز مشاهدهپذیری خود قرار داده و ذخیرهسازی تریس را در کنار جریان متریک و لاگ مدیریت میکند. SigNoz برای تیمی مناسبتر است که رابط یکپارچه‌تری برای تریس، متریک و لاگ می‌خواهد و پیچیدگی اتصال چند ابزار جدا را نمی‌پذیرد.
اگر تیم به مشاهدهپذیری یکپارچه با رابط واحد نیاز دارد، یا پیش‌تر ذخیرهسازی و گردش کار تریس را بر مبنای Tempo یا Zipkin ساخته است، یگر انتخاب مناسب‌تری نیست. در ایران، رویه خاص مستند و متمایزی برای انتخاب یگر وجود ندارد. تیم‌ها باید امکان خودمیزبانی، نگهداری فضای ذخیرهسازی، دسترسی عملیاتی و توان پشتیبانی از اجزای مشاهدهپذیری را در زیرساخت خود ارزیابی کنند.
ویژگی‌های کلیدی
برای آشنایی بهتر با این ابزار، توجه به موارد زیر میتواند مفید باشد.
-
نمایش مسیر کامل درخواست
تریس را به‌صورت درختی نمایش میدهد تا ارتباط میان سرویسها، ترتیب فراخوانی‌ها و زمان هر اسپن را در یک درخواست ببینید.
-
جست‌وجوی تریس بر پایه برچسب‌ها
میتوانید تریسها را با نام سرویس، بازه زمانی، مدت اجرا، وضعیت خطا و تگ‌های ثبت‌شده در اسپنها پیدا کنید.
-
تحلیل تأخیر و گلوگاه
زمان اجرای اسپنها نشان میدهد تأخیر اصلی در کدام سرویس، فراخوانی پایگاه داده یا وابستگی خارجی ایجاد شده است.
-
پشتیبانی از OpenTelemetry
میتواند تریسهای تولیدشده با OpenTelemetry را از طریق پروتکل OTLP دریافت کند. در نتیجه، ابزارسازی سرویسها از سامانه ذخیرهسازی و مشاهده تریسها مستقل می‌ماند.
-
نمونهبرداری از تریسها
برای کنترل هزینه ذخیرهسازی و بار پردازشی، می‌توان همه درخواستها یا فقط بخشی از آن‌ها را مطابق سیاست نمونهبرداری ثبت کرد.
-
امکان استقرار روی زیرساخت اختصاصی (خودمیزبان)
اجزای یگر را می‌توان در محیط توسعه، سرورهای داخلی یا کلاستر Kubernetes اجرا و با گزینه‌های ذخیرهسازی سازگار پیکربندی کرد.
کاربردها
در ادامه، مهم‌ترین موارد این بخش به تفکیک معرفی شده‌اند.
-
یافتن علت کندی یک درخواست از سوی کاربر
وقتی یک API کند است، تریس نشان میدهد زمان در منطق سرویس، پرس‌وجوی پایگاه داده، تماس با درگاه بیرونی یا صف پیام صرف شده است.
-
عیبیابی خطا میان چند میکروسرویس
با شناسه تریس می‌توان مسیر یک درخواست ناموفق را از سرویس ورودی تا سرویس یا وابستگی خطادار دنبال کرد.
-
بررسی تاثیر انتشار نسخه جدید
پس از انتشار نسخه جدید، میتوانید زمان پاسخ‌گویی و خطاهای ثبت‌شده در تریسهای سرویس تغییرکرده را با وضعیت معمول آن مقایسه کنید.
-
شناخت وابستگیهای واقعی سرویسها
ردیابی فراخوانی‌های ابزارسازی‌شده و دارای انتشار کانتکست کمک میکند وابستگیهای مسیرهای واقعی اجرا را ببینید؛ این نما جایگزین مستندات کامل معماری نیست.
ابزارهای جایگزین
اگر این ابزار پاسخگوی نیاز شما نبود، گزینه‌های زیر را بررسی کنید.
پرسش‌های رایج درباره یگر
اگر درباره این ابزار پرسشی دارید، ممکن است پاسخ آن را در میان موارد زیر پیدا کنید.
تفاوت یگر با Prometheus چیست؟
Prometheus عمدتا متریکهای عددی مانند مصرف CPU، نرخ خطا و زمان پاسخ را جمعآوری میکند. یگر مسیر یک درخواست مشخص را میان اجزای سامانه نشان میدهد. در یک سامانه مشاهدهپذیر، این دو ابزار معمولا مکمل یکدیگرند.
آیا برای استفاده از یگر باید همه سرویسها را تغییر دهم؟
برای مشاهده یک تریس کامل، سرویسهای درگیر در مسیر درخواست باید شناسه تریس و اطلاعات اسپنها را بهدرستی منتقل کنند. میتوانید کار را از سرویسهای مهم شروع کنید، اما در بخشهایی که ابزارسازی نشدهاند، اطلاعات تریس ناقص خواهد بود.
آیا یگر همان OpenTelemetry است؟
خیر. OpenTelemetry مجموعهای از استانداردها، APIها و ابزارهای ابزارسازی برای تولید و ارسال داده مشاهدهپذیری است. یگر یک سامانه برای دریافت و مشاهده تریسها است و میتواند داده OpenTelemetry را دریافت کند.
یگر برای پروژههای کوچک هم مفید است؟
اگر پروژه فقط یک سرویس ساده با وابستگیهای محدود دارد، استفاده از لاگ و متریک معمولا مناسبتر و کمهزینهتر است. با افزایش تعداد سرویسها، وابستگیهای خارجی یا دشواری عیبیابی درخواستها، استفاده از Jaeger ارزش بیشتری پیدا میکند.
چرا نباید همه تریسها را همیشه ذخیره کرد؟
در سامانههای پرترافیک، ثبت کامل تریسها حجم ذخیرهسازی و هزینه پردازش را افزایش میدهد. انتخاب تریسهای خطادار یا کند برای نگهداری تضمینی، قابلیت عمومی و خودکار یگر نیست و معمولا به نمونهبرداری دنبالهای و پیکربندی OpenTelemetry Collector یا مسیر دریافت داده وابسته است. سیاست نمونهبرداری باید میان جزئیات مورد نیاز و هزینه تعادل برقرار کند.
