Ваше приложение остановилось. Найдите первую полезную подсказку.

Определите один наблюдаемый сбой

«Остановилось» может означать ошибку HTTP, тайм-аут, незавершённое задание или процесс, который завершился. Запишите один URL или действие, его последнее известное рабочее время, время первого сбоя и ваш часовой пояс. Укажите, затронуты ли все или только один клиент. Держите текущую сессию SSH открытой во время исследования; изменение правил доступа не является необходимым первым ответом на ошибку приложения.

Это руководство предполагает хост Linux с systemd, службой приложения с именем first-api.service, и локальной конечной точкой проверки работоспособности по адресу 127.0.0.1:3000/healthz. Эти значения по умолчанию соответствуют руководству по первому развёртыванию API. Подставьте свои фактические имена. Для проверки может потребоваться разрешение администратора, чтобы видеть процессы или журналы других пользователей. Команды и выводы ниже приведены для иллюстрации; ни один экземпляр провайдера не тестировался для этого руководства.

Храните заметки вне собственного каталога сбойного приложения. Записывайте наблюдения до интерпретаций: «connection refused в 09:18 UTC» — это факт; «VPS нуждается в большем количестве CPU» — всё ещё гипотеза. Если сам сервер недоступен, используйте установленный у вас доступ для восстановления и соберите сведения о подключении, а не предполагайте, что перезапуск приложения возможен.

Прочитайте состояние процесса и его недавнюю историю

systemctl status first-api.service --no-pager --full
systemctl show first-api.service -p ActiveState -p SubState -p Result -p ExecMainStatus -p NRestarts

Представление статуса описывает текущий или последний вызов и включает недавние сообщения журнала. Выбранные свойства дают компактную запись для последующего сравнения. Состояние отказа или растущее число перезапусков заслуживает расследования; активный процесс всё ещё требует проверки запросом. Это разные проверки, как описано в upstream-справке по systemctl.

Если unit отсутствует, сначала проверьте его имя и способ развёртывания. Приложение, запущенное в интерактивном терминале, контейнер и служба systemd имеют разных владельцев и журналы. Немедленное создание новой службы может оставить две копии, конкурирующие за один порт. Определите существующую конфигурацию, прежде чем её менять.

Проверьте слушателя и сделайте локальный запрос

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

Найдите ожидаемые адрес и порт, затем определите владеющий процесс. Процесс, слушающий другой порт, может быть работоспособен, но недоступен через настроенный прокси. Другой процесс мог занять ожидаемый порт. руководству по ss определяет параметры слушателя и процесса.

Если локальный запрос работает, а публичный запрос по HTTPS завершается ошибкой, продолжайте проверки через DNS, TLS и прокси. Если слушатель отсутствует, изучите сбой запуска. Если соединение устанавливается, но приложение возвращает ошибку, исследуйте этот маршрут и его зависимости. Curl без --fail может успешно завершиться при ошибочном HTTP-ответе, поэтому читайте ответ, а не полагайтесь только на код выхода. См. параметры ответа и ошибок curl.

Читайте вокруг первого сбоя, а не только последнюю строку

sudo journalctl -u first-api.service --since "30 minutes ago" --no-pager -n 100
sudo journalctl -k --since "30 minutes ago" --no-pager -n 100

Первый запрос выбирает службу; второй выбирает сообщения ядра. Настройте интервал так, чтобы в него попали последний работающий запрос и изменение, предшествовавшее сбою. Доступ и срок хранения определяют, что осталось доступным. upstream-справке по journalctl объясняет фильтры по unit, времени и ядру. Перед публикацией фрагментов удалите токены, данные клиентов и строки подключения.

Иллюстративный фрагмент из отдельного приложения с функцией загрузки:

09:18:03 field-api: opening upload directory
09:18:03 field-api: EACCES: permission denied, open '/var/lib/field-api/uploads/index.json'
09:18:03 field-api: startup aborted

Это указывает на доступ пользователя службы к конкретному пути. Сверьте владельца файла и родительского каталога с инструкциями по выпуску. Не предоставляйте широкий доступ на запись ко всей файловой системе. Более позднее сообщение прокси «upstream unavailable» было бы следствием в этом сценарии, поэтому починка прокси сначала упустила бы причину.

Сравните ресурсы с самым последним релизом

free -h
df -h / /opt/first-api
df -i / /opt/first-api

Эти снимки помогают выяснить, совпали ли со сбоем нехватка памяти, места в файловой системе или inode. Их интерпретация относится к руководству по памяти и диску; одно показание с высокой занятостью не устанавливает причину. Служба также может достичь собственного лимита ресурсов, когда у остальной части хоста есть запас.

Сравните идентификатор развёрнутого выпуска, команду запуска, имена необходимых переменных окружения и пути к данным с последним работающим выпуском. Не выгружайте секретные значения переменных окружения в отчёт. Ищите переименованный каталог, отсутствующую зависимость среды выполнения, изменение порта или несовместимую миграцию базы данных. Укажите, что изменилось и что ошибка предсказывает вам найти.

Внесите одно обоснованное исправление и проверьте восстановление

Выберите минимальное исправление, подкреплённое доказательствами. Для иллюстративного отказа доступа это означает восстановление предполагаемого доступа для учётной записи службы, затем одну контролируемую попытку запуска. Если вместо этого вы используете известный рабочий выпуск кода, сначала установите, остаётся ли совместимой его схема базы данных. Откат кода не может автоматически отменить миграцию данных.

После исправления повторите те же проверки службы, локальной конечной точки и публичного запроса. Убедитесь, что представительное действие приложения работает, новые ошибки прекратились, а процесс остаётся стабильным при следующей обычной нагрузке. Политики перезапуска могут помочь восстановить процесс, но не делают постоянно сломанную программу работоспособной; обратитесь к справке по службам systemd для фактической политики.

Завершите заметку об инциденте симптомом, первой полезной зацепкой, внесённым изменением и результатом проверки. Если причина остаётся неясной, сообщите об этой неопределённости с отредактированными доказательствами, а не называйте временный перезапуск постоянным исправлением. Улучшите контрольный список выпуска проверкой, которая поймала бы этот сбой раньше.