Как анализировать логи для выявления причин ошибки 404 в сервисе

Что проверяют

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

Как отвечать

Покажите порядок действий:

• где рождается 404: CDN, балансировщик или nginx, API-шлюз, само приложение (нет маршрута или нет объекта с таким id), роутер SPA на фронтенде. Логи нужны с того уровня, до которого запрос дошёл;
• access-лог веб-сервера: в стандартном формате combined статус это девятое поле, поэтому точнее фильтровать awk '$9 == 404' access.log, чем grep 404, который зацепит и URL, и размер ответа. Топ проблемных адресов: awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -rn | head;
• контекст: время, метод, URL, Referer (откуда пришла битая ссылка), User-Agent (боты, перебирающие /wp-admin, это шум);
• сквозной идентификатор: по X-Request-ID или trace id находите тот же запрос в логах приложения. Если там его нет, проблема в маршрутизации;
• централизованные логи: Kibana или OpenSearch Dashboards, Grafana Loki, kubectl logs в Kubernetes. Фильтр по статусу и сервису, график по времени.

Дальше сопоставьте всплеск с событиями: деплой, смена версии API (/api/v1 на /api/v2), правка Ingress или proxy_pass. Типичные причины: удалённый эндпоинт, опечатка или лишний слеш на клиенте, отрезанный префикс пути в прокси, объект удалён или живёт на другом стенде, SPA без отдачи index.html на неизвестные пути.

В баг-репорт: точный запрос (удобно в виде curl), время, окружение, request id, строка лога и ожидаемый результат.

Где спотыкаются

Считают любой 404 багом. Иногда это корректный ответ на несуществующий объект, а иногда сервис намеренно отдаёт 404 вместо 403, чтобы не раскрывать само существование ресурса.

Смотрят только логи приложения. Если запрос отбил nginx или шлюз, в логах сервиса пусто, и кандидат делает вывод, что запроса вообще не было.

Ищут простым grep по строке «404» и получают мусор, а частоту и распределение по URL не считают, хотя именно паттерн чаще всего указывает на причину.