OpenTelemetry: استانداردی که شما را به فروشنده گره نمی‌زند
تا همین چند سال پیش، انتخاب ابزار پایش یک تصمیم یک‌طرفه بود. عامل اختصاصی فروشنده را در کدتان می‌کاشتید، کتابخانه‌اش را همه‌جا صدا می‌زدید، و از آن به بعد مهاجرت یعنی تکرار همهٔ آن کار.
OpenTelemetry — که معمولاً OTel نوشته می‌شود — دقیقاً برای شکستن همین گره ساخته شد. ایده‌اش یک جمله است: تولید داده را از مصرف داده جدا کن.
چه چیزی را استاندارد می‌کند
سه چیز، و هر سه لازم‌اند تا وعده عملی شود.
قالب داده. یک نمایش مشترک برای ردیابی، سنجه و لاگ، به‌علاوهٔ قراردادهای معنایی — یعنی توافق بر سر اینکه اسم فیلد «کد وضعیت HTTP» چه باشد. این بخش دوم کم‌تر جلب توجه می‌کند و عملاً مهم‌تر است: بدون آن، داشبوردی که برای یک سرویس نوشته‌اید روی سرویس بعدی کار نمی‌کند.
پروتکل انتقال. OTLP، که تقریباً هر مقصد جدی امروز می‌فهمدش.
کتابخانه‌های ابزارگذاری. برای زبان‌های رایج، و برای چارچوب‌های پرکاربرد به‌صورت خودکار — یعنی بدون دست زدن به کد، بیشتر درخواست‌های HTTP و پرس‌وجوهای پایگاه داده‌تان ردیابی می‌شوند.
بلوغ: یک عدد نیست، و اینجا جایی است که آدم‌ها اشتباه می‌کنند
بزرگ‌ترین سوءتفاهم این است که OTel را «آماده» یا «آماده نیست» فرض کنند. واقعیت این است که بلوغ به‌ازای هر سیگنال و هر زبان فرق می‌کند. وضعیت رسمی، که خودشان منتشر می‌کنند:
| سیگنال | وضعیت |
|---|---|
| ردیابی | در بیشتر زبان‌ها پایدار — بالغ‌ترین بخش |
| سنجه | در C++، دات‌نت، Go، جاوا، جاوااسکریپت و PHP پایدار؛ در Erlang، روبی و سوییفت هنوز در حال توسعه |
| لاگ | وضعیت مختلط — در C++، دات‌نت و PHP پایدار، در Go نامزد انتشار، در جاوا، جاوااسکریپت، پایتون، روبی و سوییفت در حال توسعه |
| پروفایل | تازه‌ترین سیگنال؛ فقط جاوا چیزی پیاده‌سازی کرده |
نتیجهٔ عملی‌اش برای تصمیم شما: با ردیابی شروع کنید. آنجا استاندارد جا افتاده و ریسکی نمی‌کنید. سنجه را بسته به زبانتان بررسی کنید. برای لاگ، فعلاً در بیشتر پشته‌ها راه‌حل موجود خودتان را نگه دارید و منتظر بمانید — این توصیه ممکن است سال دیگر عوض شود و همین که ممکن است عوض شود، خودش نکته است.
چرا برای ما این فقط «تمیزکاری معماری» نیست
در یک تیم در برلین، مستقل بودن از فروشنده یک مزیت است: قدرت چانه‌زنی، آزادی انتخاب.
برای ما یک موضوع دیگر است. سرویسی که امروز کار می‌کند، ممکن است فردا دسترسی‌اش قطع شود — و این فرض بدبینانه نیست، سابقهٔ تکرارشده است. در آن روز، تنها سؤالی که اهمیت دارد این است: عوض کردن مقصد، یک تغییر پیکربندی است یا یک پروژه؟
با ابزارگذاری استاندارد، جواب اولی است. بدون آن، دومی — و در بدترین زمان ممکن.
همان استدلالی که در وابستگی به تأمین‌کننده در سطح خرید سازمانی گفته‌ایم، اینجا شکل فنی و مشخصش را دارد.
معماری عملی
میان برنامهٔ شما و مقصد، یک جزء واسط می‌گذارید که Collector نامیده می‌شود. برنامه‌ها داده را به آن می‌دهند، و او تصمیم می‌گیرد کجا بفرستد.
ارزشش در سه چیز است که بدون آن سخت‌اند:
نمونه‌گیری متمرکز. اگر همهٔ ردیابی‌ها را نگه دارید، هزینه‌تان منفجر می‌شود؛ اگر تصادفی دور بریزید، همان‌هایی را دور می‌ریزید که لازم داشتید. Collector می‌تواند مثلاً هر ردیابی‌ای که خطا دارد یا کند بوده را کامل نگه دارد و از بقیه نمونه بردارد.
پاک‌سازی. حذف فیلدهای حساس، پیش از آنکه از زیرساخت شما خارج شوند.
و چند مقصد هم‌زمان. همان داده می‌تواند هم‌زمان به یک پشتهٔ خودمیزبان و به یک مقصد آزمایشی برود — که راه عملی مهاجرت بدون قطعی است.
مقصدها
OTel خودش داده را نگه نمی‌دارد. این را زیاد اشتباه می‌فهمند: OpenTelemetry جایگزین Prometheus یا Sentry نیست؛ چیزی است که به آن‌ها داده می‌دهد.
Prometheus از نسخه‌های اخیر OTLP را مستقیماً می‌پذیرد —
با یک تلهٔ کوچک که وقت زیادی گرفته: گیرندهٔ OTLP پیش‌فرض خاموش است. باید با
--web.enable-otlp-receiver روشنش کنید و داده را به /api/v1/otlp/v1/metrics
بفرستید. اگر کار نکرد، قبل از اینکه دنبال مشکل شبکه بگردید، این را ببینید.
پشتیبانی از زمان‌مندی تفاضلی هم هنوز آزمایشی است و پرچم جدا دارد.
Sentry هم OTLP را می‌پذیرد، ولی تمرکزش خطا و خرابی است نه سنجهٔ زیرساخت. در عمل بیشتر تیم‌ها هر دو را دارند و این اشکالی ندارد — مقایسه‌شان در پشته‌های سنجه و لاگ، کنار هم.
آنچه حل نمی‌کند
سه چیز، که اگر انتظارشان را داشته باشید ناامید می‌شوید.
استاندارد به شما نمی‌گوید چه چیزی را اندازه بگیرید. قالب را یکی می‌کند، قضاوت را نه. سنجهٔ بی‌ربطِ استاندارد، همچنان بی‌ربط است.
ابزارگذاری خودکار همه‌چیز را نمی‌گیرد. منطق کسب‌وکار شما — «ثبت سفارش چقدر طول کشید» در مقابل «این درخواست HTTP چقدر طول کشید» — دست‌نویس است و همان هم ارزش واقعی را دارد.
و مهاجرت رایگان نیست. اگر امروز عامل اختصاصی دارید، عوض کردنش کار است. حرف ما این نیست که این کار را همین فردا بکنید؛ این است که سرویس بعدی‌تان را استاندارد ابزارگذاری کنید و بگذارید قدیمی‌ها به‌مرور بیایند.
اگر بخواهیم یک جمله از این مقاله بماند: OTel را برای امروزتان نمی‌گیرید، برای روزی می‌گیرید که مجبور شوید مقصد را عوض کنید. و آن روز، معمولاً روزی نیست که وقت یک پروژهٔ ابزارگذاری دوباره را داشته باشید.