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

در سنتری، هر بار وقوع خطا به‌صورت یک رخداد خطا (Error Event) ثبت می‌شود. سنتری رخدادهای مشابه را کنار هم قرار می‌دهد و آن‌ها را در قالب یک Issue نمایش می‌دهد.

Error یک‌بار وقوع خطاست

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

اطلاعات هر رخداد به زبان برنامه‌نویسی، SDK و تنظیمات اپلیکیشن بستگی دارد و می‌تواند شامل موارد زیر باشد:

• نوع خطا و پیام آن؛
• پشته فراخوانی (Stack Trace)؛
• زمان وقوع خطا؛
• مرورگر، سیستم‌عامل یا دستگاه کاربر؛
• نسخه منتشرشده برنامه (Release)؛
• رویدادهای منتهی به خطا (Breadcrumbs)؛
• اطلاعات کاربر یا نشست مرتبط.

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

Issue گروهی از خطاهای مشابه است

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

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

برای مثال، یک Issue ممکن است چنین اطلاعاتی داشته باشد:

NullPointerException in checkout.py:42

First seen: 14:03
Last seen: 14:51
Events: 412
Users affected: 388

در این مثال، ۴۱۲ رخداد مشابه در یک Issue قرار گرفته‌اند. اگر اطلاعات کاربران همراه رخدادها ارسال شده باشد، سنتری می‌تواند تعداد کاربران تحت‌تأثیر را نیز نمایش دهد.

چرا این تفاوت مهم است؟

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

اطلاعات تجمیع‌شده هر Issue در اولویت‌بندی مشکلات هم مؤثر است:

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

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

مدیریت Issueها

در بخش Issues می‌توانید مشکلات ثبت‌شده را جست‌وجو و فیلتر کنید. همچنین می‌توانید هر Issue را به یکی از اعضای تیم واگذار کنید یا وضعیت آن را تغییر دهید.

حل‌شده علامت‌زدن یک Issue، رخدادهای قبلی را حذف نمی‌کند. این کار فقط نشان می‌دهد تیم شما مشکل را بررسی و رفع کرده است. اگر همان خطا دوباره رخ دهد، سنتری می‌تواند Issue را بازگشایی کند یا آن را به‌عنوان بازگشت خطا (Regression) نمایش دهد.

گاهی ممکن است سنتری دو خطای مرتبط را در Issueهای جداگانه قرار دهد یا چند خطای متفاوت را با هم گروه‌بندی کند. در چنین شرایطی می‌توانید روش گروه‌بندی را با استفاده از اثر انگشت (Fingerprint) تغییر دهید. این تنظیم بیشتر برای شرایطی مناسب است که گروه‌بندی پیش‌فرض نتیجه مطلوبی ندارد.

خلاصه

• Error Event: یک‌بار وقوع خطا در زمان و شرایط مشخص؛
• Issue: گروهی از Error Eventهای مشابه که احتمالاً علت مشترکی دارند؛
• Event Count: تعداد دفعات وقوع خطا؛
• Users Affected: تعداد کاربران تحت‌تأثیر، در صورت ارسال اطلاعات کاربر.

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