Мониторинг и логи окружения

Понимать, что происходит с сервером, помогают логи и метрики. В BitrixEnv каждый компонент стека пишет свой лог, а сам 1С-Битрикс даёт инструменты профилирования производительности. Разберём, где лежат ключевые логи, как читать метрики нагрузки и как подключить внешний мониторинг, чтобы ловить проблемы до того, как их заметят пользователи.

Где лежат логи компонентов

BitrixEnv раскладывает логи стандартно для RHEL-стека, по компонентам. Держите эту карту под рукой при разборе инцидента.

Быстрый просмотр в реальном времени по мере поступления запросов:

tail -f /var/log/nginx/error.log

Чтение логов Nginx

Access-лог Nginx — основной источник для анализа трафика и медленных ответов. Если в формат лога добавлено время ответа бэкенда ($upstream_response_time), можно быстро находить тяжёлые страницы.

• Топ URL по количеству запросов — где основная нагрузка;
• Всплеск 5xx — сервер отдаёт ошибки, смотрим error.log и PHP;
• Много 499 — клиенты отваливаются, не дождавшись ответа (медленный бэкенд).

Примеры быстрого анализа:

grep ' 502 ' /var/log/nginx/access.log | wc -l — сколько было 502;
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head — топ IP по запросам.

PHP-FPM slowlog и медленные запросы MySQL

Два самых полезных инструмента для поиска «тормозов» — slowlog PHP-FPM и slow query log MySQL. Первый показывает, где залипает PHP, второй — какие SQL-запросы съедают время.

PHP-FPM slowlog включается в конфиге пула директивами:

slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 5s

В лог попадает трассировка PHP для запросов дольше порога — сразу видно, в какой функции застревает выполнение.

Slow query log MySQL включается в конфигурации СУБД:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Разобрать накопленный slow-лог удобно утилитой mysqldumpslow или pt-query-digest — они группируют однотипные запросы и показывают самые дорогие.

Метрики нагрузки сервера

Логи отвечают на вопрос «что сломалось», метрики — «что происходит прямо сейчас». Базовый набор утилит есть в любом BitrixEnv.

Частая причина внезапных «тормозов» магазина на 1С-Битрикс — забитый диск (разросшиеся логи, кеш, бэкапы) или упор в дисковый I/O при неоптимальных запросах. Метрики iostat и df -h проверяйте в первую очередь.

Инструменты производительности 1С-Битрикс

Помимо серверных логов, сам продукт даёт встроенное профилирование в административной панели. Это первое, куда стоит смотреть при жалобах на скорость.

• Монитор производительности (Настройки → Производительность) — измеряет время генерации страниц, число запросов к БД, попадания в кеш и даёт итоговую оценку конфигурации.
• Панель отладки для разработчика показывает по каждому хиту количество и время SQL-запросов, время компонентов — удобно ловить тяжёлые компоненты.
• Проверка системы — контроль соответствия окружения требованиям (версии PHP/MySQL, настройки).

Связка проста: Монитор производительности показывает, что страница медленная и делает много запросов, панель отладки указывает конкретный компонент, а slow query log MySQL — конкретный SQL. Так вы спускаетесь от симптома к причине.

Внешний мониторинг и алерты

Ручной просмотр логов хорош для разбора инцидента, но не для его предотвращения. Для этого нужен постоянный мониторинг с оповещениями. BitrixEnv штатно совместим с внешними системами.

• Zabbix — классика для серверного мониторинга: агент собирает CPU, память, диск, статус сервисов, метрики Nginx и MySQL, шлёт алерты по порогам.
• Prometheus + Grafana — метрики через экспортеры (node_exporter, mysqld_exporter, nginx-exporter) и наглядные дашборды.
• Uptime-мониторинг снаружи — проверка доступности сайта и срока действия SSL-сертификата, чтобы узнать о падении раньше клиентов.

Минимальный набор алертов, который стоит настроить сразу:

1. Сайт не отвечает / рост 5xx;
2. Диск заполнен более чем на 85–90%;
3. Load average выше числа ядер продолжительное время;
4. Сервис (nginx, php-fpm, mysqld) остановлен;
5. Скорый истёк SSL-сертификата.

Итог

Диагностика BitrixEnv строится на двух опорах: логах компонентов (Nginx, PHP-FPM, MySQL, система) и метриках нагрузки, дополненных встроенными инструментами производительности 1С-Битрикс. Логи отвечают на «что и почему сломалось», метрики — на «что происходит сейчас», а Монитор производительности связывает медленную страницу с конкретным компонентом и SQL-запросом. Для проактивной работы поверх этого ставят внешний мониторинг с алертами.

Мы настраиваем мониторинг и разбираем инциденты на проектах 1С-Битрикс в рамках DevOps и технической поддержки: подключаем Zabbix или Prometheus с дашбордами и оповещениями, анализируем логи и slow-запросы, находим узкие места и оптимизируем окружение под нагрузку. Так проблемы отлавливаются заранее, а разбор сбоев занимает минуты, а не часы.