INFOОбмеження швидкості доступне в Cellar API v3.4.0+
Cellar включає вбудоване обмеження швидкості для захисту вашого розгортання від зловживань, вичерпання ресурсів та атак типу “відмова в обслуговуванні”. Обмеження швидкості увімкнено за замовчуванням та використовує алгоритм ковзаючого вікна на основі Redis.
Обмеження швидкості обмежує кількість запитів API, які клієнт може зробити протягом часового вікна. Коли клієнт перевищує свій ліміт, Cellar повертає HTTP 429 (Too Many Requests) з інформацією про те, коли можна повторити спробу.
Основні функції:
Cellar застосовує різні ліміти на основі вартості операцій:
Кінцеві точки:
POST /api/v1/secret - Створити секрет (v1)POST /api/v2/secret - Створити секрет (v2)POST /api/v1/secret/:id/access - Доступ до вмісту секрету (v1)POST /api/v2/secret/:id/access - Доступ до вмісту секрету (v2)Обґрунтування: Ці операції включають криптографію (шифрування/дешифрування). Ліміт за замовчуванням 300 запитів/хвилину (5 запитів/секунду) відповідає стандартам REST API професійного рівня, залишаючись консервативним відносно можливостей базової криптографічної бекенд-системи. Цей ліміт запобігає зловживанням, дозволяючи нормальні шаблони використання командою та сплески активності.
Кінцеві точки:
GET /api/v1/secret/:id - Отримати метадані секрету (v1)GET /api/v2/secret/:id - Отримати метадані секрету (v2)DELETE /api/v1/secret/:id - Видалити секрет (v1)DELETE /api/v2/secret/:id - Видалити секрет (v2)Обґрунтування: Ці операції запитують або змінюють сховище даних, але не включають криптографію. Вони менш дорогі, ніж Рівень 1, але все ще вимагають доступу до бекенду. Множник 2x відносно Рівня 1 дозволяє типові робочі процеси інтерфейсу, такі як отримати метадані → дешифрувати → видалити, без досягнення лімітів швидкості.
Кінцеві точки:
GET /api/v2/config - Запит лімітів конфігураціїОбґрунтування: Ця кінцева точка повертає кешовані значення конфігурації без бекенд-операцій. Вищий ліміт дозволяє API-клієнтам часто запитувати ліміти перед надсиланням без турботи про обмеження швидкості.
Кінцеві точки:
GET /health-check - Кінцева точка перевірки здоров’яОбґрунтування: Системи моніторингу потребують частих перевірок здоров’я. Дуже високий ліміт запобігає хибним негативним результатам у моніторингу без створення ризику зловживання, оскільки перевірки здоров’я виконують мінімальну роботу.
Cellar включає стандартні заголовки обмеження швидкості на всіх відповідях:
На Всіх Відповідях (200, 201, 400, 404, тощо):
X-RateLimit-Limit: 300 - Максимальна кількість запитів дозволена у вікні для цього рівня кінцевої точкиX-RateLimit-Remaining: 287 - Запити, що залишилися в поточному вікніX-RateLimit-Reset: 1736705220 - Unix timestamp коли вікно скидаєтьсяНа 429 Too Many Requests:
X-RateLimit-Remaining: 0)Retry-After: 42 - Секунди до скидання обмеження швидкостіПриклад:
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1736705220
Retry-After: 42
{
"error": "rate limit exceeded"
}
Обмеження швидкості налаштовується через змінні середовища. Див. Довідник Конфігурації - Поточна Версія для повних налаштувань обмеження швидкості та значень за замовчуванням.
X-Forwarded-For для клієнтів за проксі/балансувальниками навантаженняЛіміти за замовчуванням відповідають стандартам REST API професійного рівня та підходять для більшості розгортань, включаючи організації середнього розміру. Розгляньте налаштування, якщо:
Збільшити ліміти коли:
Зменшити ліміти коли:
Порушення обмеження швидкості реєструються на рівні INFO:
Rate limit exceeded for client 192.168.1.100 on tier tier1
Моніторте ці шаблони:
“Rate limit exceeded” для легітимних користувачів:
Обмеження швидкості не працює:
RATE_LIMIT_ENABLED=trueХибні позитивні результати від моніторингу:
RATE_LIMIT_HEALTH_CHECK_REQUESTS_PER_WINDOW