اسپن‌ها با tracesSampleRate، خطاها با sampleRate و Replayها با replaysSessionSampleRate و replaysOnErrorSampleRate کنترل می‌شوند. اما متریک‌ها نرخ نمونه‌برداری ندارند؛ حجم آن‌ها به نحوه ابزارگذاری (Instrument) آن‌ها بستگی دارد، نه به نرخی که بعداً تعیین می‌کنید.

گزینه‌ای با نام metricsSampleRate وجود ندارد

متریک‌ها بدون نمونه‌برداری ارسال می‌شوند. هر فراخوانی Sentry.metrics.* در کد شما یک رخداد تولید می‌کند. تنها کلید موجود، enableMetrics است که متریک‌ها را برای کل SDK روشن یا خاموش می‌کند:

Sentry.init({
  dsn: "…",
  enableMetrics: false,
});

این گزینه شکل درصدی ندارد. متریک‌ها رخدادهای کوچکی هستند — یک عدد و چند Attribute — به همین دلیل سنتری آن‌ها را مانند اسپن‌ها یا Replayها نمونه‌برداری نمی‌کند.

چه چیزی حجم را تعیین می‌کند؟

دو عامل، که هر دو در محل فراخوانی تعیین می‌شوند:

تعداد فراخوانی‌ها. یک شمارنده که در هر Request افزایش می‌یابد، به ازای هر Request یک رخداد تولید می‌کند. یک Gauge که هر دقیقه یک‌بار خوانده می‌شود، مستقل از ترافیک، هر دقیقه یک رخداد تولید می‌کند. Gauge را در بازه‌ای بخوانید که تصمیم‌گیری به آن نیاز دارد، نه در هر Request.

کاردینالیتی Attributeها. هر ترکیب یکتا از مقادیر Attributeها، یک سری (Series) جداگانه است. شمارنده checkout.failed که با region (۵ مقدار) و plan_type (۳ مقدار) برچسب‌گذاری شده باشد، ۱۵ سری ایجاد می‌کند. افزودن user_id به‌عنوان Attribute، این تعداد را به یک سری به‌ازای هر کاربر می‌رساند؛ چیزی که هم ذخیره‌سازی آن پرهزینه است و هم قابل تجمیع نیست.

// Attributeهایی با مجموعه مقادیر محدود و شناخته‌شده
Sentry.metrics.count("checkout.failed", 1, {
  attributes: { region: "eu-west", plan_type: "pro" },
});

// شناسه‌ها به‌عنوان Attribute: یک سری به‌ازای هر رخداد
Sentry.metrics.count("checkout.failed", 1, {
  attributes: { user_id: "8f3e...", request_id: "a91c..." },
});

از Attributeها برای ابعادی با مقادیر شناخته‌شده استفاده کنید؛ مانند region، plan، endpoint و status. برای رسیدن از یک متریک به یک Request مشخص، trace_id متریک را در trace دنبال کنید، به‌جای آنکه شناسه را روی خود متریک قرار دهید.

فیلترکردن یک متریک

برای حذف یک متریک خاص از beforeSendMetric استفاده کنید. این قابلیت مانند beforeSend برای خطاها عمل می‌کند:

Sentry.init({
  dsn: "…",
  beforeSendMetric: (metric) => {
    if (metric.name === "debug.heartbeat") return null;
    return metric;
  },
});

تخمین حجم

حجم متریک‌ها برابر تعداد فراخوانی‌هاست، نه تعداد سری‌ها. شمارنده checkout.failed که روزانه در ۲٬۰۰۰ checkout ناموفق فراخوانی می‌شود، روزانه ۲٬۰۰۰ رخداد تولید می‌کند؛ چه با دو Attribute برچسب‌گذاری شده باشد و چه بدون Attribute.

تعداد سری‌ها تعداد رخدادها را تغییر نمی‌دهد، اما بر حجم داده‌های Time Series ذخیره‌شده و اینکه آیا متریک به نتیجه‌ای خوانا تجمیع می‌شود یا نه، اثر می‌گذارد.

انتخاب مواردی که باید ابزارگذاری شوند

• به‌ازای هر حالت خرابی که بر اساس آن اقدام می‌کنید، یک شمارنده داشته باشید، نه به‌ازای هر نوع Exception. payment.declined مفید است؛ اما یک شمارنده به‌ازای هر رشته خطای ارائه‌دهنده پرداخت، مفید نیست.
• Gaugeها را در بازه‌ای بخوانید که تصمیم‌گیری به آن نیاز دارد. عمق صف که هر دقیقه یک‌بار خوانده می‌شود، به پرسش «آیا صف دارد عقب می‌ماند؟» پاسخ می‌دهد.
• از Distribution برای مقادیری استفاده کنید که واقعاً بررسی می‌شوند: ارزش سبد خرید، مدت زمان checkout و تأخیر چند endpoint مهم.