ساعت 3 بامداد است. پیامی اضطراری صفحه نمایش را روشن می کند: سیستم از دسترس خارج شده. ترمینال را باز می کنید. نمودارها سبزند. مصرف پردازنده و رم در محدوده نرمال قرار دارند. لاگ ها هیچ استثنا ثبت نکرده اند اما کاربران قادر به ثبت سفارش نیستند. این تصویر تکراری دقیقاً همان شکافی است که بحث مشاهده پذیری را از مانیتورینگ متمایز ساخته است. طبق آمار گارتنر میانگین هزینه هر دقیقه قطع زیرساخت های فناوری اطلاعات 5600 دلار است. برای پلتفرم های فروشگاهی در شب های شلوغ این عدد به ساعتی 300 هزار دلار می رسد. در چنین محیطی گذر از دانستن اینکه سیستم خراب است به فهم چرا خراب است صرفاً یک بحث فنی نیست. مرز بین خفگی تیم فنی و بازیابی سریع سرویس است.
مانیتورینگ و نقطه کور ساختاری
مانیتورینگ به قدمت خود رایانش وجود دارد. هسته اصلی آن جمع آوری شاخص های از پیش تعیین شده مانند مصرف پردازنده حافظه نرخ خطا و تأخیر پاسخ و ارسال هشدار هنگام عبور از آستانه های مشخص است. این روش برای خطاهای شناخته شده عالی عمل می کند. پر شدن دیسک یا اتمام کانکشن پاور دیتابیس سناریوهایی هستند که داشبوردها به راحتی آن ها را آشکار می سازند. اما مانیتورینگ نقطه کور جدی دارد. شما فقط آنچه را اندازه گیری کرده اید می بینید. یک نشت حافظه آرام یا اختلالی که فقط روی 2 درصد از ترافیک کاربران تأثیر گذاشته در میان ارقام کلی گم می شود. هشوار مصرف پردازنده بالای 80 درصد مشکل را نشان می دهد اما ریشه آن را خاموش نگه می دارد. همین رویکرد سبب می شود تیم ها روزانه با ده ها نوتیفیکیشن کاذب بمباران شوند و به اصطلاح خستگی هشدارها دچار گردند.
مشاهده پذیری عبور از هشدارهای سطحی
مشاهده پذیری (Observability) پارادایم را تغییر می دهد. شرکت Honeycomb که پیشتاز این حوزه است تعریف مشخصی ارائه می دهد: سیستمی مشاهده پذیر است که بتوانید با تحلیل خروجی های آن به سوالات غیرمنتظره درباره حالت داخلی سیستم پاسخ دهید بدون اینکه از پیش بدانید چه چیزی باید چک شود. مانیتورینگ به سوالات آماده پاسخ می دهد. مشاهده پذیری اجازه می دهد سوال را در لحظه بحران طرح کنید. اگر API پرداخت کند پاسخ می دهد مشاهده پذیری به شما نشان می دهد که سرویس واسط دقیقاً 5 ثانیه منتظر پاسخ از درگاه بانکی است. این جهش از علائم به علت ریشه ای است و بر سه پایه فنی استوار شده که معماری های سنتی فاقد آن ها بودند:
داده های با کاردینالیتی بالا
به جای فشرده سازی درخواست ها در یک شاخص واحد سیستم های مدرن هر ردیابی را به همراه متای کاربر قطعه دیتابیس یا پرچم های ویژگی ذخیره می کنند. این جزئیات به مهندسان اجازه می دهد با یک کوئری ساده بپرسند چرا ترافیک اروپا کندتر است یا مشترکات درخواست های خطا دار چیست.
ردیابی توزیع شده
در معماری های میکروسرویس یک درخواست کاربر ممکن است از دوازده سرویس عبور کند. ابزارهای متن باز مانند OpenTelemetry مسیر کامل این درخواست را با تایم استامپ دقیق و وابستگی ها ترسیم می کنند تا گلوگاه های پنهان آشکار شوند.
بافتار غنی عملیاتی
مشاهده پذیری فقط داده خام نمی خواهد. آن را در بافت عملکرد واقعی سیستم قرار می دهد تا تحلیلگر بتواند بدون حدس و گمان سناریوی خرابی را شبیه سازی و حل کند.
آینده دیباگینگ سیستم های عملیاتی
آینده توسعه سیستم های مقیاس پذیر دیگر به سوپروایزرهای کلاسیک وابسته نیست. حرکت به سمت استانداردهای باز و معماری های مبتنی بر رویداد زیرساخت ها را از حالت واکنشی به حالت پیش بینیانه و قابل کاوش تبدیل کرده است. تیم های فنی که امروز مشاهده پذیری را در لایه اول طراحی گنجانده اند فردا با سرعت نسبی پیچیدگی های تولید را به مزیت رقابتی تبدیل می کنند.
