Анализ логов ошибок 1С-Битрикс: видим полную картину проблем по журналам

Каждый сайт на 1С-Битрикс ведёт подробный дневник: что произошло, когда, с какой ошибкой и при каком запросе. Этот дневник пишется автоматически, круглосуточно и без приукрашиваний — в нём нет места ощущениям вроде кажется, всё нормально или вроде стало быстрее. Парадокс в том, что владельцы сайтов почти никогда в этот дневник не заглядывают, а когда заглядывают, видят стену непонятных строк и закрывают. В результате сайт честно рассказывает о своих болезнях, а его не слушают. Анализ логов — это умение услышать. Ниже разбираем, почему по логам видно то, чего не видно иначе, и как мы превращаем гигабайты записей в понятную карту проблем.

Почему белый экран и код 500 ничего не объясняют

Когда сайт падает, пользователь видит белый экран или короткое сообщение об ошибке 500. Это вершина айсберга: за ней может стоять что угодно — фатальная ошибка PHP, исчерпание памяти, таймаут базы, сегфолт, недоступный сервис, конфликт модулей. Сам по себе код 500 не различает эти случаи, поэтому по нему нельзя чинить. А вот логи различают. В php error_log будет точное сообщение и файл, если упал код. В журнале nginx будет запись о таймауте, если бэкенд не ответил вовремя. В slow query log окажется запрос, который не уложился в лимит. Прочитав эти журналы вместе и сопоставив по времени, мы превращаем безликую пятисотую ошибку в конкретный диагноз.

Именно поэтому первый шаг анализа — собрать все источники, а не смотреть в один файл. Очень частая ошибка самостоятельного разбора: открыли php error_log, ничего не нашли и решили, что ошибки нет. На деле причина была в журнале сервера или базы, куда никто не заглянул. Полная картина рождается только на стыке журналов.

Шум против сигнала: почему важное тонет

Главная сложность работы с логами — не нехватка данных, а их избыток. Активный сайт за сутки пишет тысячи строк, и большая часть из них — повторяющийся фоновый шум: одни и те же notice от какой-нибудь доработки, рутинные предупреждения, штатные сообщения. Опасная фатальная ошибка может встретиться в этом потоке всего раз, и найти её глазами почти невозможно. Поэтому мы не читаем лог построчно, а агрегируем: свёртываем одинаковые сообщения в группы по сигнатуре и считаем частоту каждой. Тысячи строк превращаются в короткий список из нескольких десятков паттернов, отсортированных по тому, как часто и как давно они появляются. Сразу видно, что повторяется постоянно, что нарастает и что появилось недавно. Шум уходит на дно, а сигнал всплывает наверх.

Корреляция по времени: где прячутся скрытые причины

Самые коварные проблемы не видны в одном журнале — они проявляются как совпадение событий в разных. Пятисотые ошибки, которые случаются каждый раз, когда запускается тяжёлый агент. Обрыв обмена с 1С, который совпадает с пиком трафика. Тормоза, которые наступают ровно при блокировке таблицы в базе. По отдельности каждый журнал показывает невинную запись, и только сведённые на одной временной шкале они выдают причину. Поэтому мы выстраиваем события из php, веб-сервера, базы, ядра Битрикса и обмена по общему времени и ищем устойчивые совпадения. Когда всплеск ошибок раз за разом ложится на одно и то же событие, это уже не случайность, а паттерн — и его можно закрыть. Если разбор показывает, что корень в обмене данными, дальше точечно помогает направление исправление ошибок обмена с 1С, где причина устраняется уже по готовому диагнозу.

Тормоза без ошибок: работа для slow query log

Особый класс проблем — когда сайт медленный, но в обычных логах чисто. Ошибок нет, страница просто грузится десять секунд или периодически отдаёт 500 под нагрузкой. Виновник почти всегда в базе, и виден он в slow query log — журнале медленных запросов. Там оказываются выборки без индексов, тяжёлые джойны, запросы в цикле и блокировки таблиц, которые валят время отклика. Включив и прочитав этот журнал, мы находим конкретные операции, которые тормозят сайт, и понимаем, добавить ли индекс, переписать ли запрос или закешировать результат. Это та причина, которую чаще всего ошибочно списывают на слабый хостинг, хотя дело в одном-двух тяжёлых запросах.

Когда логов недостаточно — потому что их толком нет

Иногда главная проблема не в чтении логов, а в том, что нужное вообще не пишется или уже затёрто. Логирование выключено или стоит на минимальном уровне, ротация настроена слишком агрессивно и важная запись пропала через час, либо наоборот — журналы разрослись и забивают диск, мешая работе сайта. В таких случаях анализ начинается с наведения порядка: мы настраиваем уровни логирования, чтобы фиксировалось важное и не писался мусор, и ротацию, чтобы записи сохранялись на нужный срок, но не переполняли диск. Без этого любой разбор будет неполным, потому что разбирать просто нечего. Грамотное логирование — это фундамент, на котором держится вся последующая диагностика.

От разбора к исправлению

Анализ логов отвечает на вопрос что и как часто ломается, но сам по себе ничего не чинит. Поэтому в отчёте мы не только показываем карту ошибок, но и предлагаем путь к их устранению по приоритету: с самого частого и опасного к фоновому шуму. По готовой карте исправление идёт быстрее и дешевле, потому что разработчику не нужно искать проблему — она уже локализована и подтверждена фактами. Закрыть найденные по логам ошибки можно силами вашей команды или нашими: направление исправление ошибок Битрикс устраняет конкретные группы из карты с понятной причиной. А чтобы следующий сбой не пришлось снова искать вручную, по логам удобно настроить мониторинг ошибок Битрикс с оповещениями — тогда вы узнаете о проблеме раньше пользователей.

