OpenTelemetry به استاندارد observability تبدیل شده؛ حالا چالش واقعی استفاده از آن شروع می‌شود

سه سال پیش، تیم‌های مهندسی که می‌خواستند یک stack observability انتخاب کنند، با یک تصمیم دشوار روبرو بودند: یا از agentهای اختصاصی فروشنده استفاده کنند و به آن وابسته شوند، یا ابزارهای open-source مختلف را به هم بچسبانند و بار نگهداری را بپذیرند. OpenTelemetry — پروژه CNCF که در سال ۲۰۱۹ OpenCensus و OpenTracing را ادغام کرد — تا حد زیادی این تصمیم را حل کرده. تا سال ۲۰۲۶، این پروژه به استاندارد de facto برای جمع‌آوری داده‌های telemetry در صنعت تبدیل شده.

Datadog, Honeycomb, Grafana, New Relic, Dynatrace و Splunk همگی داده‌های OpenTelemetry را به صورت native قبول می‌کنند. ارائه‌دهندگان ابری مانند AWS, Google Cloud و Azure نیز integration بومی با OpenTelemetry دارند. SDKهای Python, Java, Go, JavaScript و .NET به انتشار stable رسیده‌اند. OpenTelemetry Collector — کامپوننت pipeline که داده‌های telemetry را دریافت، پردازش و صادر می‌کند — در production شرکت‌هایی از استارتاپ‌های کوچک تا hyperscalerها مستقر شده.

OpenTelemetry جنگ instrumentation را برد. مشکل بعدی استفاده درست از آن است.

OpenTelemetry دقیقاً چه چیزی را استاندارد می‌کند

OpenTelemetry سه سیگنال telemetry تعریف می‌کند: traces (مسیر یک درخواست در سرویس‌های توزیع‌شده)، metrics (اندازه‌گیری‌های عددی در طول زمان) و logs (رکوردهای رویداد ساختاریافته). پروژه SDKهایی برای تولید این سیگنال‌ها، یک wire format (OTLP — OpenTelemetry Protocol) برای انتقال آنها و Collector برای هدایت به backendها فراهم می‌کند.

چیزی که استاندارد نمی‌کند این است که با داده‌ها پس از جمع‌آوری چه کنید. زبان‌های query، مدل‌های alerting، ابزارهای dashboard و workflowهای تحلیل همه مختص به backend هستند. تغییر از Datadog به Grafana هنوز نیاز به بازنویسی dashboardها و alertها دارد — لایه جمع‌آوری داده اکنون قابل حمل است، اما لایه تحلیل اینطور نیست. این همان مشکل «observability portability» است که صنعت هنوز روی آن کار می‌کند.

جایی که تیم‌ها گیر می‌کنند

رایج‌ترین حالت شکست این است که OpenTelemetry را به عنوان یک checkbox در نظر بگیرند تا یک practice. تیم‌ها سرویس‌های خود را instrument می‌کنند، می‌بینند که traces در backend observability ظاهر می‌شود و پیروزی را اعلام می‌کنند. شش ماه بعد، وقتی یک incident production رخ می‌دهد، متوجه می‌شوند که traces ناقص است (بعضی سرویس‌ها instrument نشده‌اند)، spans فاقد attributeهای مفید هستند (بدون user ID، feature flag، context کسب‌وکار) و cardinality metrics از محدودیت backend گذشته.

Auto-instrumentation — جایی که SDK به صورت خودکار spanهایی برای HTTP calls، database queries و عملیات message queue تولید می‌کند — اسکلت ساختاری یک درخواست را می‌گیرد اما هیچ چیزی از logic کسب‌وکار نمی‌گیرد. اینکه یک API call برای مشتری premium بوده یا free-tier، کدام feature flag فعال بوده، total cart چقدر بوده: اینها attributeهایی هستند که نیاز به manual instrumentation دارند. تیم‌هایی که بیشترین ارزش را از OpenTelemetry می‌برند آنهایی هستند که span attributes را محصول طراحی آگاهانه می‌دانند نه تولید خودکار.

Cardinality دومین شکاف است. هر ترکیب منحصربه‌فرد از attribute values یک time series جدید در backend metrics ایجاد می‌کند. یک metric که با user ID، region، feature flag و HTTP status code برچسب‌گذاری شده می‌تواند میلیون‌ها series مجزا ایجاد کند — و بسیاری از backendهای observability بر اساس time series هزینه می‌کنند یا محدودیت سخت دارند. تیم‌هایی که metrics را بدون فکر کردن به cardinality instrument می‌کنند، یا صورت‌حساب‌های غیرمنتظره بزرگی دریافت می‌کنند یا درست در زمانی که به داده نیاز دارند به محدودیت loss داده برخورد می‌کنند.

