Session Replay به‌ازای هر رخداد، پرهزینه‌ترین چیزی است که سنتری ثبت می‌کند. یک Replay ضبطی است از نشست کاربر: تغییرهای DOM، کلیک‌ها، اسکرول‌ها، درخواست‌های شبکه و کنسول. این حجم زیادی داده در هر ضبط است؛ بنابراین برخلاف خطاها (ثبت همه) یا Traceها (نمونه‌برداری حدود ۱۰ درصد)، برای Replayها نمونه‌برداری سخت‌گیرانه و عمدی انجام می‌دهید.

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

Replay دو نرخ دارد، نه یکی

این دو نرخ مستقل، در سطح Sentry.init تنظیم می‌شوند؛ نه داخل تنظیمات خود Integration:

• replaysSessionSampleRate — نسبت نشست‌هایی که به‌صورت کامل (از ابتدا تا انتها) ضبط می‌شوند، چه خوب چه بد. این نرخ «پوشش عمومی» شماست. پیش‌فرض آن 0 است.
• replaysOnErrorSampleRate — نسبت نشست‌هایی که به‌خاطر وقوع خطا ضبط می‌شوند. این نرخ «شکار باگ» شماست. پیش‌فرض آن نیز 0 است.

Sentry.init({
  dsn: "…",
  replaysSessionSampleRate: 0.01, // ضبط حدود ۱٪ از همه نشست‌ها
  replaysOnErrorSampleRate: 1.0,  // ضبط هر نشستی که خطا بدهد
  integrations: [Sentry.replayIntegration()],
});

Sentry.replayIntegration() خودش تنظیمات دیگری مانند پنهان‌سازی متن (maskAllText) یا مسدودکردن رسانه (blockAllMedia) را می‌پذیرد، اما نرخ نمونه‌برداری همیشه در سطح Sentry.init تعیین می‌شود.

دلیل این تفکیک، تفاوت هدف‌هاست. نشست‌های عمومی (همان ۱٪) برای پژوهش تجربه کاربری و دیدن نحوه واقعی استفاده از محصول به کار می‌روند. نشست‌های دارای خطا (۱۰۰٪) برای عیب‌یابی‌اند؛ به‌جای حدس‌زدن، روند شکل‌گیری باگ را می‌بینید. بیشتر تیم‌ها به دومی بیشتر از اولی نیاز دارند.

نگاه درست به هر نرخ

replaysOnErrorSampleRate — این را بالا نگه دارید (اغلب ۱.۰). یک Replay متصل به خطا، ارزشمندترین خروجی‌ای است که سنتری برای باگ‌های فرانت‌اند تولید می‌کند: می‌بینید کاربر روی چه چیزی کلیک کرده، DOM چه کرده و کنسول چه گفته است. این‌ها را نمونه‌برداری نکنید، مگر اینکه حجم خطاها آن‌قدر بالا باشد که Replayها سهمیه شما را پر کنند؛ و حتی در آن حالت، بهتر است نویزهای شناخته‌شده را فیلتر کنید تا اینکه به‌صورت تصادفی Replayهای خطا را حذف کنید.

replaysSessionSampleRate — این را پایین نگه دارید (اغلب ۰.۰۱ تا ۰.۰۵). هزینه اصلی در ضبط همه نشست‌های بدون خطاست. نمونه‌برداری ۱ تا ۵ درصد، تعداد کافی نشست نماینده برای پرسش‌های تجربه کاربری فراهم می‌کند، بدون ضبط کل کاربران. برای اپلیکیشن‌های پرترافیک مصرفی، این عدد را باز هم پایین‌تر ببرید (0.001).

این دو نرخ با هم تعامل دارند. نشستی که با replaysSessionSampleRate انتخاب شده، حتی اگر بعداً خطا بدهد به ضبط ادامه می‌دهد. نشستی که در نمونه عمومی نیست، لحظه‌ای که خطا رخ دهد (اگر replaysOnErrorSampleRate اجازه دهد) ضبط را شروع می‌کند؛ این یک Replay «فقط خطا» است که بخش اطراف باگ را ثبت می‌کند، نه کل بازدید.

