سهمیه، مدت نگه‌داری و محدودیت‌ها

این برگه همهٔ عددهایی را که روی ارسال و نگه‌داری لاگ اثر دارند یک‌جا آورده است: پلن‌ها، نحوهٔ شمارش حجم، اتفاقی که در عبور از سهمیه می‌افتد، مدت نگه‌داری و محدودیت‌های هر درخواست.

پلن‌ها

قیمت‌ها ماهانه و به تومان است:

پرداخت ریالی است. سهمیه و مصرف در سطح سازمان حساب می‌شود، نه هر پروژه؛ مصرف ماه جاری را در بخش «مصرف سازمان» در صفحهٔ هر پروژه می‌بینید.

حجم چطور شمرده می‌شود

معیار، حجم دادهٔ دریافتی پس از باز کردن فشرده‌سازی است. پس فشرده کردن بدنه با gzip پهنای باند شبکهٔ شما را کم می‌کند، ولی سهمیه را نه. برای کم کردن مصرف واقعی:

• سطح پیش‌فرض را در پروداکشن Information بگذارید و Debug را فقط موقت روشن کنید.
• لاگ‌های پرحجم و کم‌ارزش چارچوب‌ها (مثل هر کوئری Entity Framework یا هر درخواست health check) را در سطح Warning نگه دارید.
• بدنهٔ کامل درخواست و پاسخ را لاگ نکنید.

دربارهٔ حساب‌وکتاب حجم و مدت نگه‌داری، مقالهٔ لاگ را چند روز نگه داریم؟ را ببینید.

رسیدن به سقف ماهانه

• پلن رایگان در سقف می‌ایستد. وقتی حجم ماه به ۱ گیگابایت برسد، لاگ بیشتر پذیرفته نمی‌شود و ingest با کد 403 پاسخ می‌دهد تا دورهٔ ماهانهٔ بعد شروع شود یا پلن را ارتقا دهید. این رفتار عمدی است: سازمانی که اطلاعات پرداخت ندارد نباید بدهی بیاورد.
• پلن‌های پولی هرگز لاگ را دور نمی‌ریزند. اگر از حجم پلن بگذرید، لاگ‌ها مثل قبل پذیرفته و ذخیره می‌شوند و مازاد گیگی ۴۰٬۰۰۰ تومان حساب می‌شود. وسط یک حادثه، که حجم لاگ معمولاً بالا می‌رود، لاگ‌ها قطع نمی‌شوند.

مدت نگه‌داری

• هر لاگ به اندازهٔ مدت نگه‌داری پلن (۷، ۳۰، ۹۰ یا تا ۳۶۵ روز) نگه داشته و بعد خودکار حذف می‌شود.
• لاگی که زمانش قدیمی‌تر از مدت نگه‌داری پلن باشد پذیرفته نمی‌شود؛ مثلاً در پلن رایگان نمی‌توانید لاگ‌های یک ماه پیش را درون‌ریزی کنید. چنین خطوطی در پاسخ جزو ردشده‌ها شمرده می‌شوند و بقیهٔ دسته ثبت می‌شود.
• زمانی که بیش از یک ساعت جلوتر از حال باشد، با زمان دریافت جایگزین می‌شود؛ معمولاً یعنی ساعت سرور فرستنده تنظیم نیست.

محدودیت‌های هر درخواست

نرخ ارسال و شلوغی

• هر پروژه نرخ ارسال مجازی دارد که با پلن بالا می‌رود و جهش‌های کوتاه را تحمل می‌کند. عبور مداوم از آن پاسخ 429 با هدر Retry-After می‌گیرد.
• اگر سرویس دریافت موقتاً شلوغ باشد، پاسخ 503 با Retry-After برمی‌گردد.
• exporterهای OpenTelemetry و sink در Serilog در هر دو حالت خودکار دوباره تلاش می‌کنند. اگر خودتان با HTTP می‌فرستید، همین کار را بکنید؛ مرجع API را ببینید.
• اگر پایگاه داده لحظه‌ای در دسترس نباشد، لاگ‌های پذیرفته‌شده روی دیسک نگه داشته و بعداً ثبت می‌شوند؛ پاسخ موفق یعنی لاگ گم نمی‌شود.

خلاصهٔ کدهای پاسخ