Sentry چیست و چطور کار می‌کند

Sentry شناخته‌شده‌ترین ابزار رصد خطا در دنیاست و برای بسیاری از تیم‌ها مترادف خودِ مفهوم شده است. اگر تازه با این حوزه آشنا می‌شوید، فهمیدن اینکه Sentry چه می‌کند و چطور کار می‌کند، بهترین نقطهٔ شروع است — حتی اگر در نهایت ابزار دیگری انتخاب کنید.

مسئله‌ای که حل می‌کند

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

Sentry این شکاف را پر می‌کند: کتابخانه‌ای که در برنامهٔ شما اجرا می‌شود، خطاها را می‌گیرد و همراه با زمینه‌شان به سرور Sentry می‌فرستد.

چطور کار می‌کند

۱. SDK نصب می‌شود

Sentry.init({
  dsn: 'https://abc123@o0.ingest.sentry.io/456',
  release: 'my-app@1.4.2',
  tracesSampleRate: 0.1,
});

مقدار dsn آدرسی است که می‌گوید داده کجا برود و به کدام پروژه تعلق دارد. عمومی است و در کد فرانت‌اند قرار می‌گیرد؛ اجازهٔ نوشتن می‌دهد نه خواندن.

۲. قلاب‌ها نصب می‌شوند

SDK به رویدادهای سراسری گوش می‌دهد — خطاهای مدیریت‌نشده و Promiseهای رد شده — و توابعی مثل fetch را می‌پوشاند تا درخواست‌های ناموفق را هم ببیند.

۳. زمینه جمع می‌شود

هر رویداد فقط پیام خطا نیست؛ همراهش نسخهٔ انتشار، آدرس صفحه، مرورگر، و مهم‌تر از همه breadcrumb می‌آید: فهرستی از کارهایی که کاربر پیش از خطا انجام داد.

۴. رویداد ارسال می‌شود

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

۵. سرور گروه‌بندی می‌کند

مهم‌ترین بخش. Sentry برای هر خطا یک «اثر انگشت» می‌سازد — بر پایهٔ نوع خطا، پیام و محل وقوع در stack — و همهٔ رویدادهای هم‌اثر را زیر یک Issue جمع می‌کند.

بدون این، یک خطا در صفحهٔ پربازدید ظرف یک روز ده‌ها هزار ردیف می‌سازد و داشبورد بی‌فایده می‌شود.

۶. Source map اعمال می‌شود

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

مفاهیمی که باید بشناسید

Issue — گروهی از رویدادهای مشابه. واحد کاری شما همین است، نه تک‌تک رویدادها.

Event — یک بار رخ دادن.

Release — نسخه‌ای از کد. بدون این نمی‌دانید خطا از انتشار امروز است یا از نسخه‌ای که در کش کاربر مانده.

Environment — تفکیک production از staging.

Sampling — درصدی از رویدادها را می‌فرستید نه همه، برای کنترل هزینه. برای خطاها معمولاً صد درصد منطقی است؛ برای ردیابی کارایی نه.

قابلیت‌های فراتر از خطا

Sentry با گذر زمان از یک ابزار رصد خطا به مجموعه‌ای بزرگ‌تر تبدیل شده: ردیابی کارایی، Session Replay که تعامل کاربر را بازسازی می‌کند، و ویجت بازخورد کاربر.

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

چه داده‌ای جمع می‌کند

سؤالی که پیش از نصب باید بپرسید، مخصوصاً اگر کاربران ایرانی دارید.

SDK به‌صورت پیش‌فرض این‌ها را می‌فرستد: پیام و stack خطا، آدرس صفحه، اطلاعات مرورگر و سیستم‌عامل، نسخهٔ انتشار، و breadcrumbها — که شامل کلیک‌ها، جابه‌جایی بین صفحات و درخواست‌های شبکه است.

آنچه نمی‌فرستد مگر خودتان بخواهید: هویت کاربر، محتوای فرم‌ها، و کوکی‌ها.

