Страница Usage нужна для ежедневного контроля: где растёт нагрузка и почему меняется счёт.
| Метрика |
На что влияет |
invocations |
Частота выполнения Runtime |
cpu_seconds |
Стоимость вычислений |
memory_gb_seconds |
Стоимость использования памяти |
compute_seconds |
Стоимость времени работы процесса, включая потоковые ответы и WebSocket |
| Метрика |
На что влияет |
egress_gb |
Стоимость доставки файлов |
storage_gb_month |
Стоимость хранения артефактов |
image_transforms |
Стоимость трансформации изображений |
origin_fetch_gb |
Стоимость обращений к origin |
| Метрика |
На что влияет |
cu_hours |
Стоимость CU-weighted вычислительного времени БД |
storage_gb_month |
Стоимость хранения данных по времени (включает 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-соединения или неэффективное удержание экземпляров
- Рост
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_month — накопление данных, раздутый WAL, отсутствие очистки или долго хранимые данные
- Рост
data_transfer_gb — тяжёлые выборки, отсутствие пагинации
| Слой |
Сценарий |
Что делать |
| Compute |
Много вызовов |
кэш, дедупликация, rate limiting |
| Compute |
Высокий CPU |
профилирование, precompute |
| 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-метрики могут появляться с небольшой задержкой из-за агрегации событий. Для финансовой сверки используйте значения закрытого расчётного периода.