Метрики та журнали
Дивіться, що робить ваш застосунок просто зараз і що він робив годину, добу чи тиждень тому, — без встановлення будь-чого.
Вкладка «Метрики»#
Оберіть 1 год, 24 год або 7 дн. З одних і тих самих вибірок будуються два графіки:
- Навантаження CPU — частка CPU, яку використав контейнер;
- Пам'ять — резидентна пам'ять у байтах.
Область проєкту охоплює контейнер застосунку проєкту (app-<slug>); область user:<alias> додає всі контейнери на ваших демонах застосунків і баз даних. У щойно створеного контейнера історії ще немає — вкладка показує У цьому діапазоні ще немає даних.
Як збираються числа#
Збирач щоп'ятнадцять секунд опитує кожен демон про статистику кожного контейнера й зберігає її в базі даних платформи. Для довгих діапазонів використовуються погодинні агрегати, щоб графіки лишалися легкими.
| Дані | Термін зберігання (типово) |
|---|---|
| сирі вибірки (15 с) | 14 днів |
| погодинні агрегати | 90 днів |
Адміністратори можуть змінити обидва значення на сторінці Платформа → Налаштування (Зберігати сирі метрики, днів, Зберігати погодинні метрики, днів).
Через REST і MCP#
curl -fsS "$BASE/api/v1/metrics?scope=project:$PID&range=24h" -H "Authorization: Bearer $TOKEN"
# MCP: get_metrics(scope="project:7", range_key="24h")
scope — це project:<id>, user:<alias> (ваш власний або будь-який, якщо ви адміністратор) чи global (лише для адміністратора). range — це 1h, 24h або 7d; роздільну здатність обирає сервер.
Журнали#
| Журнал | Де | Примітки |
|---|---|---|
| Журнал збірки | вкладка «Розгортання» → Журнал збірки | виводиться наживо під час збірки, потім зберігається; перші рядки з # розповідають, що вирішила платформа |
| Журнал застосунку | вкладка «Застосунок» → Стежити за журналом, get_logs, GET …/logs |
stdout і stderr контейнера застосунку; хвіст до 5000 рядків або потік у реальному часі |
| Журнал бази даних | не показується | скористайтеся SQL-консоллю та статусом бази даних |
Журнали ротуються
Docker зберігає журнал кожного контейнера як набір файлів із ротацією: типово 2 файли по 25 МБ — не більше 50 МБ. Балакучий застосунок не заповнить диск, але збережуться лише найновіші рядки; усе, що потрібно зберегти, надсилайте у власний сервіс журналювання або в S3.
Журнал аудиту#
Кожна дія, що змінює стан, — створення проєкту, розгортання, перестворення, задання змінної, додавання домену, створення резервної копії, відновлення, створення чи відкликання токена — залишає запис аудиту: хто, що і над яким об'єктом. Кожне виконання в SQL-консолі також залишає запис у журналі запитів. Значення секретів не потрапляють ні в той, ні в інший.
Для операторів
Обидва журнали зберігаються в базі даних платформи (audit_log, query_log). Сторінки аудиту в консолі поки що немає; оператори читають журнали через SQL — див. Експлуатація.
Огляд усієї платформи (для адміністраторів)#
Пункт Метрики у верхній панелі показує всі контейнери з даними (навантаження CPU та пам'ять, останні значення) і підсумок за користувачами: кількість демонів, сумарне навантаження CPU й сумарна пам'ять — найшвидший спосіб побачити, хто використовує хост. Див. Адміністрування.