Мониторинг и логи

Что мониторить

Минимальный набор проверок для алертинга:

Проверка	Как	Порог
HTTP доступность	curl -fsS https://<домен>/ -o /dev/null	ответ не 200 / таймаут
Контейнеры живы	docker ps — все сервисы стенда Up, database/redis — healthy	любой контейнер в Restarting/Exited
Диск	df -h на корень и на Docker-каталог	> 80 %
Память	docker stats --no-stream	backend/queue у потолка, OOM-kill в dmesg
Глубина очередей	redis-cli LLEN queues:default / queues:reports	растёт монотонно дольше 10 минут
Срок TLS-сертификата	любой cert-мониторинг	< 14 дней (Traefik продлевает сам — алерт значит, что продление сломано)
Срок лицензии (on-premise)	php artisan license:status	days_left < 30

OOM — главный тихий убийца

PHP-фатал из-за нехватки памяти отдаёт браузеру голый 500 без CORS-заголовков (фронтенд показывает «Network Error») и не пишется в лог Laravel. Если пользователи жалуются на Network Error на конкретной операции, а в laravel.log пусто — смотрите docker logs backend-контейнера (stderr Apache/PHP) и dmesg | grep -i oom. Подробнее — Типовые проблемы.

Логи

Все сервисы пишут в stdout/stderr → docker logs:

docker logs orbita_onpremise_backend -f          # Laravel + Apache/PHP (включая фаталы)
docker logs orbita_onpremise_queue -f            # основная очередь
docker logs orbita_onpremise_queue_reports -f    # экспорт отчётов
docker logs orbita_onpremise_scheduler -f        # регулярные задачи
docker logs orbita_onpremise_traefik -f          # роутинг, ACME/сертификаты
docker logs orbita_onpremise_db -f               # PostgreSQL
docker logs orbita_onpremise_reverb -f           # WebSocket

Лог приложения внутри контейнера — storage/logs/laravel.log:

docker exec orbita_onpremise_backend tail -100 storage/logs/laravel.log

Уровень логирования — LOG_LEVEL в env (error в норме, debug временно при разборе инцидента).

Ротация docker-логов

Настройте ограничение логов Docker (в compose-файлах прод-стендов уже задан json-file с лимитами; для кастомных стендов проверьте logging: или /etc/docker/daemon.json — max-size/max-file), иначе логи со временем съедят диск.

Панель суперадмина как инструмент мониторинга

Если создан суперадмин, в панели /superadmin доступны без SSH:

• Метрики — сводка по стенду и по каждому тенанту (пользователи, записи, активность);
• Error log — просмотр ошибок приложения по датам прямо из браузера;
• Аудит — журнал действий по всем тенантам.

Для дежурного инженера это самый быстрый способ понять «у нас ошибки?» без доступа к серверу.

Healthcheck-и compose

У database и redis в compose определены healthcheck-и; зависимые сервисы стартуют после их готовности. Состояние видно в docker ps (healthy/unhealthy) — unhealthy у БД при живом контейнере обычно означает исчерпание соединений или диска.

Ресурсы по сервисам

docker stats --no-stream

Ориентиры «в норме»:

Сервис	Память
backend	200–500 MB (растёт с числом Apache-воркеров)
queue	100–200 MB
queue-reports	до 512 MB в пике экспорта — это норма
database	сотни MB — зависит от shared_buffers
meilisearch	зависит от объёма индекса (2–5 GB на 1 млн документов)
redis, reverb, frontend, scheduler	десятки MB