پس از تنظیم نرخ نمونهبرداری، فیلترکردن رخدادهای غیرضروری و بررسی میزان مصرف، باید پلنی را انتخاب کنید که با حجم واقعی دادههای اپلیکیشن هماهنگ باشد.
نام پلنها، محدودیتها و قیمتها ممکن است تغییر کنند؛ بنابراین در این مستند عدد یا پلن مشخصی پیشنهاد نمیکنیم. هدف این است که حجم تقریبی رخدادها را محاسبه کنید، آن را با محدودیت پلنها مقایسه کنید و کوچکترین پلنی را انتخاب کنید که حاشیه امن کافی دارد.
چرا انتخاب پلن اهمیت دارد؟
اگر پلن کوچکتر از نیاز اپلیکیشن باشد، ممکن است سهمیه (Quota) پیش از پایان دوره مصرف شود. در این حالت، سنتری Eventهای جدید را ذخیره نمیکند و هنگام ارسال آنها پاسخ 429 برمیگرداند. این وضعیت ممکن است باعث شود بعضی خطاها یا دادههای عملکردی مهم ثبت نشوند.
انتخاب پلنی بسیار بزرگتر از نیاز نیز هزینه غیرضروری ایجاد میکند. همچنین بالاگذاشتن نرخ نمونهبرداری فقط بهدلیل وجود سهمیه بیشتر، الزاماً اطلاعات مفیدتری در اختیار شما قرار نمیدهد.
پلن مناسب باید دو ویژگی داشته باشد:
- حجم معمول رخدادهای اپلیکیشن را پوشش دهد؛
- برای افزایش ترافیک و رخدادهای پیشبینینشده حاشیه امن داشته باشد.
چه دادههایی را باید بررسی کنیم؟
برای تخمین مصرف، ابتدا مشخص کنید اپلیکیشن چه نوع دادههایی را برای سنتری میفرستد.
Errorها
هر بار وقوع یک خطا میتواند یک یا چند رخداد خطا (Error Event) ایجاد کند. حجم Errorها به ترافیک اپلیکیشن، نرخ بروز خطا و تنظیمات SDK بستگی دارد.
اگر بعضی خطاها برای شما ارزش عملی ندارند، بهتر است آنها را پیش از ارسال فیلتر کنید. ارسال مداوم خطاهای شناختهشده یا کماهمیت میتواند سهمیه را مصرف کند و پیداکردن خطاهای مهم را دشوارتر سازد.
Transactionها
با فعالبودن پایش عملکرد (Performance Monitoring)، SDK برای عملیاتهایی مانند درخواستهای HTTP، بارگذاری صفحهها و وظایف پسزمینه Transaction ایجاد میکند.
تعداد Transactionهای ارسالی با مقدار tracesSampleRate کنترل میشود. برای مثال، مقدار 0.1 یعنی تقریباً ۱۰ درصد Transactionها برای سنتری ارسال شوند.
Session Replay
اگر Session Replay را فعال کردهاید، تعداد نشستهای ضبطشده و نرخ نمونهبرداری آن را نیز در محاسبه مصرف در نظر بگیرید.
نحوه محاسبه Replay ممکن است با Error و Transaction متفاوت باشد. پیش از انتخاب پلن، محدودیت مربوط به Replay و تنظیمات نرخ نمونهبرداری آن را در مشخصات پلن بررسی کنید.
تخمین مصرف ماهانه
اگر پروژه شما مدتی فعال بوده است، بخش Stats بهترین مرجع برای بررسی مصرف واقعی است. در این بخش میتوانید Eventهای موفق و ناموفق را بر اساس نوع رخداد، پروژه و بازه زمانی ببینید.
برای پروژهای که هنوز داده کافی ندارد، میتوانید از تخمین اولیه استفاده کنید.
تعداد تقریبی Transactionهای ماهانه:
تعداد عملیات روزانه × tracesSampleRate × ۳۰
برای مثال، اگر اپلیکیشن روزانه ۱۰۰٬۰۰۰ عملیات قابلاندازهگیری داشته باشد و tracesSampleRate برابر 0.1 باشد:
100,000 × 0.1 × 30 = 300,000 Transaction در ماه
تعداد تقریبی Errorهای ماهانه:
تعداد عملیات روزانه × نرخ تقریبی خطا × ۳۰
اگر روزانه ۱۰۰٬۰۰۰ عملیات داشته باشید و نرخ خطا را 0.005 یا نیم درصد در نظر بگیرید:
100,000 × 0.005 × 30 = 15,000 Error در ماه
این محاسبهها تقریبیاند. تعداد واقعی Eventها به SDK، Integrationهای فعال، نحوه تعریف Transactionها و تنظیمات فیلتر و نمونهبرداری بستگی دارد.
Spanهای داخل یک Transaction را فقط زمانی جداگانه در محاسبه Quota وارد کنید که در مشخصات پلن صراحتاً به محاسبه مستقل Span اشاره شده باشد.
یک عدد کافی نیست
بهتر است مصرف را در سه حالت تخمین بزنید:
- حداقل: ترافیک عادی با نرخ نمونهبرداری پایینتر؛
- واقعبینانه: ترافیک و نرخ خطای معمول اپلیکیشن؛
- حداکثر: افزایش ترافیک، انتشار نسخه جدید یا رخدادهای غیرمنتظره.
پلن انتخابی باید تخمین واقعبینانه را با حاشیه امن پوشش دهد. انتخاب پلنی که فقط با حداقل مصرف سازگار است، احتمال تمامشدن Quota را افزایش میدهد. از طرف دیگر، لازم نیست برای بدترین حالت غیرمحتمل، بزرگترین پلن را انتخاب کنید.
محدودیتهای زمانی را بررسی کنید
مصرف سنتری فقط بر اساس مجموع ماهانه محدود نمیشود. نرخ ارسال Event ممکن است در بازههای کوتاهتر، مانند یک دقیقه، یک ساعت و یک روز نیز محدود شود.
برای مثال، ممکن است مصرف ماهانه شما هنوز پایین باشد، اما یک خطای تکرارشونده در چند دقیقه تعداد زیادی Event ایجاد کند. در این شرایط، مکانیزم Spike Protection میتواند ارسال رخدادها را موقتاً محدود کند تا Quota بهصورت ناگهانی مصرف نشود.
بنابراین، هنگام انتخاب پلن فقط مجموع ماهانه را بررسی نکنید. الگوی ارسال رخدادها و احتمال افزایش ناگهانی آنها نیز اهمیت دارد.
انتخاب پلن برای پروژه جدید
برای پروژهای که هنوز سابقه مصرف ندارد، این مراحل را انجام دهید:
- تعداد تقریبی درخواستها، صفحههای بازشده و وظایف پسزمینه را محاسبه کنید.
- نرخ فعلی Errorها را تخمین بزنید.
- مقدار اولیه
tracesSampleRateرا مشخص کنید. - مصرف Error، Transaction و Replay را جداگانه برآورد کنید.
- پلنی را انتخاب کنید که تخمین واقعبینانه را با حاشیه امن پوشش دهد.
- پس از شروع کار، بخش Stats را بهصورت دورهای بررسی کنید.
تخمین اولیه همیشه مقداری خطا دارد. پس از جمعآوری داده واقعی، نرخهای نمونهبرداری و پلن را بر اساس مصرف مشاهدهشده تنظیم کنید.
جزئیات Eventها در سنتری همروش تا ۱۵ روز نگهداری میشوند، اما آمار مصرف سازمان در بخش Stats تا ۹۰ روز در دسترس است. از این بازه برای بررسی روند مصرف و تصمیمگیری درباره پلن استفاده کنید.
پیش از ارتقای پلن چه کار کنیم؟
اگر مصرف به محدودیت پلن نزدیک شده است، پیش از ارتقا این موارد را بررسی کنید:
-
رخدادهای غیرضروری را فیلتر کنید. با تنظیماتی مانند
beforeSendاز ارسال Errorهای شناختهشده و کماهمیت جلوگیری کنید. -
نرخ Transactionها را کاهش دهید. مقدار
tracesSampleRateرا متناسب با حجم ترافیک تنظیم کنید. -
نمونهبرداری هدفمند داشته باشید. برای مسیرها و عملیاتهای مهم نرخ بیشتری در نظر بگیرید و عملیاتهای پرتکرار و کماهمیت را با نرخ پایینتری ثبت کنید.
-
نرخ Session Replay را بازبینی کنید. اگر تعداد Replayها زیاد است، نرخ ضبط نشستهای عادی و نشستهای دارای خطا را متناسب با نیاز تغییر دهید.
-
ارسال ناگهانی Eventها را بررسی کنید. افزایش غیرعادی مصرف ممکن است به یک خطای تکرارشونده یا پیکربندی نادرست SDK مربوط باشد.
-
در صورت نیاز پلن را ارتقا دهید. اگر پس از حذف دادههای غیرضروری و تنظیم نرخها همچنان به حجم بیشتری نیاز دارید، پلن بزرگتری انتخاب کنید.
نشانههای انتخاب درست پلن
پلن شما زمانی متناسب است که:
- در شرایط عادی به محدودیتهای ارسال نمیرسید؛
- برای افزایش موقت ترافیک حاشیه امن دارید؛
- پاسخ
429بهصورت مکرر دریافت نمیکنید؛ - نرخ نمونهبرداری برای تحلیل عملکرد کافی است؛
- بخش Issues بیشتر شامل خطاهای قابلبررسی و مفید است؛
- برای دادههای بدون ارزش عملی هزینه اضافی پرداخت نمیکنید.
هدف، ثبت بیشترین حجم داده نیست. باید دادهای کافی و قابلاستفاده برای شناسایی خطاها و مشکلات عملکردی داشته باشید، بدون اینکه رخدادهای غیرضروری Quota را مصرف کنند.