Логи веб-сервера Битрикс: как найти причину ошибки по времени и связать с событием
Чтобы найти причину сбоя по жалобе «в 14:20 упало», нужно сопоставить три источника: логи веб-сервера, лог ошибок PHP и журнал ошибок Битрикс. Сначала фиксируем точное время и часовой пояс, затем ищем запросы в узком интервале, сверяем коды ответов и сообщения, после чего строим таблицу «время / запрос / код / сообщение / что проверить». Такой порядок даёт проверяемую версию причины и следующий шаг, а не догадку.
Что именно ищем и в каких границах работаем
Задача диагностики — по конкретной жалобе пользователя или руководителя восстановить цепочку событий на сервере. Обычно формулировка звучит так: «в 14:20 сайт не открывался», «в 14:20 не прошла оплата», «в 14:20 пропала корзина». Наша цель — не «посмотреть логи вообще», а найти записи, относящиеся к этому моменту, и связать их с наблюдаемым симптомом. Логи веб-сервера, на котором работает Битрикс, — не один файл, а набор источников, которые нужно читать вместе.
Границы задачи важно зафиксировать до начала работы. Мы занимаемся диагностикой: собираем доказательства, строим версии, предлагаем варианты исправления. Мы не меняем уровень логирования на проде без письменного согласования, не запускаем нагрузочные тесты на боевом контуре и не правим конфигурацию сервера «по ходу». Если для проверки версии нужно временно повысить детализацию логов, это отдельное согласованное действие с планом возврата.
Отдельно проговорим, что диагностика не равна устранению. Найти причину и починить её — разные объёмы. Иногда причина очевидна и правка локальна, иногда требуется аудит кода Битрикс или более широкий технический аудит сайтов на 1С-Битрикс. В отчёте мы честно разделяем: что подтверждено логами, что является гипотезой, а что требует отдельной проверки.
Ещё одна граница — персональные данные. В логах могут оказаться IP, идентификаторы пользователей, фрагменты запросов. Мы не публикуем их в открытых документах и не передаём третьим лицам без основания. Если в записях есть персональные данные, порядок работы согласуется с профильным специалистом.
Исходные данные, роли и точки входа
Прежде чем открывать файлы, соберите минимальный набор входных данных. Без них поиск превращается в перебор.
- Точное время жалобы с часовым поясом. «14:20» без пояса бесполезно, если сервер живёт в UTC, а пользователь — в Москве.
- Симптом: что именно не работало. Ошибка 500, белый экран, зависшая страница, отказ оплаты, пустая корзина.
- Идентификаторы: URL страницы, номер заказа, логин или ID пользователя, если он есть.
- Период: не только минута жалобы, но и 5–10 минут до и после.
- Доступы: к логам веб-сервера, к логу PHP, к административной панели Битрикс, к журналу ошибок.
Роли распределяются так. Заказчик или руководитель проекта даёт симптом и время, согласует действия на проде. Администратор сервера или DevOps предоставляет доступ к логам и отвечает за инфраструктуру. Разработчик читает записи, строит версии и предлагает правки. Ответственный за итог — тот, кто собирает отчёт и следит, чтобы версии были проверены, а не просто перечислены.
Точки входа различаются. Логи веб-сервера обычно лежат на сервере и содержат строки о каждом запросе: время, метод, URL, код ответа, размер, иногда время обработки. Лог ошибок PHP — отдельный файл, куда попадают предупреждения и фатальные ошибки. Журнал ошибок Битрикс доступен из административной панели и хранит сообщения уровня платформы. Эти три источника дополняют друг друга, и ни один из них не является полным в одиночку.
Как выбрать источник и не утонуть в файлах
У каждого источника своя зона ответственности. Выбор зависит от симптома и от того, что уже известно.
Если сайт отдавал ошибку 500 или 502, начинайте с логов веб-сервера: там видно, что запрос дошёл до сервера и с каким кодом завершился. Если код 500, дальше смотрим лог PHP — там может быть сообщение об ошибке. Если код 502 или 504, проблема может быть на уровне связи веб-сервера и обработчика, и тогда лог PHP может быть пуст. Если пользователь видит белый экран без текста, чаще всего это фатальная ошибка PHP, и её нужно искать в логе PHP, а не в журнале Битрикс.
Журнал ошибок Битрикс полезен, когда сбой связан с логикой платформы: ошибки модулей, агентов, обмена, почтовых событий. Он не заменяет лог PHP, потому что часть ошибок возникает до инициализации платформы или вне её обработчиков.
Критерии выбора источника удобно свести в таблицу решений. Она помогает не открывать все файлы подряд, а идти по симптомам.
| Симптом | Первый источник | Что искать | Когда переходить дальше |
|---|---|---|---|
| Ошибка 500 на странице | Логи веб-сервера | Строку запроса с кодом 500 в нужную минуту | Если код есть, открыть лог PHP за ту же минуту |
| Белый экран без текста | Лог ошибок PHP | Фатальную ошибку с временем рядом с жалобой | Если пусто, проверить, куда пишет PHP, и журнал Битрикс |
| Отказ оплаты или вебхука | Логи веб-сервера и журнал Битрикс | Запросы к обработчику оплаты и сообщения модуля | Если запрос есть, а ответа нет, смотреть таймауты и лог PHP |
| Зависшая страница | Логи веб-сервера | Долгое время обработки и код 504 | Если время большое, искать тяжёлый запрос и лог медленных запросов |
| Ошибка только у одного пользователя | Логи веб-сервера и журнал Битрикс | Запросы с его ID или сессией | Если запросы успешны, проверять права и данные пользователя |
Такой подход экономит время и снижает риск, что вы будете читать гигабайты записей без цели.
Пошаговый разбор: от жалобы до записи в логе
Начните с фиксации времени. Переведите жалобу в часовой пояс сервера. Если сервер в UTC, а жалоба в 14:20 по Москве, ищите в 11:20 UTC. Ошибка в поясе — самая частая причина «в логах ничего нет».
Затем определите окно поиска. Возьмите минуту жалобы и добавьте по 5–10 минут с каждой стороны. Это покроет разницу часов, задержку записи и повторные попытки.
Откройте логи веб-сервера и отфильтруйте строки по времени. Ищите коды 4xx и 5xx, а также запросы к подозрительным URL. Если жалоба про конкретную страницу, сузьте выборку по её адресу. Если про оплату — по адресу обработчика платежей.
Для найденных строк зафиксируйте: время, метод, URL, код ответа, время обработки, идентификатор пользователя или сессии, если он есть. Эти поля станут основой таблицы.
Если код 500, откройте лог PHP и найдите сообщение с временем в том же окне. Сообщение может быть коротким или содержать стек вызовов. Стек полезен, но не всегда указывает на корень: ошибка может возникать в одном месте, а причина — в данных или в конфигурации. Обратите внимание, что в логах веб-сервера время может отличаться от времени PHP из-за задержек обработки.
Сверьтесь с журналом ошибок Битрикс. Иногда там есть запись, которой нет в логе PHP, и наоборот. Совпадение по времени и смыслу усиливает версию.
Соберите таблицу «время / запрос / код / сообщение / что проверить». Каждая строка — это факт плюс следующий шаг. Такая таблица становится основой отчёта и позволяет вернуться к разбору позже без повторного чтения логов.
Таблица сопоставления: время, запрос, код, сообщение, что проверить
Ниже — шаблон, который заполняется по результатам поиска. Он не заменяет отчёт, но делает его проверяемым.
| Время (по серверу) | Запрос | Код | Сообщение | Что проверить |
|---|---|---|---|---|
| 14:19:58 | POST /local/ajax/order.php | 500 | PHP Fatal error: Allowed memory size exhausted | Настройки памяти, размер данных в запросе, объём выборки |
| 14:20:01 | GET /catalog/ | 200 | — | Время обработки, кеш, количество запросов к базе |
| 14:20:03 | POST /bitrix/services/main/ajax.php | 500 | Ошибка модуля обмена | Доступность внешнего сервиса, таймауты, журнал модуля |
| 14:20:07 | GET /personal/order/ | 302 | — | Куда ведёт редирект, права пользователя, сессия |
| 14:20:12 | POST /local/ajax/payment.php | 504 | — | Время ответа внешнего шлюза, настройки таймаута, лог PHP |
Заполняйте таблицу только подтверждёнными данными. Если поле неизвестно, оставьте пометку «требует проверки», а не догадку. Это дисциплинирует разбор и защищает от ложных выводов.
Учебный пример: жалоба «в 14:20 упало»
Учебный пример. Компания «Условный сервис» получает жалобу: в 14:20 по московскому времени пользователи не смогли оформить заказ. Сервер работает в UTC. Доступны логи веб-сервера, лог PHP и журнал ошибок Битрикс. Ответственный — администратор сервера, разработчик помогает с чтением записей.
Шаг 1. Переводим время: 14:20 МСК — это 11:20 UTC. Окно поиска: 11:15–11:25 UTC.
Шаг 2. В логах веб-сервера находим несколько запросов с кодом 500 в 11:19:58 и 11:20:03. Один из них — POST на /local/ajax/order.php, другой — POST на /bitrix/services/main/ajax.php.
Шаг 3. В логе PHP за 11:19:58 видим сообщение о нехватке памяти. За 11:20:03 — сообщение об ошибке модуля обмена.
Шаг 4. В журнале ошибок Битрикс за 11:20:03 есть запись об ошибке обмена с внешним сервисом.
Шаг 5. Строим таблицу и версии. Версия первая: нехватка памяти при оформлении заказа. Версия вторая: сбой обмена, который мог повлиять на доступность данных. Версия третья: сочетание — обмен создал нагрузку, из-за чего выросло потребление памяти.
Шаг 6. Проверка. Смотрим, повторялась ли ошибка памяти в другие дни. Проверяем, был ли обмен в то же время. Смотрим, сколько запросов пришло в интервале. Если ошибка памяти единична и совпадает с пиком запросов, версия усиливается. Если обмен падал регулярно, но жалоб не было, его роль вторична. Важно: не путайте корреляцию с причиной, проверьте влияние каждого фактора отдельно.
Наблюдаемый результат: подтверждена ошибка памяти в момент жалобы, зафиксирована сопутствующая ошибка обмена, составлена таблица и список проверок. Решение по исправлению — отдельный шаг, который согласуется с заказчиком. В учебном примере данные условны и не являются статистикой.
Типичные ошибки при чтении логов
Первая ошибка — игнорировать часовой пояс. Если сервер в UTC, а вы ищете по местному времени, нужная строка не найдётся, и вы сделаете ложный вывод «в логах пусто».
Вторая ошибка — читать логи без окна. Открыть файл за весь день и листать — значит потратить часы и пропустить важное. Всегда задавайте интервал.
Третья ошибка — считать, что журнал Битрикс заменяет лог PHP. Это разные источники, и ошибка может быть только в одном из них.
Четвёртая ошибка — делать вывод по одной строке. Один код 500 без сообщения и контекста ничего не доказывает. Нужны время, запрос, сообщение и проверка.
Пятая ошибка — менять уровень логирования на проде без согласования. Это может повлиять на производительность и на объём данных. Сначала копия, резервирование, тест и план возврата.
Шестая ошибка — путать корреляцию и причину. Два события в одну минуту могут быть не связаны. Проверяйте повторяемость и влияние.
Чек-лист приёмки диагностики
- Зафиксировано точное время жалобы и часовой пояс сервера
- Определён симптом и затронутый сценарий
- Собраны доступы к логам веб-сервера, PHP и журналу Битрикс
- Задан интервал поиска с запасом до и после жалобы
- Найдены строки запросов с кодами 4xx и 5xx в интервале
- Для каждой строки выписаны время, запрос, код, сообщение
- Сверены записи лога PHP и журнала ошибок Битрикс
- Составлена таблица «время / запрос / код / сообщение / что проверить»
- Версии причины разделены на подтверждённые и гипотезы
- Указан следующий шаг по каждой версии
- Изменения на проде не выполнялись без согласования
- Персональные данные не раскрыты в отчёте
Ограничения, риски и следующий шаг
Диагностика по логам имеет ограничения. Логи могут быть неполными, если запись настроена частично или файлы ротируются. Сообщения об ошибках не всегда указывают на корень. Время в разных источниках может отличаться из-за настроек. Часть событий вообще не попадает в логи: например, проблемы на стороне клиента или внешнего сервиса.
Риски при работе с логами — это нагрузка на прод при чтении больших файлов, изменение уровня логирования без плана возврата, раскрытие персональных данных. Поэтому любые действия, влияющие на боевой контур, выполняются после согласования и с резервной копией.
Следующий шаг после диагностики — решение по исправлению. Оно может быть локальным или требовать более широкого разбора. Если причина связана с кодом, полезно посмотреть аудит кода Битрикс. Если нужно оценить проект целиком, подойдёт аудит сайта на Битрикс. Если встаёт вопрос о компетенциях команды, пригодится материал про собеседование Битрикс-разработчика.
Что делать, если в логах нет записей за время жалобы?
Проверьте часовой пояс сервера и окно поиска. Убедитесь, что логи вообще пишутся и не ротировались. Если записей нет, проверьте, не отключено ли логирование и куда направлены сообщения.
Чем отличаются логи веб-сервера, PHP и Битрикс?
Логи веб-сервера фиксируют запросы и коды ответов. Лог PHP содержит ошибки и предупреждения интерпретатора. Журнал Битрикс хранит сообщения платформы и модулей. Они дополняют друг друга.
Можно ли включать подробное логирование на проде?
Только после согласования, с оценкой влияния на производительность и объём данных. Сначала копия, резервирование, тест и план возврата. Помните, что избыточное логирование может замедлить работу сайта.
Как понять, что причина найдена, а не просто совпала по времени?
Нужно проверить повторяемость, влияние на сценарий и связь между записями. Совпадение по времени — это версия, а не доказательство. Ищите причинно-следственные связи, а не только временные совпадения.
Кто должен отвечать за разбор логов?
Обычно администратор сервера или DevOps предоставляет доступ и данные, разработчик читает записи и строит версии, руководитель проекта согласует действия и принимает отчёт.
Что делать после того, как причина найдена?
Зафиксировать доказательства, согласовать объём исправления и выполнить его отдельно от диагностики. Если нужно, провести более широкий аудит.
Практический разбор: сопоставление логов по времени жалобы
Учебный разбор. Условная задача: на тестовом контуре сайта на 1С-Битрикс при обращении к странице каталога в 14:20 пользователь получил ответ 500. Известны: точное время 14:20 и часовой пояс сервера, URL страницы каталога, имя тестового пользователя. Вводные правила: логи веб-сервера, лог ошибок PHP и журнал ошибок Битрикс включены и хранятся за нужные сутки; доступ к ним только на чтение.
| Действие | Что проверить |
|---|---|
| Зафиксировать окно поиска: 14:19–14:21 по часовому поясу сервера и отобрать в логе веб-сервера записи по URL страницы каталога за это окно. | Находим одну или несколько строк с этим URL и кодом ответа 500, видим время запроса и IP. |
| Сопоставить время найденного запроса с записями в логе ошибок PHP и журнале ошибок Битрикс в том же окне. | Находим запись с тем же временем: сообщение об ошибке PHP или запись журнала Битрикс, указывающая на конкретный файл или модуль. |
| Проверить версию причины: повторно открыть ту же страницу каталога на тестовом контуре под тестовым пользователем и снова сверить три источника. | Если симптом повторяется, в логах появляется новая запись с тем же сообщением; если нет — фиксируем, что причина зависит от условий, и это отдельная гипотеза. |
Для приёмки. Таблица «время / URL / код ответа / сообщение / что проверить» с выдержками из трёх источников за окно 14:19–14:21 и указанием, какая запись подтверждает версию, а какая остаётся гипотезой.
Ограничение. Разбор применим, когда логи включены и сохранились за нужные сутки; он не заменяет устранение причины и не покрывает случаи, когда запись отсутствует из-за переполнения или ротации логов.
