Проверить состояние и журналы

Состояние healthy означает, что техническая проверка прошла. Оно не подтверждает права пользователей, отправку писем или правильность процессов.

Эта статья для того, у кого есть доступ к серверу. Если вы обычный пользователь, запишите время ошибки, адрес страницы и действие перед ошибкой и передайте администратору. Не просите пароль от сервера только ради проверки одной заявки.

С чего начать, если «ничего не работает»

1. Уточните масштаб: не открывается весь сайт или только одно действие у одного сотрудника. Во втором случае начните с проверки доступа, а не с перезапуска сервера.
2. Убедитесь, что подключились к нужному серверу и открыли каталог действующего комплекта. DEV, STAGE и рабочий сайт — разные системы.
3. Выполните команды чтения состояния и последних журналов ниже. Сначала соберите признаки ошибки; перезапуск может скрыть важную последовательность событий.
4. Сопоставьте время сбоя с журналом приложения. Если интерфейс или API показал correlationId, приложите его к обращению сопровождающему: это идентификатор конкретного запроса.
5. После исправления повторите именно неработавшее действие под нужной ролью. Одна зелёная проверка контейнера ещё не означает, что проблема пользователя исчезла.

Быстрая проверка

Если сайт открывается и вы вошли как Superuser, откройте Настройки платформы → Настройка системы → Администрирование → Состояние системы и нажмите Обновить показатели. Смотрите время последней проверки: данные не обновляются непрерывно. Этот экран помогает начать диагностику без SSH, но не проверяет автоматически все фоновые обработчики.

Реальный экран NGENSIA 0.9 на учебных данных. Сообщение о связи с базой не означает, что проверена доставка почты или весь рабочий процесс.

Реальный экран NGENSIA 0.9 на учебных данных. Сообщение о связи с базой не означает, что проверена доставка почты или весь рабочий процесс.

Команда из каталога deploy	Результат
sh ngensia.sh status	Показывает состояние контейнеров, ничего не останавливает
sh ngensia.sh start	Запускает PostgreSQL и приложение, применяя подготовленную конфигурацию; не включает внешний proxy
sh ngensia.sh stop	Останавливает приложение и PostgreSQL, но оставляет proxy работающим

Согласуйте перерыв перед stop: пользователи потеряют доступ, а оставшийся proxy может отвечать ошибкой. Не используйте эту команду перед резервным копированием: ему нужна работающая база. В сценариях, где требуется остановить только приложение, используйте указанную там команду docker compose … stop app, не полную остановку. Отдельной команды restart в оболочке нет.

Из каталога действующего комплекта:

sh ngensia.sh status
docker compose --env-file .env -f compose.yml exec -T app node deploy/healthcheck.mjs
docker compose --env-file .env -f compose.yml logs --tail 100 app
docker compose --env-file .env -f compose.yml logs --tail 100 postgres

При S3 в ручные Compose-команды добавьте -f compose.s3.yml. Публичный адрес /health/ready закрыт штатным прокси; внешний 404 на нём не означает отказ приложения.

Что проверить после изменения

1. HTTPS и вход.
2. Открытие доступной карточки.
3. Поиск известной записи.
4. Скачивание старого вложения.
5. Затронутый рабочий сценарий от нужной роли.
6. Состояние фоновых обработчиков и очередей.

Если запуск не завершился

Проверьте digest образа, соединение с PostgreSQL, результаты миграций, место на диске и доступ к файлам/секретам. Не создавайте вручную маркеры завершения установки и не удаляйте базу «для повторной попытки».

В комплекте журналы Docker ограничены размером и количеством файлов. Это ротация, а не централизованный мониторинг. Настройте отдельно контроль доступности, диска, памяти, срока сертификатов и возраста успешной внешней копии.

Перед передачей журнала

Удалите секреты и персональные данные из копии для поддержки. Не публикуйте полные дампы и содержимое runtime.

Обновление · Обработчики · Аварийное восстановление