Ваш застосунок зупинився. Знайдіть першу корисну підказку.

Визначте один спостережуваний збій

«Зупинився» може означати помилку HTTP, тайм-аут, завдання, яке не завершилося, або процес, який завершився. Запишіть один URL або дію, час останньої відомої роботи, час першого збою та ваш часовий пояс. Вкажіть, чи це впливає на всіх, чи лише на одного клієнта. Тримайте поточну сесію SSH відкритою під час дослідження; зміна правил доступу не є необхідною першою відповіддю на помилку застосунку.

Цей посібник передбачає хост Linux з systemd, сервіс застосунку з назвою first-api.service, і локальну кінцеву точку перевірки стану за адресою 127.0.0.1:3000/healthz. Ці значення за замовчуванням відповідають посібнику з першого розгортання API. Замініть їх своїми фактичними назвами. Огляд може вимагати прав адміністратора, щоб бачити процеси або журнали інших користувачів. Команди та виводи нижче є ілюстративними; для цього посібника не тестувався жоден екземпляр провайдера.

Зберігайте нотатки поза власним каталогом застосунку, що збій. Записуйте спостереження перед інтерпретаціями: «з'єднання відхилено о 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.

Якщо модуль відсутній, спершу перевірте його назву та спосіб розгортання. Застосунок, запущений в інтерактивному терміналі, контейнер і служба 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 пояснює фільтри модулів, часу та ядра. Редагуйте токени, дані клієнтів і рядки підключення перед поширенням фрагментів.

Ілюстративний фрагмент з окремого застосунку з функцією завантаження:

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 для фактичної політики.

Завершіть свою нотатку про інцидент симптомом, першою корисною підказкою, зробленою зміною та результатом перевірки. Якщо причина залишається невизначеною, повідомте про цю невизначеність із відредагованими доказами, а не називайте тимчасовий перезапуск постійним виправленням. Покращте контрольний список випуску за допомогою перевірки, яка виявила б цю помилку раніше.