Collector به عنوان یک دارایی استراتژیک

OpenTelemetry Collector به جرات کم‌استفاده‌ترین کامپوننت در اکوسیستم است. بیشتر تیم‌ها آن را به عنوان یک forwarder ساده مستقر می‌کنند — دریافت OTLP از سرویس‌ها، صادرات به backend. Pipeline processor Collector می‌تواند کارهای بیشتری انجام دهد: فیلتر کردن داده‌های high-cardinality قبل از رسیدن به backend، sampling traces بر اساس قوانین کسب‌وکار (sample ۱۰۰٪ خطاها، ۱٪ موفق)، غنی‌سازی spans با metadata از Kubernetes یا service discovery، و هدایت سیگنال‌های مختلف به backendهای متفاوت.

یک pipeline Collector خوب پیکربندی شده می‌تواند هزینه‌های observability را ۶۰-۸۰٪ کاهش دهد بدون از دست دادن signal معنادار، با حذف تهاجمی داده‌های کم‌ارزش (traces health check، jobهای background روتین) و نگه‌داشتن همه چیز مرتبط با debugging و تحلیل کسب‌وکار. تیم‌هایی که با Collector به عنوان زیرساختی رفتار می‌کنند که نیاز به پیکربندی آگاهانه دارد نه deploy و فراموشی، ارزش بسیار بیشتری از همان بودجه استخراج می‌کنند.

Semantic Conventions: استاندارد دست‌کم گرفته شده

Semantic conventions OpenTelemetry — یک specification برای نام‌گذاری و ساختاربندی attributes روی spans و metrics — کم‌ارزش‌ترین contribution پروژه است. وقتی هر تیم attributes span دیتابیس خود را متفاوت نام‌گذاری کند، نمی‌توانید dashboardها یا alertهای generic بنویسید که بین سرویس‌ها کار کند. وقتی همه از یک convention پیروی کنند (db.system، db.statement، http.method، http.status_code)، ابزارها می‌توانند درباره telemetry بدون پیکربندی خاص سرویس استدلال کنند.

پذیرش semantic conventions در عمل هنوز کامل نیست. conventions پایدار HTTP، دیتابیس‌ها، سیستم‌های messaging و RPC را پوشش می‌دهند — رایج‌ترین الگوهای زیرساخت. بسیاری از الگوهای خاص برنامه یا پوشش داده نشده‌اند یا در وضعیت experimental هستند. تیم‌هایی که روی OpenTelemetry می‌سازند باید زمان بگذارند تا conventions attribute خود را برای context لایه برنامه تعریف کنند، با پیروی از الگوهای نام‌گذاری که پروژه تعیین می‌کند، تا مزایای composability یکسان در لایه برنامه به دست آورند.

در سال ۲۰۲۶ یک setup خوب چه شکلی است

تیم‌هایی که در سال ۲۰۲۶ بیشترین ارزش را از OpenTelemetry می‌برند چند ویژگی مشترک دارند. آنها یک platform team یا قهرمان observability دارند که مالک پیکربندی Collector و استانداردهای instrumentation است. آنها مجموعه‌ای از span attributes اجباری برای سرویس‌های جدید تعریف کرده و در code review اعمال می‌کنند. آنها تحلیل cardinality صریح روی metrics خود انجام داده و انتخاب‌های آگاهانه درباره اینکه کدام dimensions را نگه دارند انجام داده‌اند. آنها از tail-based sampling برای capture کامل traces خطاها و درخواست‌های کند استفاده می‌کنند در حالی که ترافیک روتین را تهاجمی sample می‌کنند.

آنها همچنین داده‌های observability را به عنوان یک محصول می‌بینند، نه infra exhaust. سوال این نیست «آیا داده جمع‌آوری می‌کنیم؟» بلکه «آیا مهندس on-call می‌تواند ریشه یک incident production را در کمتر از ۱۰ دقیقه پیدا کند؟» این استاندارد تصمیم‌های instrumentation متفاوتی را نسبت به «آیا Collector running است؟» هدایت می‌کند.

OpenTelemetry سخت‌ترین مشکل هماهنگی در observability را حل کرد: رساندن صنعت به توافق روی یک فرمت داده مشترک. لایه بعدی مشکلات — چه چیزی را instrument کنیم، چگونه pipeline را پیکربندی کنیم، روی آن چه بسازیم — چالش‌های مهندسی و سازمانی هستند که هر تیم باید خودشان برای خودشان حل کنند. خبر خوب این است که فونداسیون اکنون به اندازه کافی پایدار است که بتوان روی آن ساخت.