مانیتورینگ خطا چیست و چرا هر سایتی به آن نیاز دارد

مانیتورینگ سرور شما سبز است. Uptime نود و نه و نه دهم درصد. لاگ‌ها تمیزند. و در همین حال، ۸ درصد کاربران شما نمی‌توانند سفارششان را ثبت کنند، چون یک خطای جاوااسکریپت در مرورگر آن‌ها دکمهٔ نهایی را از کار انداخته است.

این فاصله — بین «سرور بالاست» و «سایت برای کاربران کار می‌کند» — چیزی است که مانیتورینگ خطا پر می‌کند.

مانیتورینگ خطا دقیقاً چه کاری می‌کند؟

یک سیستم رصد خطا کد کوچکی است که در مرورگر کاربر اجرا می‌شود و هر وقت خطایی رخ دهد، آن را به همراه زمینه‌اش به سرور شما می‌فرستد. به‌جای اینکه منتظر بمانید کاربری زحمت گزارش دادن را به خودش بدهد، خطاها خودشان می‌آیند.

سیستم خوب سه کار انجام می‌دهد:

• ثبت می‌کند — خطای جاوااسکریپت، درخواست شبکهٔ ناموفق، و promise رد شده را خودکار می‌گیرد.
• گروه‌بندی می‌کند — هزاران رخداد یکسان را زیر یک «مشکل» جمع می‌کند تا با سیل تکراری روبه‌رو نشوید.
• زمینه می‌دهد — می‌گوید کدام کاربر، در کدام صفحه، با چه مرورگری، و پیش از خطا چه کارهایی کرد.

بدون بخش سوم، شما فقط فهرستی از پیام‌های خطا دارید. با آن، مشکل قابل بازتولید و در نتیجه قابل حل می‌شود.

تفاوتش با لاگینگ و APM

سه ابزار که مدام با هم اشتباه گرفته می‌شوند و هر کدام سؤال متفاوتی را جواب می‌دهند:

لاگینگ جواب می‌دهد «چه اتفاقی افتاد؟» — جریانی از رویدادها که خودتان تعریف کرده‌اید. عالی برای تحقیق عمیق، ولی باید بدانید دنبال چه می‌گردید و معمولاً فقط سمت سرور را می‌بیند.

APM جواب می‌دهد «چقدر کند است؟» — زمان پاسخ، گلوگاه‌های پایگاه داده، مصرف منابع. مسئله‌اش عملکرد است نه درستی.

رصد خطا جواب می‌دهد «چه چیزی برای کاربران خراب است؟» — و مهم‌تر، خودش به شما خبر می‌دهد؛ لازم نیست بدانید دنبال چه بگردید.

این سه مکمل هم‌اند، نه جایگزین. ولی اگر تیم کوچکی هستید و باید یکی را اول راه بیندازید، رصد خطا بیشترین ارزش را به‌ازای کمترین تلاش می‌دهد: نصبش چند دقیقه است و از همان روز اول چیزهایی نشانتان می‌دهد که نمی‌دانستید.

یک سیستم رصد خطای خوب چه چیزهایی دارد؟

گروه‌بندی با اثر انگشت

یک خطا در صفحهٔ پربازدید می‌تواند روزی هزاران بار تکرار شود. سیستم باید بر اساس نوع خطا، پیام و محل وقوع، یک «اثر انگشت» بسازد و همهٔ رخدادهای مشابه را زیر یک مشکل جمع کند. بدون این، داشبورد شما ظرف یک روز غیرقابل استفاده می‌شود.

Breadcrumb

فهرستی از کارهایی که کاربر پیش از خطا انجام داد: کلیک‌ها، جابه‌جایی بین صفحات، درخواست‌های شبکه. این تفاوت بین «یک خطا داریم» و «می‌دانم چطور بازتولیدش کنم» است.

پشتیبانی از Source Map

کد production فشرده است و stack trace بدون source map چیزی مثل a.js:1:24817 نشان می‌دهد. سیستم باید بتواند آن را به فایل و خط اصلی نگاشت کند.

تشخیص رگرسیون

