Как агент диагностирует сервер

Хороший агент не угадывает. Он идёт по тому же пути, что и опытный админ: сначала выясняет, что сломалось, потом — почему, и только потом предлагает исправление. Ваша задача — следить, чтобы он не перепрыгивал через шаги.

Шаг 1. Что видит пользователь

Начинаем с симптома, а не с догадок. Если жалоба «сайт не открывается», первым делом стоит проверить, что именно отвечает сервер:

curl -I http://localhost

Ответ 502 Bad Gateway и ответ Connection refused — это две разные поломки. В первом случае веб-сервер работает, но не может достучаться до приложения. Во втором — веб-сервер вообще не слушает порт.

Шаг 2. Статус сервиса

Дальше — состояние сервиса и его последние сообщения:

systemctl status nginx
journalctl -u nginx -n 20 --no-pager

systemctl status скажет, запущен ли сервис и с каким кодом он упал. journalctl покажет последние строки лога — там обычно и лежит настоящая причина.

Шаг 3. Проверка конфигурации

Если сервис не стартует, следующий шаг — проверить конфиг. У nginx для этого есть отдельная команда:

nginx -t

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

Шаг 4. Исправление — минимальное

Когда причина найдена, исправление должно быть минимальным: поменять одну строку, а не переписать весь конфиг. И после каждого изменения — снова проверка:

nginx -t && systemctl reload nginx

Признаки, что агент идёт не туда

• Предлагает переустановить пакет, ещё не посмотрев логи.
• Меняет несколько вещей сразу — потом не понять, что помогло.
• Перезапускает сервис «на всякий случай», не найдя причину.
• Объясняет вывод, которого не было в терминале.

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

Дальше — лаба: сайт не открывается, а вы с агентом ищете причину и чините так, чтобы сайт поднимался и после перезагрузки.