Чем анализ логов отличается от взгляда в один файл

Заглянуть в php error_log умеет почти любой администратор, и иногда этого достаточно. Анализ логов как услуга начинается там, где простого взгляда мало: нужно свести несколько источников, отделить шум от сигнала на большом объёме, поймать паттерн, который виден только в корреляции, или разобраться, почему журналы вообще не содержат нужного. Это методичная работа, а не везение. Мы заходим со структурой: какие источники собрать, как нормализовать, по каким признакам группировать, с чем коррелировать. Поэтому результат воспроизводим и подкреплён фактами, а не зависит от того, повезло ли наткнуться на нужную строку.

Скрытые ошибки, которые копят долг

Отдельно стоит сказать про ошибки, которые не валят сайт, но тихо вредят. Фоновые warning и notice, исключения, которые перехватываются и глушатся, медленные запросы в пределах терпимого, обрывы обмена, которые потом повторяются вручную. Каждая такая мелочь по отдельности не критична, но вместе они портят данные, замедляют страницы и однажды складываются в крупный сбой. По логам эти проблемы видны заранее — как фон, который нарастает. Регулярный анализ журналов превращает невидимый технический долг в список с приоритетом, который можно гасить планомерно, а не тушить пожары по факту падения. Это разница между управляемым проектом и проектом, который живёт от аварии до аварии.

Как мы не вредим боевому сайту

Анализ логов — одна из самых безопасных диагностических услуг, потому что журналы мы читаем, а не правим. Тем не менее осторожность нужна и здесь. Большие журналы выгружаем и разбираем на копиях, чтобы не нагружать боевой сервер тяжёлым парсингом. При настройке уровней логирования и ротации сначала фиксируем текущую конфигурацию, чтобы вернуться, если что-то пойдёт не так. Если в логах есть персональные данные, обращаемся с ними бережно и не выгружаем лишнего. Доступ к журналам используем строго для разбора, а действия фиксируем. Мы понимаем, что сайт работает прямо сейчас, и не создаём ему дополнительной нагрузки ради анализа.

Возражения, которые мы слышим чаще всего

У нас и так настроен какой-то мониторинг, зачем разбирать логи вручную. Мониторинг говорит, что упало, но редко объясняет почему: он ловит симптом по порогу, а причина по-прежнему в журналах. Анализ логов и мониторинг не конкуренты, а дополняют друг друга — разбор находит и формулирует проблему, мониторинг потом следит, чтобы она не вернулась незаметно. Логов слишком много, там невозможно разобраться. В этом и смысл услуги: мы агрегируем и группируем объём, который вручную не осилить, и сводим его к короткому списку паттернов. У нас вроде всё работает, ошибок нет. Почти всегда в логах действующего сайта есть фоновые ошибки, о которых никто не знает, и регулярный анализ показывает их до того, как они станут заметны клиентам.

Типовые находки в логах Битрикса

За годы разбора журналов складывается копилка знакомых паттернов, и это ускоряет работу. Среди частых находок: фатальные ошибки из чужих доработок, которые всплывают только при определённых данных; исчерпание лимита памяти на тяжёлых выборках каталога; таймауты FastCGI, когда бэкенд не успевает ответить и отдаёт 500 без записи в php error_log; медленные запросы без индексов, которые валят базу под нагрузкой; ошибки агентов и крон-задач, тихо ломающие фоновую логику; обрывы обмена с 1С по расписанию, совпадающие с блокировками таблиц; всплеск ошибок авторизации при атаках перебором. Узнавая знакомый паттерн, мы быстрее проверяем гипотезу, но всё равно подтверждаем её фактами из журналов, а не ставим диагноз по памяти.

Что вы получаете в отчёте

Итог анализа — не фраза, а документ. В нём топ повторяющихся ошибок с частотой и динамикой, временные шкалы всплесков, найденные скрытые паттерны и корреляции с нагрузкой, агентами и обменом, оценка риска по каждой группе и приоритезированный план: что чинить первым и почему. Если мы настраивали логирование, в отчёт входит и описание новой конфигурации уровней и ротации. Документ написан так, чтобы его понял и разработчик, и руководитель: техническому специалисту он даёт точку входа и факты, а руководителю — ясную картину, что происходит с сайтом и во что это обходится. С этим отчётом исправление можно поручить кому угодно.

С чего начать

Начните с короткого описания ситуации: что беспокоит — падения, тормоза, обрывы обмена — и есть ли доступ к логам и панели хостинга. Даже пары строк достаточно, чтобы мы оценили объём и предложили формат: экспресс-разбор по горящему сбою или полный анализ всех источников. Первичная оценка бесплатна, и по её итогу вы получите честный ответ: видна ли причина сразу или нужно сводить журналы и искать паттерны, сколько это займёт и сколько будет стоить. Дальше — собираем логи, строим карту ошибок и показываем полную картину проблем по журналам, чтобы вы перестали гадать и начали чинить по фактам. А если захотите, наведём порядок и в самом логировании, чтобы следующий сбой был виден сразу, без долгих поисков по разрозненным файлам.