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

تفاوت Event و Issue

هر بار که خطایی در اپلیکیشن رخ می‌دهد، ممکن است یک رخداد (Event) برای سنتری ارسال شود. اگر هزار کاربر با یک خطای مشابه روبه‌رو شوند، سنتری می‌تواند هزار Event را در قالب یک Issue گروه‌بندی کند.

Issue نمایی تجمیع‌شده از مشکل است و اطلاعاتی مانند تعداد رخدادها، زمان اولین و آخرین رخداد، کاربران تحت‌تأثیر و نمونه‌هایی از Eventهای مرتبط را نمایش می‌دهد. تیم توسعه معمولاً Issue را بررسی و علت اصلی آن را رفع می‌کند، نه اینکه هر Event را جداگانه مدیریت کند.

بخش‌های اصلی یک Issue

هنگام بازکردن یک Issue، بهتر است اطلاعات را با این ترتیب بررسی کنید:

1. عنوان و عامل احتمالی: نوع و پیام خطا و بخشی از فایل یا تابعی که سنتری آن را به‌عنوان محل احتمالی مشکل نشان می‌دهد.

2. پشته فراخوانی: پشته فراخوانی (Stack Trace) مسیر اجرای توابع تا نقطه بروز خطا را نمایش می‌دهد و یکی از مهم‌ترین بخش‌ها برای پیداکردن منشأ مشکل است.

3. تعداد و زمان رخدادها: تعداد Eventها و زمان اولین و آخرین رخداد نشان می‌دهند مشکل چند بار و در چه بازه‌ای اتفاق افتاده است.

4. روند رخدادها: نمودار رخدادها مشخص می‌کند خطا با نرخ ثابتی تکرار شده یا در زمان مشخصی افزایش یافته است. افزایش ناگهانی می‌تواند با انتشار نسخه جدید یا تغییر دیگری در اپلیکیشن مرتبط باشد.

5. کاربران تحت‌تأثیر: اگر اطلاعات کاربر همراه Event ارسال شده باشد، می‌توانید تعداد کاربران درگیر و پراکندگی خطا میان آن‌ها را بررسی کنید.

6. نسخه و محیط اجرا: نسخه منتشرشده (Release) و محیط اجرا (Environment) کمک می‌کنند مشخص شود خطا در کدام نسخه و محیط، مانند production یا staging، رخ داده است.

7. ردپاهای رخداد: ردپاها (Breadcrumbs) رویدادهایی مانند جابه‌جایی میان صفحه‌ها، درخواست‌های HTTP، پیام‌های کنسول یا عملیات‌های پیش از خطا را نشان می‌دهند.

برای ارزیابی اولیه، عنوان، Stack Trace، تعداد رخدادها و روند تغییرات را بررسی کنید. سپس برای درک شرایط وقوع خطا سراغ Breadcrumbs، Release و اطلاعات زمینه‌ای بروید.

خواندن Stack Trace

Stack Trace زنجیره توابعی را نشان می‌دهد که پیش از وقوع خطا اجرا شده‌اند. فریم‌های این زنجیره معمولاً به چند گروه تقسیم می‌شوند:

• فریم‌های کد برنامه (In-app Frames): بخش‌هایی از کد که تیم شما نوشته است. معمولاً بهتر است بررسی را از این فریم‌ها شروع کنید.
• فریم‌های کتابخانه و فریم‌ورک: اطلاعات مربوط به کتابخانه‌ها و فریم‌ورک‌های استفاده‌شده در برنامه. این فریم‌ها ممکن است فقط مسیر رسیدن خطا به کد شما را نشان دهند.
• فریم‌های سیستمی یا کامپایل‌شده: اطلاعات سطح پایین‌تر که برای خواندن صحیح آن‌ها ممکن است به Debug Symbol نیاز باشد.

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

در اپلیکیشن‌های JavaScript، اگر کد فشرده یا Minify شده باشد، برای نمایش صحیح فایل و شماره خط باید Source Mapها را هنگام Build تولید و برای سنتری بارگذاری کنید.

بررسی Breadcrumbs

