اوپنتلمتری در جنگهای مشاهدهپذیری پیروز شده است. اکنون بخش دشوار آن فرا میرسد.
مشکلی که به اندازه کافی دربارهاش صحبت نمیشود
شما در حال اجرای یک سیستم توزیعشده در محیط تولید هستید. چیزی اشتباه است — تأخیر افزایش یافته، نرخ خطا بالا رفته، یک کاربر در حال ثبت تیکت پشتیبانی است. اولین غریزه شما نگاه کردن به لاگهاست. اما کدام سرویس؟ شما دوازده تا از آنها دارید. لاگها وجود دارند، جایی، پراکنده در سه پشته ابزاری متفاوت که توسط مهندسانی که دیگر آنجا نیستند به جا ماندهاند. شما جستجو میکنید. تغییر مسیر میدهید. بیست دقیقه بعد ریشه مشکل را پیدا میکنید: یک کوئری پایگاه داده که شروع به تایماوت کرده چون یک مهاجرت شِما روی هاست اشتباهی اجرا شده است.
این مشکل مشاهدهپذیری است. نه هشداردهی. نه داشبوردها. مشکل اساسی: درک آنچه واقعاً درون سیستمهای شما در زمانی که اوضاع خراب میشود اتفاق میافتد — و به طور فزاینده، قبل از اینکه خراب شوند. سه سیگنال متعارف عبارتند از لاگها (رویدادهای مجزا)، متریکها (اندازهگیریهای عددی در طول زمان)، و تریسها (سفر یک درخواست از طریق یک سیستم توزیعشده). قبل از OpenTelemetry، جمعآوری هر سه به روشی منسجم و قابل حمل واقعاً دردناک بود.
دوران قفلشدگی
هر فروشنده مشاهدهپذیری — Datadog، New Relic، Dynatrace، Honeycomb، Jaeger — SDK مخصوص خود را عرضه میکرد. عامل مخصوص خود. پروتکل سیمی مخصوص خود. اگر سرویس پایتون خود را با ردیاب Datadog ابزارسازی کرده بودید و بعداً تصمیم به ارزیابی Honeycomb میگرفتید، باید لایه ابزارسازی خود را بازنویسی میکردید. نه به این دلیل که فروشندگان بدخواه بودند، بلکه به این دلیل که هیچ استانداردی وجود نداشت. لایه جمعآوری تلهمتری، خندق محافظ بود.
این یک ناراحتی جزئی نبود. به این معنی بود که تیمها تصمیمات مربوط به فروشنده را زود هنگام میگرفتند، قبل از اینکه دادههای تولیدی کافی برای دانستن نیاز واقعی خود داشته باشند. به این معنی بود که تیمهای پلتفرم چرخههای مهندسی را صرف نگهداری خطوط لوله تلهمتری متعدد میکردند. به این معنی بود که هزینههای جابجایی به اندازهای بالا بود که بیشتر تیمها به سادگی جابجا نمیشدند — حتی وقتی ابزار بهتری ارائه میشد.
OpenTelemetry از کجا آمد
در سال ۲۰۱۹، دو پروژه متنباز رقیب مشاهدهپذیری — OpenCensus (پشتیبانی شده توسط گوگل) و OpenTracing (یک پروژه CNCF) — در OpenTelemetry ادغام شدند. این ادغام از چیزی که میتوانست تکهتکه شدن مضر اکوسیستم باشد جلوگیری کرد. OpenTelemetry به یک پروژه CNCF تبدیل شد و به سرعت رشد کرد. از نظر تعداد مشارکتکنندگان، اکنون دومین پروژه فعال CNCF پس از Kubernetes است.
پیشنهاد ارزش ساده بود: یک بار ابزارسازی کن، به هر جایی صادر کن. یک SDK به ازای هر زبان. یک پروتکل سیمی — OTLP (پروتکل OpenTelemetry). یک جمعکننده — otel-collector — برای دریافت، پردازش و صادر کردن تلهمتری به هر بکاندی. فروشندگان بر روی کیفیت تحلیل و تجسم رقابت میکنند، نه بر روی قفلشدگی ابزارسازی.
وضعیت OTel در سال ۲۰۲۶
شرط جواب داد. OpenTelemetry در محیط تولید در گوگل، مایکروسافت، Shopify، اوبر و هزاران سازمان دیگر مستقر شده است. هر بکاند مشاهدهپذیری اصلی — Datadog، Grafana، Elastic، Honeycomb، Dynatrace، New Relic، Splunk — به طور بومی OTLP را میپذیرد. CNCF گزارش میدهد که OpenTelemetry به نوعی در ۸۳٪ از شرکتهای Fortune 500 استفاده میشود. این دیگر یک پروژه خاص نیست. این زیرساخت است.
SDKهای Go، Java، Python و JavaScript پایدار و به خوبی نگهداری میشوند. ابزارسازی خودکار برای فریمورکهای محبوب — Django، Express، Spring Boot، Rails — به طور قابل اعتمادی کار میکند. میتوانید یک وابستگی واحد اضافه کنید، چند متغیر محیطی تنظیم کنید، و بدون دست زدن به کد برنامه، تریسها را به بکاند خود روانه کنید. برای پروژههای جدید، این نقطه شروع واضحی است.
آنچه واقعاً کار میکند
تریسها قویترین بخش داستان OTel هستند. مشخصات تریس بالغ است. SDKها پایدار هستند. ابزارسازی خودکار برای تماسهای HTTP، پایگاه داده و سیستمهای پیامرسانی رایجترین نیازهای ابزارسازی را پوشش میدهد. اگر امروز با OTel شروع میکنید، از اینجا شروع کنید.
otel-collector قدرتمند و اثباتشده در تولید است. میتواند تلهمتری را از دهها منبع دریافت کند، تبدیلها را اعمال کند، نویز را فیلتر کند و به طور همزمان به چندین بکاند منشعب کند. تیمهایی که محیطهای چند ابری پیچیده را اجرا میکنند از جمعکننده به عنوان یک لایه مسیریابی تلهمتری استفاده میکنند — همه چیز را به جمعکننده صادر کنید، اجازه دهید جمعکننده مسیریابی بکاند را مدیریت کند.
اکوسیستم نیز حول جمعکننده بالغ شده است. دریافتکنندهها و صادرکنندههای کمکی بیشتر منابع داده سازمانی را پوشش میدهند. اپراتور برای Kubernetes محکم است. توزیعهای فروشنده از جمعکننده، بیلدهای آزمایششده و پشتیبانیشده با صادرکنندههای مخصوص فروشنده از پیش پیکربندیشده ارائه میدهند.
آنچه هنوز سخت است
لاگها فقط اخیراً در مشخصات OTel پایدار شدهاند. سیگنال لاگگیری به طور قابل توجهی از تریسها و متریکها عقب بود، و اگرچه اکنون پایدار است، اکوسیستم به طور کامل به آن نرسیده است. همبستگی لاگها با تریسها با استفاده از TraceId و SpanId — که هدف اصلی است — هنوز در بیشتر فریمورکها نیاز به سیمکشی عمدی دارد. کار میکند، اما هنوز بدون تلاش نیست.
قراردادهای معنایی متریکها در بین زبانها ناسازگار است. یک متریک که در SDK جاوا یک نام دارد، در SDK پایتون نام کمی متفاوت دارد. این موضوع در حال بررسی است، اما به کندی. تیمهایی که داشبوردهای بین زبانی میسازند با این اصطکاک مواجه میشوند.
پیکربندی جمعکننده پیچیده است. پیکربندی YAML otel-collector — دریافتکنندهها، پردازشگرها، صادرکنندهها، خطوط لوله — انعطافپذیر اما پرحرف است. با رشد توپولوژیها، به فایلهای YAML برخورد میکنید که واقعاً استدلال درباره آنها دشوار است. هنوز راه حل عالی برای این وجود ندارد.
نمونهگیری مبتنی بر دم قدرتمند اما از نظر عملیاتی سنگین است. پردازشگر tailsampling در OTel Collector کار میکند، اما نیاز به معماری استقرار دقیق دارد تا اطمینان حاصل شود که همه اسپنهای یک تریس معین به یک نمونه جمعکننده میرسند.
مشکل کاردینالیتی که OTel حل نکرد
OpenTelemetry افزودن ویژگیها به تلهمتری شما را آسان میکند. این یک ویژگی است. همچنین یک تلهانداز است. افزودن ویژگیهای با کاردینالیتی بالا — شناسه کاربران، شناسه درخواستها، توکنهای نشست — به متریکها یک اشتباه کلاسیک است که باعث انفجار هزینه در بکاندهایی میشود که به ازای هر سری متریک هزینه دریافت میکنند.
OTel از شما در برابر این محافظت نمیکند. تیمهایی که OTel را اتخاذ میکنند باید این را زود درک کنند: حاکمیت کاردینالیتی متریک اختیاری نیست، بلکه بهداشت عملیاتی است. از ویژگیهای با کاردینالیتی بالا روی اسپنها و لاگها استفاده کنید، جایی که به آن تعلق دارند. ابعاد متریک را پایین و عمداً محدود نگه دارید.
سیگنال چهارم: پروفایلینگ
OpenTelemetry روی یک سیگنال مشاهدهپذیری چهارم کار میکند: پروفایلینگ پیوسته. سیگنال پروفایلینگ OTel هنوز آزمایشی است، اما Grafana، Elastic و چندین فروشنده دیگر از قبل روی آن شرط بستهاند. هدف یک فرمت استاندارد، یک پروتکل سیمی استاندارد، همبستگی با تریسها است.
توصیه عملی برای تیمهایی که امروز OTel را اتخاذ میکنند
- با تریسها شروع کنید. ابتدا از ابزارسازی خودکار استفاده کنید.
- قبل از پیکربندی جمعکننده، بکاند خود را انتخاب کنید. یک صادرکننده واحد برای شروع کافی است.
- زودتر از موعد یک توپولوژی جمعکننده سفارشی راهاندازی نکنید. زمانی که به انشعاب، فیلتر یا غنیسازی نیاز داشتید آن را اضافه کنید.
- قبل از افزودن ویژگیهای متریک، کاردینالیتی را درک کنید. مجموعه برچسبهای مجاز خود را به صراحت تعریف کنید.
- از SDKها استفاده کنید، نه مستقیم از API. فقط در صورتی که در حال نوشتن یک کتابخانه هستید به API وابسته شوید.
جنگ برنده شده است. کار تمام نشده است.
OpenTelemetry به چیزی دست یافته است که در نرمافزار زیرساخت واقعاً نادر است: مشکل قفلشدگی ابزارسازی را از بین برد. فروشندگان بر روی کیفیت تحلیل خود رقابت میکنند — نه بر روی به دام انداختن شما در SDK خود. این دنیای بهتری است.
اما بخش سخت — قراردادهای ثابت بین زبانی، پیکربندی قابل فهم جمعکننده، لاگهای پایدار، حاکمیت کاردینالیتی، پروفایلینگ — هنوز در حال کار است. پایه محکم است. روی آن عمداً بسازید.