Моніторинг

Kept нічого не надсилає про себе нікуди, якщо ви це не налаштуєте: жодної телеметрії взагалі, навіть лічильників встановлень за згодою.

Перевірки працездатності

Шлях	Відповідь
/healthz	200, поки процес обслуговує HTTP. Для перевірки живучості.
/readyz	200, коли відповідають обидва з’єднання бази даних веба, інакше 503. Для перевірки готовності, а також власного HEALTHCHECK образу.
/version	версія, коміт, з якого її зібрано, вихідний репозиторій і де є сторонні повідомлення (/notices.txt, в образі).

Контейнер, що запускає лише воркер (KEPT_ROLE=worker), не обслуговує HTTP. HEALTHCHECK образу залежить від KEPT_ROLE: для воркера він перевіряє, що цикл завдань опитав базу даних протягом останніх двох хвилин (він торкається /tmp/kept-worker-alive під час роботи), тож розділене розгортання не потребує перевизначення healthcheck.

Сторінка статусу і сповіщення

Адміністрування → Статус показує те, що потребує уваги: набір відновлення, пошту, невдалі фонові завдання, сканування нагадувань і резервні копії: вік резервної копії, останнє пробне відновлення, версіонування бакета, місце на диску, випуск і його міграції, перевірка оновлень, HTTPS і конектори. Сповіщення адміністратора доходять до адміністраторів екземпляра в застосунку, поштою та push; кожне зникає, коли усувається його причина.

Метрики

Встановіть KEPT_METRICS_TOKEN, і /metrics віддаватиме текст Prometheus запитам, що надсилають його як bearer-токен (Authorization: Bearer <token>); без змінної шлях не існує. Compose передає змінну з .env.

Метрика	Що
kept_build_info{version, revision}	завжди 1; поточна збірка
kept_process_uptime_seconds	секунд зі старту процесу
kept_process_resident_memory_bytes	пам’ять процесу
kept_db_pool_connections{pool, state}	з’єднання на пул бази даних: усього, вільні, очікують
kept_backup_last_success_timestamp_seconds	коли завершилася остання вдала резервна копія (0 до першої)
kept_backup_last_run_status{status}	1 для стану останнього завершеного запуску, 0 для інших
kept_disk_used_ratio{volume}	наскільки заповнені диск даних і ціль резервного копіювання в каталог
kept_update_available	1, коли перевірка оновлень побачила новіший випуск

Жодна мітка ніколи не містить шляху чи цілі. Якщо база даних не відповідає, рядки резервної копії, диска й оновлення зникають; сам scrape все одно завершується успішно.

Журнали

Рядки JSON у стандартному виводі (KEPT_LOG_FORMAT=json, типово), або pretty для перегляду docker compose logs оком; KEPT_LOG_LEVEL задає рівень. Кожен запит має id, який повертається в заголовку відповіді x-request-id, тож звіт можна зіставити з його рядком журналу. Токени в URL приховуються в журналі, а секрети й паролі ніколи не записуються в журнал.

Трасування і звітування про помилки

Обидва необов’язкові і типово вимкнені.

• Трасування: якщо задано OTEL_EXPORTER_OTLP_ENDPOINT, Kept надсилає траси OpenTelemetry його HTTP-запитів і запитів до бази даних до вашого колектора. Якщо не задано, код трасування взагалі не завантажується, а колектор, що не працює, ніколи не сповільнює запит.
• Звітування про помилки: якщо в KEPT_ERROR_DSN є DSN, сумісний із Sentry, неперехоплені помилки повідомляються з id запиту і маршрутом, а ніколи не з тілом запиту, заголовком, рядком запиту, ім’ям чи чимось, що зберігається в місці зберігання.