# محافظت در برابر جهش > https://docs.errora.org/billing/spike-protection در پرداخت مصرفی، یک انتشار معیوب واقعاً هزینه دارد: یک حلقهٔ تکرار که به ازای هر درخواست خطا می‌دهد، در یک بعدازظهر به میلیون‌ها رویداد تبدیل می‌شود. محافظت در برابر جهش حجم ساعتی هر پروژه را می‌پاید و وقتی خیلی بالاتر از حالت عادی همان پروژه رفت، داده را دور می‌ریزد. این قابلیت برای همهٔ پروژه‌ها و همهٔ سرویس‌های تحت پوشش **به‌صورت پیش‌فرض فعال** است. ## چه چیزهایی تحت پوشش‌اند | سرویس | واحدهایی که شامل می‌شود | | --- | --- | | خطا و لاگ | رویدادهای خطا، گزارش‌های امنیتی مرورگر، رکوردهای لاگ | | ردیابی | تراکنش‌ها و اسپن‌هایشان | | بازپخش جلسه | سگمنت‌های ضبط‌شدهٔ بازپخش | چک‌این‌های کران و بررسی‌های آپ‌تایم هرگز دور ریخته نمی‌شوند؛ حذف یک چک‌این مثل اجرای ازدست‌رفته دیده می‌شود و حادثهٔ اشتباه باز می‌کند. اجرای رفع خودکار با AI هم دست خود شماست و سیل نمی‌سازد. ## آستانه چطور حساب می‌شود هر ساعت برای هر پروژهٔ محافظت‌شده یک آستانه بر حسب *واحد در ساعت* تعیین می‌شود؛ بزرگ‌ترِ این دو: - **یک کف.** معیار پروژه‌ای که هنوز سابقه‌ای ندارد و کف همهٔ حالت‌های دیگر. برابر است با بزرگ‌ترِ کفِ تنظیم‌شدهٔ سرویس (`SPIKE_PROTECTION_MIN_EVENTS_PER_HOUR`، پیش‌فرض ۱۰٬۰۰۰) و آنچه سه برابر اعتبار باقی‌ماندهٔ کیف پول در ۳۰ روز و تقسیم بر پروژه‌ها، در هر ساعت می‌خرد. - **یک مقدار مبتنی بر مصرف.** میانگین وزنی هفت روز گذشتهٔ حجم ساعتی — با وزن بیشتر برای همان ساعت از شبانه‌روز و همان ساعت از همان روز هفته — ضرب در پنج برابر انحراف معیار همان هفته، محدود به بازهٔ ۳ تا ۶ برابر. پس پروژه‌ای با ترافیک یکنواخت آستانه‌ای چند برابر اوج عادی‌اش می‌گیرد و پروژه‌ای پرنوسان آستانه‌ای بازتر، چون «عادیِ» آن خودش نوسان دارد. ## در جریان جهش چه می‌شود ۱. شمارندهٔ آن ساعت از آستانه عبور می‌کند. ۲. باقی دادهٔ آن سرویس در آن ساعت دور ریخته می‌شود؛ نه ذخیره می‌شود و نه هزینه دارد. ۳. پاسخ `429` است به همراه هدر `X-Sentry-Rate-Limits` سنتری (`…:organization:spike_protection`). SDKهای رسمی این هدر را می‌خوانند و تا پایان پنجره ارسال آن سرویس را متوقف می‌کنند، پس هزینهٔ تلاش‌های مجدد هم حذف می‌شود. ۴. یک جهش ثبت می‌شود و هر قانون هشداری که روی **فعال‌شدن محافظت از جهش** تعریف شده اجرا می‌شود. شمارنده سر ساعت صفر می‌شود، بنابراین داده خودبه‌خود دوباره جریان می‌گیرد. تا وقتی جهش ادامه دارد آستانه هر ساعت بازمحاسبه می‌شود و حجم دورریخته به‌تدریج از سابقه محو می‌شود (حدود ۱۰٪ پس از یک روز و تقریباً صفر پس از دو روز) — پس رشد واقعی و پایدار ظرف یکی دو روز آستانه را بالا می‌برد، نه اینکه برای همیشه محدود بماند. جهش به‌محض اینکه یک ساعتِ کامل زیر آستانه تمام شود بسته می‌شود و **پایان محافظت از جهش** فرستاده می‌شود. ## روشن و خاموش کردن در **تنظیمات ← محافظت از جهش** فهرست پروژه‌ها با یک کلید برای هر سرویس، آستانهٔ فعلی و گزارش جهش‌های اخیر پروژهٔ انتخاب‌شده را می‌بینید. مالک و ادمین می‌توانند تغییرش دهند و بقیه فقط می‌بینند. خاموش‌کردن یک سرویس شمارش حجم را متوقف نمی‌کند، پس اگر دوباره روشنش کنید سابقه آماده است. ## هشدارها در **تنظیمات ← Webhook و هشدار** یک قانون روی *فعال‌شدن محافظت از جهش* / *پایان محافظت از جهش* بسازید و به هر کانالی وصلش کنید: پیامک، ایمیل، تلگرام، بله، Mattermost یا Webhook. متن پیام نام پروژه، سرویس، آستانه و مقدار دورریخته‌شده را می‌گوید. ## API مسیرها هم‌شکل سنتری‌اند، پس یک اسکریپت موجود فقط باید آدرس میزبان را عوض کند. ```bash # وضعیت فعلی همهٔ پروژه‌ها GET /api/v1/organizations//spike-protections # فعال‌سازی (POST) یا غیرفعال‌سازی (DELETE). مقدار projects شناسه، اسلاگ یا ["$all"] است؛ # اگر categories را ندهید همهٔ سرویس‌ها را شامل می‌شود. POST /api/v1/organizations//spike-protections DELETE /api/v1/organizations//spike-protections {"projects": ["my-app"], "categories": ["tracing"]} # تاریخچهٔ جهش‌های یک پروژه GET /api/v1/organizations//spikes/projects/ # حجم ساعتی اخیر + آستانه‌های پیش‌بینی‌شده برای ۲۴ ساعت آینده GET /api/v1/organizations//spike-projection/projects/ ``` ## مرتبط - [کیف پول و پرداخت مصرفی](./wallet.md) — هزینهٔ هر واحدی که دور ریخته شده است. - **نرخ نمونه‌برداری** هر پروژه (تنظیمات ← پروژه) نسخهٔ ایستای همین ایده است: همیشه کسر ثابتی از رویدادها را دور می‌ریزد، در حالی که محافظت از جهش فقط وقتی حجم غیرعادی شد وارد عمل می‌شود.