وقتی مشکلی را حل‌شده علامت زدید و دوباره برگشت، سیستم باید بفهمد و خبر دهد. برگشت یک باگ حل‌شده معمولاً فوری‌تر از یک باگ جدید است.

محدودسازی نویز

افزونه‌های مرورگر، ربات‌ها و اسکریپت‌های شخص ثالث خطاهایی تولید می‌کنند که ربطی به کد شما ندارند. سیستمی که این‌ها را فیلتر نکند، به‌سرعت باعث می‌شود تیم اعلان‌ها را نادیده بگیرد — پدیده‌ای که به آن خستگی از هشدار می‌گویند.

حریم خصوصی

خطاها ممکن است حاوی داده‌های شخصی کاربران باشند. سیستم باید فیلدهای حساس را ماسک کند و امکان پاک‌سازی داده‌های شخصی را بدهد. این در ایران هم موضوع اعتماد مشتری است، حتی جایی که الزام قانونی مشخصی نباشد.

آنچه رصد خودکار نمی‌بیند

مهم است انتظارتان واقع‌بینانه باشد. رصد خودکار خطا دستهٔ کاملی از مشکلات را نمی‌بیند:

• دکمه‌ای که کار می‌کند ولی کاربر پیدایش نمی‌کند.
• متنی که فنی درست است ولی گیج‌کننده.
• فرمی که کار می‌کند ولی آن‌قدر طولانی است که کاربر رهایش می‌کند.
• محاسبه‌ای که خطا نمی‌دهد ولی عدد غلط نشان می‌دهد.

این‌ها از نظر سیستم، رفتار عادی‌اند. تنها راه دیدنشان این است که خود کاربر بگوید — به همین دلیل رصد خطا و دریافت بازخورد کاربر دو نیمهٔ یک تصویرند، نه دو ابزار رقیب.

چطور شروع کنیم

راه‌اندازی رصد خطا برخلاف تصور رایج پروژهٔ بزرگی نیست:

• اسکریپت را اضافه کنید — یک تگ در صفحات سایت. نیازی به تغییر فریم‌ورک یا معماری نیست.
• یک هفته فقط تماشا کنید. اولین هفته معمولاً شوک‌آور است؛ خطاهایی می‌بینید که ماه‌ها وجود داشته‌اند. عجله نکنید و همه را یک‌جا حل نکنید.
• بر اساس تعداد کاربران متأثر اولویت بدهید، نه تعداد رخداد. خطایی که ۵۰۰ بار برای یک کاربر رخ داده، از خطایی که ۵۰ بار برای ۵۰ کاربر مختلف رخ داده کم‌اهمیت‌تر است.
• نویز را ببندید. خطاهای افزونه‌ها و اسکریپت‌های شخص ثالث را فیلتر کنید تا اعلان‌ها معنادار بمانند.
• حلقه را ببندید. وقتی مشکلی را حل کردید، علامت بزنید تا اگر برگشت خبردار شوید.

هفتهٔ اول: انتظار شوک را داشته باشید

تقریباً هر تیمی که برای اولین بار رصد خطا راه می‌اندازد، تجربهٔ مشابهی دارد: تعداد خطاها بسیار بیشتر از چیزی است که انتظار داشتند. این طبیعی است و به این معنی نیست که محصولتان بد است؛ به این معنی است که تا دیروز نمی‌دیدیدشان.

واکنش اشتباه، تلاش برای صفر کردن فهرست در هفتهٔ اول است. واکنش درست این است:

• روز اول تا سوم فقط تماشا کنید. بگذارید داده جمع شود تا الگوها معلوم شوند.
• نویز را ببندید. خطاهای افزونه‌ها، ربات‌ها و اسکریپت‌های شخص ثالث را فیلتر کنید. معمولاً این کار به‌تنهایی فهرست را نصف می‌کند.
• پنج مورد اول را بر اساس کاربران متأثر انتخاب کنید و فقط همان‌ها را حل کنید.
• بقیه را بگذارید بمانند. خطایی که ماه‌هاست وجود دارد و کسی شکایتی نکرده، یک هفتهٔ دیگر هم صبر می‌کند.

دادهٔ کاربران و مسئولیتی که می‌آید

