Разбор access-лога nginx для диагностики Битрикс: коды ответа, URL и источники

Зачем смотреть access.log рядом с Битрикс

В типичном контуре «nginx → php-fpm → Битрикс» большинство симптомов сначала отражается в access-логе: всплески 502/504, массовые 404 к несуществующим .php, аномально длинные ответы по байтам. Пара минут аккуратного разреза по логу часто экономит час ручной рыскани по конфигам и дампам сессий.

Дефолтная строка access

Часто включён именно классический шаблон, который задаёт переменными вида:

$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"

Смысл полей вкратце: IP клиента и (редко заполненный) пользователь по HTTP Basic; локальное время сервера; целиком метод, путь с query и версия протокола; код ответа; сколько байт отдали после заголовков; заголовки Referer и User-Agent как строки в кавычках.

Разбор утилитами удобнее вести, зная номер столбца: в простой конфигурации без лишних полей код ответа обычно оказывается девятым токеном в первой группе; для сложных log_format сначала выведите одну строку и сверьтесь со справкой к своей схеме.

Частота HTTP-кодов

Общую картину по всему файлу можно получить простым счётчиком по полю статуса. Ниже вариант, который режет статус после третьего кавычечного блока (подходит к дефолтному порядку полей выше):

cat access.log | cut -d '"' -f3 | cut -d ' ' -f2 | sort | uniq -c | sort -rn

Альтернатива тем же столбцом №9 напрямую по пробелам, если ваш формат на это натянут один в один:

awk '{ print $9 }' access.log | sort | uniq -c | sort -rn

Высокий хвост 4xx при нормальном основном массиве 300 часто связан со сканерами или битыми закладками в шаблонах; рост 5xx почти всегда требует пары строк из error.log и метрик времени upstream к php-fpm.

Что именно ломалось: топ URL по коду

Чтобы увидеть, какие адреса чаще всего получили, скажем, 404:

awk '($9 ~ /404/) { print $7 }' access.log | sort | uniq -c | sort -rn

По аналогии подставляйте свой код 502/499 и сравнивайте время с деплоем, перезапуском пула и длительными агентами Битрикс. Для углубленной проверки «кто бил по одному экзотическому скрипту» обычно проще перейти к разбору с разделителем по кавычкам и вытащить первый столбец (IP) из совпадающих строк.

Подозрительные пробои к интерпретируемым путям

Многочисленные 404 на пути вида /bitrix/-чужие или произвольные .php-инсталлеры типично относятся к роботизации, не к контент-плану. Осмысленный фильтр по GET к PHP можно собрать на awk с проверкой поля запроса внутри второй группы между кавычками; имеет смысл ограничивать вывод head, чтобы не раздувать отчёт.

Связка с error-log и конфигурацией

Полезный минимальный чеклист: совпадает ли пик ошибок во времени с ротацией логов, рестартом контейнеров или пиком тяжёлых AJAX-методов сайта; не задвоились ли server_name и блоки для статики так, что часть запросов уходит в «пустой» backend; включён ли нормализованный log_format на все виртуальные хосты, где нужна единая аналитика. Идея разборочных фильтров хорошо описана в классических материалах по nginx (в той же логике, что использовали коллеги при разборе парсинга логов), мы пересказали и сместили упор под эксплуатацию проектов на «1С-Битрикс».