Breadcrumbs یک خط زمانی از رویدادهای پیش از خطا هستند. بسته به SDK، Integrationها و تنظیمات اپلیکیشن، ممکن است مواردی مانند این‌ها در آن‌ها ثبت شوند:

• بازشدن یا تغییر صفحه؛
• درخواست‌های HTTP؛
• کلیک‌ها و تعامل‌های کاربر؛
• پیام‌های کنسول؛
• خطاهای قبلی همان نشست.

برای مثال، Breadcrumbs ممکن است نشان دهند کاربر وارد صفحه پرداخت شده، درخواست /api/charge پاسخ ناموفق گرفته و سپس Frontend با خطا مواجه شده است. این ترتیب می‌تواند برای بازتولید خطا یا پیداکردن سرویس مرتبط مفید باشد.

Breadcrumbs برای همه Eventها یکسان نیستند و محتوای آن‌ها به تنظیمات SDK و اطلاعاتی بستگی دارد که اپلیکیشن جمع‌آوری می‌کند.

Tags، Context و اطلاعات کاربر

هر Event می‌تواند اطلاعات ساختاریافته دیگری نیز داشته باشد:

• برچسب‌ها (Tags): مقادیر قابل‌جست‌وجو مانند environment، release، مرورگر، سیستم‌عامل و برچسب‌های سفارشی؛
• اطلاعات زمینه‌ای (Context): اطلاعات مرتبط با درخواست، دستگاه، Runtime یا بخش‌های دیگر اپلیکیشن؛
• اطلاعات کاربر: شناسه یا سایر اطلاعاتی که اپلیکیشن از طریق SDK ارسال کرده است.

بهتر است برای شناسایی کاربر از یک شناسه داخلی و پایدار استفاده کنید و از ارسال اطلاعات حساس یا غیرضروری خودداری کنید. اگر اطلاعات کاربر در SDK تنظیم نشده باشد، سنتری نمی‌تواند تعداد دقیق کاربران تحت‌تأثیر را نمایش دهد.

گروه‌بندی Eventها

سنتری با استفاده از اطلاعاتی مانند نوع خطا، پیام، Stack Trace و اثر انگشت (Fingerprint)، Eventهای مشابه را در یک Issue قرار می‌دهد.

گاهی ممکن است دو خطای متفاوت در یک Issue گروه‌بندی شوند یا یک خطای واحد در چند Issue جدا نمایش داده شود. اگر Eventهای داخل یک Issue مسیرها یا علت‌های متفاوتی دارند، باید احتمال گروه‌بندی نادرست را بررسی کنید.

در چنین شرایطی می‌توانید با تعریف Fingerprint سفارشی، خطاها را از هم جدا یا Eventهای مرتبط را در یک Issue گروه‌بندی کنید.

اولویت‌بندی Issueها

تعداد Eventها به‌تنهایی برای تعیین اهمیت یک Issue کافی نیست. هنگام اولویت‌بندی، این موارد را کنار هم بررسی کنید:

• تعداد و روند رخدادها؛
• تعداد کاربران تحت‌تأثیر؛
• محیطی که خطا در آن رخ داده است؛
• ارتباط خطا با یک Release جدید؛
• اثر خطا بر بخش‌های اصلی اپلیکیشن؛
• جزئیات Stack Trace و Breadcrumbs.

حتی خطایی که فقط یک بار رخ داده است ممکن است به فرایندی حساس مانند پرداخت یا ثبت سفارش مربوط باشد. تصمیم‌گیری درباره Issue باید بر اساس محتوای خطا و اثر آن انجام شود، نه فقط تعداد رخدادها.

خلاصه

برای بررسی یک Issue، ابتدا عنوان، Stack Trace، تعداد رخدادها و روند تغییرات را ببینید. سپس کاربران تحت‌تأثیر، Release، Environment، Breadcrumbs و Context را بررسی کنید.

اگر Eventهای داخل یک Issue به دو مشکل متفاوت اشاره می‌کنند، گروه‌بندی را بازبینی کنید. همچنین اگر اطلاعاتی مانند کاربر، Release یا Breadcrumbs نمایش داده نمی‌شوند، تنظیمات SDK و داده‌های ارسالی اپلیکیشن را بررسی کنید.