سیستم رصد خطا ذاتاً داده جمع می‌کند، و بخشی از آن می‌تواند شخصی باشد: آدرس صفحه‌ای که شناسهٔ کاربر در آن است، محتوای فرمی که در لحظهٔ خطا پر شده بود، یا اسکرین‌شاتی که اطلاعات حساب را نشان می‌دهد.

حداقل‌هایی که باید رعایت شوند:

• فیلدهای رمز عبور همیشه و به‌صورت خودکار از اسکرین‌شات و از دادهٔ ارسالی حذف شوند.
• امکان علامت‌گذاری فیلدهای حساس دیگر وجود داشته باشد — شمارهٔ کارت، کد ملی، شمارهٔ تماس.
• الگوهای شناخته‌شده سمت سرور پاک‌سازی شوند، به‌عنوان لایهٔ دوم دفاع.
• دادهٔ قدیمی خودکار حذف شود. نگه‌داشتن خطاهای دو سال پیش هیچ ارزشی ندارد و فقط ریسک است.

و در سیاست حریم خصوصی سایتتان به این موضوع اشاره کنید. این هم درست است و هم — وقتی کاربر بداند چه چیزی جمع می‌شود — باعث می‌شود راحت‌تر گزارش بدهد.

یک سناریوی واقعی

فرض کنید فروشگاهی دارید و نرخ تبدیل صفحهٔ پرداخت از هفتهٔ گذشته ۱۲ درصد افت کرده است. بدون رصد خطا، مسیر تحقیق شما چیزی شبیه این است: نمودار گوگل آنالیتیکس را نگاه می‌کنید، از تیم بازاریابی می‌پرسید کمپینی عوض شده یا نه، سرور را چک می‌کنید که سالم است، و در نهایت خودتان یک خرید آزمایشی می‌کنید که بدون مشکل انجام می‌شود. نتیجه: «احتمالاً فصلی است.»

با رصد خطا، همان تحقیق این شکل را دارد: در فهرست مشکلات، خطایی می‌بینید که سه‌شنبهٔ گذشته شروع شده، ۴۱۰ کاربر را تحت تأثیر گذاشته و همه‌شان در سافاری روی آی‌اواس بوده‌اند. breadcrumb نشان می‌دهد همه‌شان دقیقاً بعد از انتخاب «پرداخت با کارت» به خطا خورده‌اند. انتشار سه‌شنبه هم دقیقاً همان بخش را تغییر داده بود.

تفاوت این دو مسیر، تفاوت بین چند روز حدس زدن و بیست دقیقه کار است. و مهم‌تر: در مسیر اول هرگز مطمئن نمی‌شوید که واقعاً مشکل را پیدا کرده‌اید.

معیارهایی که واقعاً مهم‌اند

وقتی سیستم رصد راه افتاد، چند عدد به شما می‌گویند اوضاع بهتر می‌شود یا بدتر:

• زمان تا کشف. از لحظه‌ای که باگ وارد production شد تا لحظه‌ای که کسی فهمید چقدر طول کشید؟ این عدد بیش از هر چیز دیگری نشان می‌دهد سیستم رصد شما کار می‌کند یا نه.
• زمان تا رفع (MTTR). از کشف تا انتشار اصلاح. اگر این عدد بالاست، معمولاً مشکل کمبود اطلاعات است نه کمبود توان فنی.
• نسبت کاربران متأثر. عدد مطلق خطاها گمراه‌کننده است؛ درصد کاربرانی که دست‌کم یک خطا دیده‌اند، معیار بهتری از سلامت محصول است.
• نرخ بازگشت باگ. چند درصد از چیزهایی که «حل‌شده» علامت زدید، برگشتند؟ عدد بالا یعنی دارید علامت‌ها را درمان می‌کنید نه علت‌ها.

هشدارها را چطور تنظیم کنیم

بزرگ‌ترین دلیل شکست پروژه‌های رصد خطا، فنی نیست — رفتاری است. تیم برای همه‌چیز اعلان می‌گذارد، ظرف دو هفته کانال اعلان‌ها پر از نویز می‌شود، همه بی‌صداش می‌کنند، و سیستم عملاً می‌میرد.

