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