انتخاب نرخ نمونهبرداری فقط بهمعنای تنظیم یک عدد نیست. این مقدار تعیین میکند چه حجمی از داده برای سنتری ارسال شود و در نتیجه چه میزان از سهمیه (Quota) پلن مصرف میشود. در این مستند بررسی میکنیم چگونه این تنظیم بر ارسال رخدادها اثر میگذارد، چطور مصرف را بازبینی کنیم و چگونه از مصرف بیجای سهمیه جلوگیری کنیم.
تأثیر این تنظیم بر Errorها
مقدار tracesSampleRate فقط به دادههای Performance Monitoring مربوط است و نرخ ارسال Errorها را مستقیماً تغییر نمیدهد.
اگر مقدار آن را کاهش دهید، ثبت خطاها متوقف نمیشود؛ اما ممکن است Transaction و Trace مرتبط ب ا بعضی خطاها در دسترس نباشد. نرخ ارسال Errorها با تنظیمات دیگری مانند sampleRate، فیلترهای SDK و تابع beforeSend کنترل میشود.
همچنین محدودیت پلن همچنان میتواند روی ذخیرهشدن Eventها اثر بگذارد. بنابراین، مستقلبودن تنظیم Error و Transaction به این معنا نیست که Errorها بدون هیچ محدودیتی ذخیره میشوند.
بررسی و تنظیم دوباره نرخ
پس از فعالسازی Performance Monitoring، مصرف پروژه را در بخش Stats بررسی کنید. اگر تعداد Transactionها بیش از انتظار است، ابتدا مشخص کنید کدام پروژه یا عملیات بیشترین نرخ ارسال را دارد.
در صورت نیاز میتوانید:
- مقدار
tracesSampleRateرا کاهش دهید؛ - برای مسیرهای پرتکرار نرخ کمتری در نظر بگیرید؛
- Transactionهای کماهمیت را فیلتر کنید؛
- تنظیمات SDK را بازبینی کنید؛
- پلن سرویس را ارتقا دهید.
اگر محدودیت پلن تمام شود یا Spike Protection فعال شود، ممکن است سنتری بعضی Eventهای جدید را ذخیره نکند و پاسخ 429 برگرداند.
Spike Protection و پاس خ 429
مصرف سنتری فقط بر اساس مجموع ماهانه محدود نمیشود. نرخ ارسال Event ممکن است در بازههای کوتاهتر، مانند یک دقیقه، یک ساعت و یک روز نیز محدود شود.
برای مثال، ممکن است مصرف ماهانه هنوز پایین باشد، اما یک خطای تکرارشونده در چند دقیقه تعداد زیادی Event ایجاد کند. در این شرایط، مکانیزم Spike Protection میتواند ارسال رخدادها را موقتاً محدود کند تا Quota بهصورت ناگهانی مصرف نشود.
هنگامی که سنتری Eventهای جدید را بهدلیل محدودیت ذخیره نمیکند، پاسخ 429 برمیگرداند. این وضعیت به این معناست که رخدادهای پس از آن لحظهبهرسانی ذخیره نمیشوند و بررسی مشکلات عملکردی یا خطاهای جدید ممکن است دشوار شود.
برای جلوگیری از این وضعیت:
- نرخ نمونهبرداری را متناسب با ترافیک تنظیم کنید؛
- رخدادهای پرتکرار و کماهمیت را فیلتر کنید؛
- الگوی ارسال رخدادها و احتمال افزایش ناگهانی آنها را در برآورد مصرف در نظر بگیرید؛
- پس از برطرفشدن افزایش ناگهانی، تنظیمات را به حالت عادی بازگردانید.
اشتباههای رایج
- استفاده از
1.0در یک سرویس پرترافیک بدون برآورد تعداد Transactionها؛ - قراردادن مقدار
0.0با وجود نیاز به بررسی کندی و Traceها؛ - یکسانگرفتن نرخ نمونهبرداری Error و Transaction؛
- نادیدهگرفتن افزایش ترافیک و رخدادهای ناگهانی؛
- تنظیم نرخ بدون بررسی دورهای بخش Stats.
هدف نمونهبرداری
هدف نمونهبرداری، ثبت همه Transactionها نیست. باید دادهای کافی و نماینده از عملکرد اپلیکیشن داشته باشید، بدون اینکه حجم رخدادهای غیرضروری محدودیت پلن را مصرف کند.
یک مقدار مناسب به این شرطها کمک میکند:
- در شرایط عادی به محدودیتهای ارسال نمیرسید؛
- برای افزایش موقت ترافیک حاشیه امن دارید؛
- پاسخ
429بهصورت مکرر دریافت نمیکنید؛ - نرخ نمونهبرداری برای تحلیل عملکرد کافی است؛
- برای دادههای بدون ارزش عملی هزینه اضافی پرداخت نمیکنید.