برآورد حجم Replayها

Replayها بر اساس تعداد ضبط شمرده می‌شوند و هر ضبط می‌تواند حجیم باشد. یک بودجه تقریبی:

replays/day ≈ sessions/day × replaysSessionSampleRate
            + erroring_sessions/day × replaysOnErrorSampleRate

برای سایتی با یک میلیون نشست در روز، نرخ عمومی ۱٪، نرخ خطا ۱۰۰٪ و نرخ خطای واقعی ۰.۲٪:

• نشست‌های عمومی: 1,000,000 × 0.01 = 10,000 replay در روز
• نشست‌های همراه با خطا: 1,000,000 × 0.002 × 1.0 = 2,000 replay در روز
• مجموع: تقریباً 12,000 replay در روز

این عدد را با سهمیه Replay پلن هم‌روش خود مقایسه کنید. اگر replaysSessionSampleRate را خیلی بالا بگذارید، Replayها معمولاً اولین سهمیه‌ای هستند که پر می‌شوند؛ به همین دلیل توصیه پیش‌فرض این است که از عدد پایین شروع کنید و فقط در صورت داشتن ظرفیت خالی و دلیل واقعی (مثلاً یک پژوهش تجربه کاربری) آن را بالا ببرید.

چه تعدادی کافی است

برای عیب‌یابی (نرخ خطا): اغلب یک Replay خوب از یک باگ برای حل آن کافی است. به هزاران Replay از یک خطای یکسان نیاز ندارید؛ یکی نشان می‌دهد کلیک کجا بوده و وضعیت DOM چه بوده است. بنابراین replaysOnErrorSampleRate=1.0 اسراف نیست؛ گروه‌بندی باعث می‌شود در نهایت فقط یک Replay نماینده برای هر Issue بررسی کنید.

برای تجربه کاربری (نرخ عمومی): به‌دنبال الگوها در میان کاربران هستید. این کار به یک برش نماینده نیاز دارد، نه همه نشست‌ها. ۱ تا ۵ درصد در بیشتر سطوح ترافیک برای دیدن الگوها کافی است.

اشتباهی که باید از آن پرهیز کنید

روی یک سایت عملیاتی، بدون بررسی سهمیه Replay خود، replaysSessionSampleRate=1.0 را «برای اطمینان» تنظیم نکنید. Replayها سنگین‌اند؛ ضبط همه نشست‌های یک اپلیکیشن پرترافیک سریع‌ترین راه تمام‌کردن سهمیه است. از عدد پایین شروع کنید و فقط با دلیل مشخص آن را بالا ببرید.

Replayها بُعد حریم خصوصی هم دارند: آن‌ها چیزی را که کاربران می‌بینند و تایپ می‌کنند ثبت می‌کنند. بیشتر SDKها امکان پنهان‌کردن یا مسدودکردن فیلدها و ورودی‌های حساس را فراهم می‌کنند. این یک الزام است، نه یک امکان اختیاری، پیش از فعال‌کردن Replayها با هر نرخ واقعی.

خلاصه

• دو نرخ دارید، هر دو در سطح Sentry.init: replaysSessionSampleRate (عمومی، پایین نگه دارید) و replaysOnErrorSampleRate (عیب‌یابی، بالا نگه دارید).
• معمولاً به Replayهای خطا بیشتر از Replayهای عمومی نیاز دارید.
• Replayها اولین سهمیه‌ای هستند که پر می‌شود؛ replaysSessionSampleRate را حدود ۱٪ شروع کنید و تنظیم کنید.
• برای رفع هر باگ، اغلب یک Replay کافی است؛ Replay درباره دیدن است، نه حجم.