Страница Usage нужна для ежедневного контроля: где растёт нагрузка и почему меняется счёт.
| Метрика | На что влияет |
|---|
invocations | Частота выполнения Runtime |
cpu_seconds | Стоимость вычислений |
memory_gb_seconds | Стоимость использования памяти |
compute_seconds | Стоимость времени работы процесса, включая потоковые ответы и WebSocket |
| Метрика | На что влияет |
|---|
cu_seconds | Стоимость Isolate Compute |
cpu_seconds | Активная нагрузка edge-логики; breakdown |
memory_gb_seconds | Effective memory limit во времени; breakdown |
subrequests | Внешние операции (KV, fetch); diagnostic/control |
| Метрика | На что влияет |
|---|
egress_gb | Стоимость доставки файлов |
storage_gb_month | Стоимость хранения артефактов |
image_transforms | Стоимость трансформации изображений |
origin_fetch_gb | Стоимость обращений к origin |
| Метрика | На что влияет |
|---|
cu_hours | Стоимость CU-weighted вычислительного времени БД |
storage_gb | Стоимость хранения данных (включает written_data) |
data_transfer_gb | Стоимость сетевого трафика к БД |
extra_databases | Стоимость активных баз данных |
extra_branches | Стоимость активных веток БД |
| Метрика | На что влияет |
|---|
build_minutes | Стоимость сборок |
kv_storage_gb_month | Стоимость хранения KV во времени |
kv_read_million_units | Стоимость KV reads |
kv_write_million_units | Стоимость KV writes |
kv_storage_mb | Hard cap объёма KV |
- Смотрите дневной тренд по каждой метрике
- Выделяйте дни с резким ростом (spikes)
- Сверяйте всплески с релизами и изменениями трафика
- Проверяйте, какая именно метрика и какого слоя дала основной вклад в gross/extra usage
- Откройте Usage за текущий период.
- Определите, какие слои использует ваше приложение.
- Найдите метрику с наибольшим отклонением от базового тренда.
- Сопоставьте отклонение с релизом, фичей или нагрузочным событием.
- Примените оптимизацию и сравните результат на 7-дневном окне.
- Рост
cpu_seconds при стабильных invocations — усложнение обработки запроса
- Рост
memory_gb_seconds — большие объекты и долгие операции
- Рост
compute_seconds при стабильном трафике — долгие ответы, WebSocket-соединения или неэффективное удержание экземпляров
- Рост
subrequests — массовые обращения к KV/fetch в цикле
- Рост
cpu_seconds при стабильных invocations — усложнение edge-логики
- Рост
memory_gb_seconds — избыточный configured memory limit
- Рост
kv_storage_gb_month — крупные значения, много ключей без TTL или отсутствие cleanup
- Рост
kv_read_million_units — частые reads или чтение крупных значений
- Рост
kv_write_million_units — частые writes, большие metadata/value или churn ключей
- Рост
egress_gb — увеличение размера файлов или трафика
- Рост
origin_fetch_gb — низкий cache hit rate
- Рост
image_transforms — много вариантов изображений
- Рост
cu_hours — долгоживущие соединения, частые запросы, большой CU size, отсутствие connection pooling
- Рост
storage_gb — накопление данных, раздутый WAL, отсутствие очистки
- Рост
data_transfer_gb — тяжёлые выборки, отсутствие пагинации
| Слой | Сценарий | Что делать |
|---|
| Compute | Много вызовов | кэш, дедупликация, rate limiting |
| Compute | Высокий CPU | профилирование, precompute |
| Compute | Рост памяти | потоковая обработка, уменьшение данных |
| Isolate | Много subrequests | батчинг KV, кэширование fetch |
| Isolate | Высокий CPU | вынос тяжёлой логики в Compute |
| Runtime KV | Рост storage | TTL для временных ключей, удаление старых данных, уменьшение payload |
| Runtime KV | Много reads/writes | батчинг, локальный cache, уменьшение размера value/metadata |
| Static | Высокий egress | сжатие, оптимизация бандлов |
| Static | Cache miss | увеличение TTL, stale-while-revalidate |
| PostgreSQL | Высокие CU-часы | connection pooling, авто-suspend, меньший CU size |
| PostgreSQL | Рост storage | VACUUM, архивирование, удаление старых данных |
| PostgreSQL | Высокий transfer | пагинация, выборка только нужных колонок |
Usage-метрики могут появляться с небольшой задержкой из-за агрегации событий. Для финансовой сверки используйте значения закрытого расчётного периода.