Перейти к содержимому

Runtime-биллинг: практический уровень

Эта страница для команды, которой нужно не только понимать модель, но и управлять стоимостью в продакшене.

В Usage отслеживайте минимум 4 базовые метрики Runtime:

  • invocations
  • cpu_seconds
  • memory_gb_seconds
  • residency_seconds

Если у вас есть streaming/WebSocket, добавьте:

  • streaming_seconds
  • websocket_connection_seconds

Смотрите не только абсолютные значения, но и скорость роста по дням.

ДрайверЧто увеличивает расходЧто обычно помогает
invocationsлишние фоновые вызовы, дубли запросовкэш, дедупликация, rate limiting
cpu_secondsтяжёлые вычисления на запросprecompute, профилирование, оптимизация hot-path
memory_gb_secondsбольшие объекты и долгие операцииуменьшение рабочей выборки, потоковая обработка
residency_secondsизбыточное удержание готовых экземпляровкорректные idle/pool настройки, авто-пауза
streaming_secondsочень долгие стримысокращение времени сессии, раннее завершение
websocket_connection_secondsдолгоживущие соединения без активноститаймауты неактивности, heartbeat-политика
  1. Зафиксируйте бюджет и лимиты Runtime на месяц.
  2. Настройте предупреждения на 50%, 80% и 100% бюджета.
  3. Ежедневно проверяйте тренд по cpu_seconds и memory_gb_seconds.
  4. При всплеске делайте разбор по проектам, окружениям и релизам.
  5. После оптимизаций сверяйте эффект на 7-дневном окне.
  6. Для защиты от перерасхода используйте Hard Cap.
  1. Проверьте, какая метрика дала основной вклад в рост.
  2. Сопоставьте рост с релизами, миграциями и маркетинговыми кампаниями.
  3. Посмотрите, не выросла ли длительность единичного выполнения.
  4. Проверьте burst-активность и повторные вызовы.
  5. Если рост необъясним, передайте период и разрезы в поддержку.

Hard Cap ограничивает максимальные overage-расходы за период.

  • До порога сервис работает штатно.
  • На пороге срабатывает защитный режим (ограничения ресурсоёмких операций).
  • После пересечения порога нужен следующий расчётный период или ручная корректировка политики.