چرا مدل «رویدادهای عریض» برتر از معماری سنتی سنجه‌ها، لاگ‌ها و تریس‌هاست؟

مقدمه و زمینه

در دنیای توسعه نرم‌افزار امروزی، مفهوم Observability یا قابلیت مشاهده‌پذیری با سردرگمی‌های زیادی روبه‌روست. مهندسان مدام درگیر این سؤال هستند که تفاوت واقعی بین تریس (Trace)، اسپن (Span)، لاگ (Log) و سنجه (Metric) چیست. چارچوب‌هایی مثل OpenTelemetry ابزارهای قدرتمندی هستند، اما اصرار آن‌ها بر دسته‌بندی داده‌ها به سه دسته مجزا باعث پیچیدگی بیش از حد و ایجاد واژه‌نامه‌هایی با بیش از ۶۰ اصطلاح تخصصی شده است. این در حالی است که در مقیاس سیستم‌های توزیع‌یافته بزرگ، آنچه بیش از هر چیز اهمیت دارد، امکان کاوش آزادانه در داده‌ها، ترکیب فیلترها و یافتن ناشناخته‌هاست.

سیستم Scuba در Meta: بهشت مانیتورینگ

نویسنده بر اساس تجربه کاری خود در Meta، سیستم داخلی این شرکت به نام Scuba را به عنوان الگویی بی‌نقص معرفی می‌کند. ایده اصلی Scuba بسیار ساده است و بر پایه Wide Events یا رویدادهای عریض بنا شده است:

• ساختار داده ساده: یک رویداد عریض، مجموعه‌ای از جفت‌های کلید و مقدار شبیه به یک سند JSON است که تمام اطلاعات مرتبط با یک رویداد (مانند ثبت یک نمایش آگهی) در آن جای می‌گیرد.
• ثبت تمام جزئیات: تشویق توسعه‌دهندگان به اینکه هر داده‌ی به ظاهر مرتبطی را درون رویداد بریزند، ابزار قدرتمندی برای کشف «ناشناخته‌های ناشناخته» (Unknown Unknowns) در هنگام بروز بحران فراهم می‌کند.
• قابلیت Slice and Dice: رابط کاربری Scuba به مهندسان اجازه می‌دهد بدون نیاز به داشتن دانش کامل از کل سیستم، داده‌ها را گروه بندی (Group by) یا فیلتر کنند تا ریشه مشکل پیدا شود.

برای مثال، اگر شاخص نمایش آگهی‌ها در یک سیستم به شکل عجیبی افت کند، مهندس می‌تواند داده‌ها را ابتدا بر اساس نوع کمپین، سپس سیستم‌عامل کاربر و در نهایت نسخه سیستم‌عامل فیلتر کند تا دقیقاً نسخه مشکل‌دار اپلیکیشن شناسایی شود. نکته جالب اینجاست که مسائل مربوط به کاردینالیتی (Cardinality) در این سیستم مطرح نیست، زیرا داده‌ها پیش‌آگریگیت نمی‌شوند.

نگاهی به OpenTelemetry از زاویه‌ای دیگر

پس از کار با سیستمی مانند Scuba، مواجهه با ابزارهای منبع‌باز خارج از Meta ممکن است ناامیدکننده باشد. در OpenTelemetry مفهوم Span بسیار نزدیک به Wide Event است، اما ساختار سنتی حفظ شده است. در واقع، می‌توان سه مفهوم سنتی را حالت‌های خاصی از رویدادهای عریض دانست:

• تریس‌ها و اسپن‌ها: در واقع همان رویدادهای عریض هستند که فیلترهای SpanId، TraceId و ParentSpanId را دارند و به کمک روابط والد و فرزندی مرتب می‌شوند.
• لاگ‌ها: لاگ‌های ساختاریافته کاملاً به رویدادهای عریض شبیه‌سازی می‌شوند و با استخراج الگوهای خطا می‌توان به سرعت آن‌ها را تحلیل کرد.
• سنجه‌ها: سنجه‌ها نیز می‌توانند به عنوان رویدادهای عریضی که در بازه‌های زمانی مشخص وضعیت سیستم را گزارش می‌دهند، بازتعریف شوند.

دیدگاه جامعه مهندسی در Hacker News

بحث‌های شکل‌رفته حول این مقاله در هکرنیوز حاوی نکات انتقادی و تجربی مهمی است. از جمله اینکه کاربران درباره هزینه‌های نگهداری و ذخیره‌سازی داده‌ها در این روش پرسش‌هایی مطرح کرده‌اند. نگهداری رویدادهای عریض خام به جای پیش‌آگریگیت کردن داده‌ها چالش‌برانگیز است و تکنیک‌هایی مانند Dynamic Sampling (نمونه‌برداری پویا) نقش کلیدی در کنترل هزینه‌ها ایفا می‌کنند؛ موضوعی که نشان می‌دهد تیم‌ها همچنان باید بین هزینه‌های ذخیره‌سازی و سرعت عیب‌یابی تعادل برقرار کنند.

چرا این موضوع برای مهندسان اهمیت دارد؟

برای توسعه‌دهندگان و مهندسان زیرساخت، این مقاله یادآوری می‌کند که نباید خود را محدود به دسته‌بندی‌های خشک لاگ، سنجه و تریس کنند. حرکت به سمت Wide Events و ابزارهایی که امکان کاوش انعطاف‌پذیر داده‌ها را می‌دهند، سرعت عیب‌یابی (Debugging) را به شدت افزایش می‌دهد و به تیم‌ها کمک می‌کند در مواجهه با قطعی‌های پیچیده، به جای حدس و گمان، با داده‌های واقعی تصمیم بگیرند.