ولی دو نقطهٔ نشت هست که باید حواستان باشد: آدرس صفحه اگر شناسه یا ایمیل در پارامترهایش باشد، و breadcrumbهای شبکه که آدرس درخواست‌ها را نگه می‌دارند. Sentry امکان پاک‌سازی پیش از ارسال دارد؛ استفاده از آن اختیاری است ولی نباید باشد.

سه اشتباه رایج در راه‌اندازی

۱. فراموش کردن release. بدون آن نمی‌دانید خطا از کدام نسخه است، source map درست اعمال نمی‌شود، و نمی‌فهمید اصلاح شما واقعاً کار کرده یا نه. این تنها فیلدی است که نباید از قلم بیفتد.

۲. نفرستادن source map. بسیاری از تیم‌ها SDK را نصب می‌کنند و آپلود نقشه‌ها را به بعد موکول می‌کنند. نتیجه ماه‌ها داده‌ای است که خوانده نمی‌شود.

۳. تنظیم نکردن فیلتر از روز اول. خطاهای افزونه‌های مرورگر و اسکریپت‌های شخص ثالث ظرف چند هفته چنان نسبتی از فهرست را می‌گیرند که تیم دیگر نگاهش نمی‌کند. Sentry گزینهٔ ignoreErrors و denyUrls دارد؛ همان اول تنظیمشان کنید.

هزینه و مدل قیمت

Sentry بر اساس تعداد رویداد قیمت‌گذاری می‌کند. پلن رایگان محدودی دارد و پلن Team از حدود ۲۶ دلار در ماه برای ۵۰ هزار خطا شروع می‌شود. Session Replay و ردیابی کارایی سهمیه‌های جداگانه دارند.

نکته‌ای که تیم‌ها را غافلگیر می‌کند: سهمیه با سرعت غیرمنتظره‌ای مصرف می‌شود. یک درخواست شبکه که هر چند ثانیه دوباره تلاش می‌کند، می‌تواند سهمیهٔ ماه را در چند روز خالی کند. برای همین تنظیم فیلتر و محدودسازی نرخ از روز اول اهمیت دارد.

برای تیم ایرانی

سه مانع عملی وجود دارد که ربطی به کیفیت محصول ندارد:

• دسترسی. بدون تحریم‌شکن باز نمی‌شود — و ابزار رصدی که هر بار باز کردنش زحمت دارد، کمتر باز می‌شود.
• پرداخت. کارت خارجی لازم است.
• محل داده. دادهٔ کاربران شما روی سرورهای خارج از کشور می‌نشیند.

گزینه‌هایی که این موانع را حل می‌کنند وجود دارند: نسخهٔ میزبانی‌شده در ایران، نصب self-hosted، یا ابزارهای بومی. مقایسهٔ کاملشان را در مقالهٔ جداگانه‌ای آورده‌ایم.

آیا Sentry برای شما مناسب است؟

بله، اگر: تیم مهندسی چند نفره دارید، به ردیابی کارایی و Session Replay نیاز دارید، و دسترسی و پرداخت برایتان حل شده است.

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

و یک نکتهٔ مهم فارغ از انتخاب: Sentry — و هر ابزار رصد خطای دیگری — فقط خطاهای فنی را می‌بیند. دکمه‌ای که کاربر پیدا نمی‌کند یا متنی که گیج‌کننده است، هیچ خطایی تولید نمی‌کنند. برای آن دسته به مسیر مستقیم دریافت بازخورد کاربر نیاز دارید، در کنار رصد خودکار.

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

• مستندات Sentry — مرجع رسمی
• SDK جاوااسکریپت Sentry — نصب و پیکربندی در مرورگر
• گروه‌بندی رویدادها در Sentry — اثر انگشت و قواعد ادغام خطاها
• صفحهٔ قیمت Sentry — پلن‌ها و سهمیه