قاعده‌ای که جواب می‌دهد: اعلان فقط برای چیزی که باید همین حالا کاری برایش بکنید. بقیه در داشبورد می‌مانند تا وقتی خودتان سراغشان بروید. در عمل یعنی:

• مشکل جدیدی که قبلاً هرگز دیده نشده — بله، اعلان.
• مشکلی که «حل‌شده» بود و برگشته — بله، اعلان.
• جهش ناگهانی در نرخ یک خطا — بله، اعلان.
• تکرار هزارم یک خطای شناخته‌شده — نه. این را در داشبورد ببینید.

خودتان بسازید یا سرویس بگیرید؟

ساختن نسخهٔ ساده‌ای از این سیستم کار سختی نیست: یک شنوندهٔ خطا، یک endpoint و یک جدول. تیم‌های زیادی این را در یک بعدازظهر می‌سازند. مشکل جای دیگری است — بخش‌هایی که کار می‌برند و در ابتدا دیده نمی‌شوند:

• گروه‌بندی هوشمند، وگرنه ظرف یک هفته جدولتان میلیون‌ها ردیف تکراری دارد.
• نگاشت source map برای کد فشرده.
• محدودسازی نرخ، وگرنه یک خطای پرتکرار سرور خودتان را از پا درمی‌آورد.
• پاک‌سازی داده‌های شخصی.
• سیاست نگه‌داری و حذف داده‌های قدیمی.

برای تیمی که محصولش رصد خطا نیست، این‌ها معمولاً وقتی است که بهتر بود صرف محصول خودشان می‌شد. در ایران یک ملاحظهٔ اضافه هم هست: سرویس‌های خارجی معمولاً نیاز به تحریم‌شکن دارند، پرداختشان دردسر دارد و دادهٔ کاربران شما از کشور خارج می‌شود. اگر سراغ سرویس آماده می‌روید، Sentry شناخته‌شده‌ترین گزینه است؛ مقایسهٔ ابزارهای رصد خطا برای تیم‌های ایرانی و جایگزین‌های ایرانی Sentry گزینه‌های در دسترس را کنار هم گذاشته‌اند.

BugMug را تیم شرکت نرم‌افزاری ژابیز پردا ساخته است؛ تیمی که از سال ۱۳۸۰ سامانه‌های اطلاعاتی و مدیریتی برای سازمان‌ها و شرکت‌های بزرگ طراحی می‌کند و نیاز به دیدن خطاهای سمت کاربر را در همین پروژه‌ها از نزدیک تجربه کرده است.

هزینهٔ نداشتنش

تیم‌ها معمولاً رصد خطا را به تعویق می‌اندازند چون هزینه‌اش قابل مشاهده است و هزینهٔ نداشتنش نه. ولی هزینهٔ دوم واقعی است و معمولاً بزرگ‌تر:

کاربری که به باگ می‌خورد و برمی‌گردد، هزینهٔ جذبش را پرداخته‌اید و درآمدش را نگرفته‌اید. باگی که ماه‌ها زنده می‌ماند، چند برابر باگی که همان روز دیده شده هزینهٔ رفع دارد، چون کسی دیگر آن کد را به یاد ندارد. و پشتیبانی‌ای که مجبور است با کاربر بحث کند «دقیقاً چه دیدید؟»، وقتی را می‌سوزاند که یک اسکرین‌شات خودکار می‌توانست ذخیره‌اش کند.

سؤال درست این نیست که «آیا به رصد خطا نیاز داریم؟» بلکه این است که «الان چند باگ داریم که نمی‌بینیم؟» — و تنها راه فهمیدنش، نصب کردن و نگاه کردن است. حساب این هزینه را با عدد در هزینهٔ پنهان نداشتن سیستم رصد خطا نشان داده‌ایم.

منابع و مطالعهٔ بیشتر

• Monitoring Distributed Systems — کتاب SRE گوگل — اصول پایش و هشداردهی از تجربهٔ گوگل
• رویداد error در MDN — سازوکار مرورگر برای گرفتن خطاهای مدیریت‌نشده
• رویداد unhandledrejection در MDN — گرفتن Promiseهای ردشده در سطح سراسری