مقایسهٔ ابزارهای رصد خطا برای تیمهای ایرانی
در این مقاله میخوانید
- معیارهایی که واقعاً تصمیم را میسازند
- ۱. دسترسی و پرداخت
- ۲. زبان داشبورد
- ۳. نحوهٔ شمارش سهمیه
- ۴. بازخورد کاربر
- ۵. عمق فنی
- گزینهها، یکییکی
- Sentry.io
- همروش (Sentry میزبانیشده)
- هانتانا
- GlitchTip یا Sentry self-hosted
- باگماگ
- جدول تصمیم
- هزینههای پنهانی که در جدول قیمت نیستند
- هزینهٔ پیوستها
- هزینهٔ کاربر
- هزینهٔ یادگیری
- هزینهٔ نگهداری در حالت self-hosted
- در دورهٔ آزمایشی دقیقاً چه چیزی را تست کنید
- سه اشتباه رایج در انتخاب
- ترکیب کردن هم گزینه است
- پیشنهاد عملی
- منابع و مطالعهٔ بیشتر
انتخاب ابزار رصد خطا معمولاً با مقایسهٔ فهرست ویژگیها شروع میشود و با پشیمانی تمام میشود — چون ویژگیهایی که در جدول مقایسه میدرخشند، معمولاً همانهایی نیستند که در عمل روزانه اهمیت دارند.
این مقاله سعی میکند مقایسه را بر اساس چیزی بچیند که واقعاً تصمیم را تعیین میکند. ما خودمان یکی از گزینهها هستیم و این را پنهان نمیکنیم؛ در عوض سعی کردهایم دربارهٔ جاهایی که گزینهٔ دیگری بهتر است هم صریح باشیم. اگر مشکلتان مشخصاً دسترسی به خود Sentry است، جایگزین ایرانی Sentry را هم ببینید.
معیارهایی که واقعاً تصمیم را میسازند
۱. دسترسی و پرداخت
برای تیم ایرانی این اولین فیلتر است، نه آخرین. ابزاری که هر بار برای دیدنش باید تحریمشکن روشن کنید، در عمل کمتر باز میشود — و ابزار رصدی که کسی نگاهش نمیکند، ارزشی ندارد.
۲. زبان داشبورد
اگر فقط توسعهدهندهها قرار است داشبورد را ببینند، انگلیسی مشکلی نیست. ولی اگر مدیر محصول، پشتیبانی یا مدیر پروژه هم باید بتوانند نگاه کنند، فارسی بودن تفاوت بین «ابزاری که تیم استفاده میکند» و «ابزاری که فقط یک نفر بلد است» را میسازد.
۳. نحوهٔ شمارش سهمیه
مهمترین معیاری که معمولاً نادیده گرفته میشود. یک صفحهٔ پربازدید با یک خطای تکراری میتواند دهها هزار رویداد در روز تولید کند. بپرسید: رویدادهای تکراری جداگانه شمرده میشوند؟ محدودسازی نرخ دارید؟ وقتی سهمیه تمام شد، داده دور ریخته میشود یا صورتحساب بالا میرود؟
۴. بازخورد کاربر
آیا ابزار فقط خطای فنی میبیند، یا کاربر هم میتواند مستقیماً چیزی بگوید؟ این تفاوت، دستهٔ کاملی از مشکلات را پوشش میدهد که هیچ خطایی تولید نمیکنند.
۵. عمق فنی
Source map، breadcrumb، ردیابی نسخهٔ انتشار، تشخیص رگرسیون. اگر تیم مهندسی جدی دارید، اینها فرق بین «میدانم خطایی هست» و «میدانم کدام کامیت باعثش شد» است.
گزینهها، یکییکی
Sentry.io
استاندارد صنعت و از نظر فنی بیرقیب. Source map، ردیابی کارایی، Session Replay، ویجت بازخورد کاربر، و پشتیبانی از تقریباً هر زبان و فریمورکی.
برای تیم ایرانی: نیاز به تحریمشکن، پرداخت دلاری، و خروج داده از کشور. ویجت بازخوردش روی موبایل اسکرینشات نمیگیرد و اسکرینشاتها از سهمیهٔ پیوست کم میشوند.
انتخابش کنید اگر: تیم بینالمللی دارید یا زیرساخت پرداخت خارجی برایتان حل شده است.
همروش (Sentry میزبانیشده)
همان Sentry، روی زیرساخت ایران، با پرداخت تومانی. پلن رایگانش ۵٬۰۰۰ رویداد در ماه است و پلن ۵۰٬۰۰۰ رویدادی حدود ۱٬۶۰۰٬۰۰۰ تومان.
قوتش: تمام عمق فنی Sentry بدون هیچکدام از دردسرهای دسترسی. اگر تیمتان از قبل با Sentry کار کرده، مهاجرت تقریباً بدون تغییر کد است.
محدودیتش: داشبورد Sentry است، یعنی انگلیسی و طراحیشده برای مهندس. برای تیمی که مدیر محصول و پشتیبانی هم باید در آن نگاه کنند، مانع ایجاد میکند.
انتخابش کنید اگر: واقعاً به عمق Sentry نیاز دارید و تیمتان فنی است.
هانتانا
ابزار ایرانی تحلیل رفتار کاربر: هیتمپ، نظرسنجی، NPS، پاپآپ و ویجت بازخورد با اسکرینشات.
قوتش: کاملاً فارسی، و برای فهمیدن رفتار کاربر و بهبود نرخ تبدیل ابزار خوبی است.
محدودیتش: رصد خودکار خطا ندارد. اگر خطای جاوااسکریپتی دکمهٔ پرداخت را از کار بیندازد، هانتانا به شما نمیگوید — مگر اینکه کاربری زحمت گزارش دادن را بکشد.
انتخابش کنید اگر: مسئلهٔ اصلیتان بهینهسازی نرخ تبدیل است نه کیفیت فنی. در کنار یک ابزار رصد خطا مکمل خوبی است.
GlitchTip یا Sentry self-hosted
متنباز، روی سرور خودتان، بدون هزینهٔ اشتراک.
قوتش: داده هرگز از زیرساخت شما خارج نمیشود. GlitchTip با همان SDKهای Sentry کار میکند و بسیار سبکتر از Sentry کامل است.
محدودیتش: نگهداری با شماست — بهروزرسانی، پشتیبان، و پایش خودِ سیستم. Sentry self-hosted منابع سنگینی میخواهد؛ GlitchTip بسیار معقولتر است ولی قابلیت کمتری دارد.
انتخابش کنید اگر: الزام قراردادی یا سازمانی برای نگهداری داده در داخل دارید.
باگماگ
رصد خودکار خطا بهعلاوهٔ ویجت گزارش باگ کاربر با اسکرینشات، در یک داشبورد فارسی راستچین.
قوتش: هر دو نیمه در یک جا و به هم گره خورده — خطای فنی و گزارش کاربر کنار هم دیده میشوند. ویجت راستچین است و کاربر میتواند جابهجایش کند. اسکرینشات روی موبایل هم کار میکند. قیمت بر اساس گزارش کاربر است نه حجم رویداد، پس ترافیک بالای سایت شما را جریمه نمیکند.
محدودیتش: Session Replay و ردیابی عمیق کارایی نداریم. اکوسیستم و مستنداتمان به گستردگی Sentry نیست.
انتخابش کنید اگر: تیم کوچک یا متوسطی هستید که هم میخواهد خطاها را ببیند و هم صدای کاربر را بشنود، و ترجیح میدهد ابزارش را کل تیم بتواند بخواند.
جدول تصمیم
بهجای جدول ویژگیها، از این مسیر تصمیم استفاده کنید:
- الزام دارید داده در سرور خودتان بماند؟ → GlitchTip.
- تیم مهندسی بزرگ و نیاز به عمق کامل Sentry؟ → همروش.
- پرداخت خارجی برایتان حل است و تیم بینالمللی دارید؟ → Sentry مستقیم.
- مسئلهتان نرخ تبدیل است نه خطای فنی؟ → هانتانا.
- تیم کوچک، داشبورد فارسی، و میخواهید صدای کاربر را هم بشنوید؟ → باگماگ.
هزینههای پنهانی که در جدول قیمت نیستند
قیمت اعلامشده معمولاً کل هزینه نیست. چهار موردی که بعداً خودشان را نشان میدهند:
هزینهٔ پیوستها
اسکرینشاتها معمولاً از سهمیهٔ جداگانهای کم میشوند. در Sentry هر پلن حدود یک گیگابایت پیوست دارد که تقریباً معادل ۲٬۵۰۰ اسکرینشات است. اگر ویجت بازخورد را جدی استفاده کنید، این سقف زودتر از سقف رویداد پر میشود.
هزینهٔ کاربر
اگر سرویس بهازای هر کاربر هزینه بگیرد، تیم شش نفره میتواند قیمت را چند برابر کند. بدتر اینکه معمولاً باعث میشود دسترسی را محدود کنید — و ابزاری که فقط دو نفر میبینندش، نصف ارزشش را از دست میدهد.
هزینهٔ یادگیری
ابزار قدرتمندتر یعنی زمان بیشتر برای راهاندازی درست. اگر تیم شما دو نفره است، چند روز صرف پیکربندی Sentry کردن هزینهٔ واقعی است — حتی اگر در فاکتور نیاید.
هزینهٔ نگهداری در حالت self-hosted
«رایگان» بودن نرمافزار متنباز به معنی رایگان بودن سرویس نیست. سرور، پشتیبانگیری، بهروزرسانی و پایشِ خودِ سیستم رصد، همگی وقت مهندسی میخواهند. تیمهایی که این مسیر را رفتهاند معمولاً میگویند هزینهٔ سرور کمترین بخش بود.
در دورهٔ آزمایشی دقیقاً چه چیزی را تست کنید
بیشتر تیمها دورهٔ آزمایشی را با نصب کردن و نگاه کردن به داشبورد میگذرانند. این کافی نیست. این پنج کار را عمداً انجام دهید:
- یک خطای واقعی بیندازید و ببینید چقدر طول میکشد تا در داشبورد ظاهر شود و چقدر اطلاعات همراهش هست.
- کد فشرده را تست کنید، نه نسخهٔ توسعه. اگر source map درست کار نکند، در production عملاً کور خواهید بود.
- یک خطای تکراری بسازید — مثلاً درخواستی که مدام شکست میخورد — و ببینید سرویس آن را گروهبندی میکند یا صد ردیف جدا میسازد.
- روی موبایل واقعی تست کنید، نه شبیهساز. مخصوصاً اگر ویجت بازخورد برایتان مهم است.
- داشبورد را به یکی از اعضای غیرفنی تیم نشان دهید و ببینید چیزی از آن میفهمد یا نه. این تست ساده، بیشتر از هر جدول ویژگی، آیندهٔ استفاده از ابزار را پیشبینی میکند.
سه اشتباه رایج در انتخاب
مقایسه بر اساس تعداد ویژگی. ابزاری با پنجاه قابلیت که تیم شما از سهتایش استفاده میکند، از ابزاری با ده قابلیت که همهشان استفاده میشوند بدتر است. پیچیدگی هزینه دارد، حتی وقتی رایگان است.
نادیده گرفتن اینکه چه کسی قرار است نگاه کند. اگر فقط یک نفر در تیم بتواند داشبورد را بخواند، آن ابزار به یک گلوگاه تبدیل میشود.
انتخاب بر اساس سقف پلن پولی. شما ماه اول را روی پلن رایگان میگذرانید. اگر سقف رایگان کوچک باشد، ارزیابی واقعی هرگز اتفاق نمیافتد.
ترکیب کردن هم گزینه است
این مقایسه طوری نوشته شده که انگار باید یکی را انتخاب کنید، ولی در عمل بسیاری از تیمها دو ابزار مکمل دارند و این تصمیم بدی نیست — به شرطی که آگاهانه باشد.
ترکیبهایی که منطقیاند:
- رصد خطا + ابزار تحلیل رفتار. اولی میگوید چه چیزی خراب است، دومی میگوید کجا کاربران گیر میکنند بدون اینکه چیزی خراب باشد. این دو سؤال متفاوتند و یک ابزار معمولاً هر دو را خوب جواب نمیدهد.
- رصد فرانتاند + لاگ بکاند. خطای مرورگر و خطای سرور دو دنیای جدا هستند. تیمهایی که فقط یکی را دارند، نیمی از تصویر را میبینند.
و ترکیبی که منطقی نیست: دو ابزار رصد خطا بهطور همزمان و دائمی. برای دو هفتهٔ ارزیابی خوب است، ولی بعد از آن فقط هزینه و سردرگمی است — و معمولاً هیچکدام را کسی جدی نمیگیرد چون معلوم نیست کدام منبع حقیقت است.
پیشنهاد عملی
دو گزینه را همزمان روی یک سایت نصب کنید و دو هفته بگذارید هر دو کار کنند. هیچ مقالهای — از جمله همین — بهاندازهٔ دیدن دادهٔ واقعی سایت خودتان در دو داشبورد، تصمیم را روشن نمیکند. هر دو SDK سبکاند و تداخلی با هم ندارند.
بعد از دو هفته بپرسید: کدام داشبورد را بیشتر باز کردم؟ کدامیک چیزی نشانم داد که نمیدانستم؟ کدامیک را میتوانم به بقیهٔ تیم نشان دهم؟ پاسخ این سه سؤال، از هر جدول مقایسهای دقیقتر است.
منابع و مطالعهٔ بیشتر
- صفحهٔ قیمت Sentry — پلنها و سهمیهٔ رسمی
- مدیریت سهمیه در Sentry — اینکه رویدادها چطور شمرده و محدود میشوند
- مستندات GlitchTip — راهاندازی و نگهداری نسخهٔ متنباز
- مستندات Sentry self-hosted — منابع سختافزاری و سرویسهای لازم
باگماگ را رایگان امتحان کنید
خطاهای سایتتان را خودکار ثبت کنید و بگذارید کاربران با یک کلیک باگ گزارش دهند.
شروع رایگان