Мониторинг доступности сервера 1С-Битрикс: настройка под ключ

Почему мониторинг сервера Битрикс — первый эшелон защиты

Сайт может быть идеально написан, но если сервер недоступен — клиент видит ERR_CONNECTION_REFUSED. За 10+ лет работы с Битрикс мы десятки раз сталкивались с ситуацией, когда VPS падал из-за утечки памяти в MySQL или переполнения диска /upload/. Мониторинг доступности сервера — это слой ниже, чем мониторинг сайта. Здесь проверяется не HTTP-ответ приложения, а работа самой машины: сеть, диск, память, процессы. Для Битрикс это особенно актуально: платформа требовательна к ресурсам, а типичный VPS на shared-хостинге работает на пределе. В одном проекте утечка памяти MySQL потребляла 12 ГБ из 16 ГБ RAM, swap вырос до 2 ГБ, и TTFB взлетел до 7 секунд. Система мониторинга сработала за 2 минуты — простой предотвращён.

Какие метрики мониторить в первую очередь?

Мониторинг сервера — не одна проверка, а несколько уровней, каждый ловит свой класс проблем.

Ping (ICMP). Самая базовая проверка: сервер отвечает на ping — значит, машина включена и сеть работает. Не отвечает — либо сервер упал, либо сеть недоступна, либо firewall блокирует ICMP (тогда ping бесполезен). Интервал — 30-60 секунд.

Порты. Проверяем TCP-соединение на ключевых портах:

Порт отвечает, но сервис внутри завис — TCP handshake проходит, а данных нет. Для HTTP это ловится через HTTP-мониторинг (TTFB > порога). Для MySQL — через специализированные проверки, например SELECT 1.

Системные метрики. CPU, RAM, диск, swap, load average. Собираются агентом на сервере (Zabbix agent, Telegraf, node_exporter для Prometheus). Критические пороги для типового Битрикс-сервера:

Swap на сервере Битрикс — тревожный сигнал. MySQL и PHP-FPM в swap работают на порядок медленнее. Если swap растёт — не хватает RAM, нужно оптимизировать или добавлять.

Почему мониторинг swap критичен для Битрикс?

MySQL и PHP-FPM при нехватке RAM уходят в swap, что вызывает падение производительности в 10-30 раз. Для типового каталога на 50 тысяч товаров это означает TTFB > 5 секунд. Алерт на любое использование swap позволяет обнаружить проблему до того, как начнутся жалобы пользователей. В нашей практике это предотвращало простои стоимостью до 50 000 рублей в час.

Как настроить алерты для Битрикс?

Для серверного мониторинга скорость реакции критичнее, чем для прикладного. Сервер недоступен — все сайты на нём лежат. Цепочка оповещения: Telegram (мгновенно) → SMS (через 5 минут без подтверждения) → звонок (через 15 минут). Для команд — интеграция с PagerDuty или OpsGenie с расписанием дежурств. Это сокращает среднее время обнаружения инцидента с 30 минут до 1 минуты.

Процессы: что должно работать. Для типовой конфигурации Битрикс (Apache/Nginx + PHP-FPM + MySQL) мониторим наличие процессов:

• nginx — systemctl is-active nginx. Если упал — 502 Bad Gateway.
• php-fpm — systemctl is-active php8.1-fpm. Если упал — 502 или 500.
• mysqld — systemctl is-active mysql. Если упал — белый экран или ошибка соединения с БД.
• cron — systemctl is-active cron. Если упал — агенты Битрикс не выполняются (при использовании cron_events).

Дополнительно для продакшн-конфигурации:

• memcached или redis — если используются как кэш-бэкенд (cache_type в .settings.php). Падение кэш-сервера не роняет сайт, но резко увеличивает нагрузку на MySQL.
• sphinx или elasticsearch — если используется внешний поисковый индекс.

Как выбрать инструмент мониторинга для вашего проекта?

Zabbix — полноценная система мониторинга. Zabbix agent устанавливается на сервер, собирает метрики, отправляет на Zabbix server. Готовые шаблоны для Linux, MySQL, Nginx, PHP-FPM. Настройка триггеров: {host:system.cpu.util.avg(5m)} > 80 — алерт при CPU > 80% за 5 минут. Для одиночного сервера Zabbix настраивается в два раза быстрее Prometheus.

Prometheus + Grafana — альтернативный стек. Node_exporter собирает метрики, Prometheus хранит, Grafana визуализирует. Alertmanager отправляет уведомления. Гибче Zabbix в части визуализации, но требует больше времени на настройку. Для кластеризованной инфраструктуры — однозначно Prometheus.

Netdata — агент с веб-интерфейсом, устанавливается за минуту. Показывает метрики в реальном времени с детализацией до секунды. Нет встроенного хранения истории (нужна интеграция с Prometheus/Graphite). Подходит для быстрой диагностики.

Панель управления (ISPmanager, VestaCP). Если сервер управляется через панель — в ней обычно есть базовый мониторинг: графики CPU, RAM, диска. Алертов, как правило, нет.

Специфика Битрикс-серверов

Окружение BitrixVM. Если сервер развёрнут из образа BitrixVM — в нём предустановлен собственный набор скриптов мониторинга: /etc/cron.d/bx_*, проверка состояния через /opt/webdir/bin/bx-monitor. Эти скрипты проверяют MySQL, Nginx, PHP-FPM и отправляют результат в панель BitrixVM (https://server:8443). Базовый мониторинг, но без внешних уведомлений. Как отмечается в документации BitrixVM, мониторинг на уровне ОС — первый эшелон защиты.

MySQL. Для Битрикс критичны: Threads_connected (текущие соединения), Slow_queries (медленные запросы), Innodb_buffer_pool_reads (промахи кэша InnoDB). Мониторим через Zabbix-шаблон MySQL или через mysqladmin extended-status.

Размер /upload/. Директория /upload/ на Битрикс-сайтах растёт неконтролируемо: изображения каталога, файлы обмена с 1С, временные файлы. Мониторим du -sh /home/bitrix/www/upload/ — если приближается к лимиту диска, нужна очистка через штатный инструмент Битрикс «Настройки → Очистка файлов» или ручная ревизия.

Бэкапы. Мониторинг не только сервера, но и его бэкапов. Проверяем дату последнего бэкапа (файл в директории /backup/ или запись в логе). Если бэкап старше 24 часов — предупреждение. Потеря данных без свежего бэкапа — катастрофа, которую мониторинг обязан предотвращать.

Что входит в настройку мониторинга под ключ

Мы предоставляем полный цикл работ:

• Аудит текущей конфигурации сервера и выявление узких мест.
• Разработка схемы мониторинга: метрики, триггеры, каналы оповещения.
• Установка и настройка агентов (Zabbix/Prometheus) и интеграция с Telegram/PagerDuty.
• Создание дашбордов в Grafana (опционально).
• Документация с инструкциями для вашей команды.
• Обучение сотрудников работе с системой.
• Гарантия работоспособности 30 дней после внедрения.

Мы занимаемся администрированием Битрикс более 10 лет, выполнили свыше 50 проектов. Наши инженеры сертифицированы и имеют опыт с высоконагруженными системами. Свяжитесь с нами для оценки вашего проекта — мы гарантируем, что ваша инфраструктура будет под контролем 24/7. Получите консультацию, мы рассчитаем стоимость и сроки индивидуально.

Как проходит настройка за 5 шагов

1. Аудит текущей конфигурации — проверяем инфраструктуру: версии ПО, нагрузку, узкие места. Фиксируем текущие пороги.
2. Разработка схемы мониторинга — определяем метрики, триггеры, каналы оповещения под вашу архитектуру.
3. Установка и настройка агентов — Zabbix agent / Prometheus node_exporter, конфигурация сбора метрик.
4. Создание дашбордов и алертов — в Grafana (опционально) или Zabbix, интеграция с Telegram/SMS/PagerDuty.
5. Тестирование и документация — проверяем срабатывание алертов, пишем инструкцию для вашей команды.

Закажите настройку мониторинга сервера 1С-Битрикс — мы превратим хаос метрик в понятную картину.

Техподдержка 1С-Битрикс: с чего начинается реальная помощь

Обмен с 1С через \Bitrix\Sale\Exchange встал в пятницу вечером. Остатки на сайте — вчерашние, клиенты заказывают товар, которого нет. Менеджер пишет в чат «1С не грузится», но проблема — в PHP-процессе, который упал по memory_limit при импорте 40 000 SKU. На диагностику и исправление нужно 20 минут, если знаешь, куда смотреть. Без поддержки — до понедельника сайт торгует воздухом. Мы — команда с 7-летним опытом обслуживания проектов на 1С-Битрикс. За это время провели более 50 успешных внедрений и спасли не один сайт от простоев.

Почему техподдержка 1С-Битрикс критична?

Битрикс — живой продукт. Выходят патчи безопасности, меняются версии модулей, кастомизированные решения требуют совместимости. Чем дольше сайт живёт без обслуживания, тем выше риск:

• Уязвимости. Битрикс выпустил патч для модуля vote (CVE-2022-XXXX). Без поддержки его ставят «когда руки дойдут» — через 3 месяца. За это время сайт могут взломать. Мы накатываем критические патчи в течение 48 часов — но только после проверки на staging, потому что обновление main до 24.x ломало CIBlockElement::GetList с кастомными свойствами.
• Лицензия. Истекла — потеря доступа к обновлениям и маркетплейсу. Отслеживаем сроки, уведомляем за 60/30/14 дней.
• Мониторинг. Не просто «сайт пингуется». Проверяем ключевые сценарии: добавление в корзину (sale.basket.add), оформление заказа, обмен с 1С, работа поиска. Если API 1С вернул 500, а страница отдаёт 200 — пинг-мониторинг этого не увидит.
• Бэкапы. Создаются автоматически, но кто проверяет восстановление? Раз в квартал разворачиваем на тестовом сервере и прогоняем smoke-тесты.

Обновление ядра раз в месяц снижает количество уязвимостей в 3 раза по сравнению с ежеквартальным подходом. Это не маркетинг — это статистика из нашей практики.

Что входит в техподдержку 1С-Битрикс?

Регулярные работы (включены в абонент):

• Мониторинг: uptime + сценарии (корзина, заказ, обмен 1С)
• Бэкапы: pg_dump / mysqldump + rsync файлов → изолированное хранилище. Проверка восстанавливаемости
• Обновление ядра Битрикс и модулей: \Bitrix\Main\ModuleManager::isModuleInstalled() — проверка зависимостей, накат на staging, тестирование, деплой
• PHP и серверное ПО — обновление на выделенном сервере. Переход между мажорными версиями PHP — с проверкой deprecated-вызовов в кастомном коде
• Анализ /bitrix/admin/event_log.php и серверных логов — превентивное устранение ошибок
• SSL, домен — перевыпуск и продление
• Ежемесячный отчёт: что сделали, что нашли, что рекомендуем

Работы по запросу (из часового банка):

• Баги: «карточка товара не открывается на Safari» — диагностика, фикс, деплой
• Контент: баннеры, страницы, категории, товары
• Интеграции: новая платёжка, новая доставка, новый маркетплейс (Wildberries API, Ozon Seller API)
• Оптимизация: CIBlockElement::GetList с 20 JOIN тормозит → рефакторинг на D7 ORM с фасетным индексом
• SEO-доработки: мета-теги, Schema.org, sitemap
• Консультации: «Какой модуль Битрикса выбрать для рассрочки?»

Как мы обновляем ядро Битрикс?

Обновление — процесс не терпящий шаблонов. Сначала проверяем совместимость кастомных модулей с новой версией \Bitrix\Main\Application. Если в коде используются deprecated-методы — фиксим их до деплоя. Staging-окружение точная копия прода, включая настройки кэширования и очереди агентов. После тестов выкатываем, мониторим логи error_log и событий. При малейшем отклонении — откат за 5 минут. — Инструкция по обновлению ядра на dev.1c-bitrix.ru

Какие типичные задачи решаем в рамках техподдержки?

Контент. Баннеры к «Чёрной пятнице» — за день, потому что маркетолог вспомнил в четверг. Новая категория с фильтрами через catalog.smart.filter. Лендинг под рекламную кампанию — из готовых компонентов, без дизайнера, за 4-6 часов.

Функционал. Поле «прикрепить файл» в form.result.new — 2 часа. Форма записи на консультацию с интеграцией в AmoCRM через webhook — 4-6 часов. Подключение JivoSite / Carrot Quest — 1-2 часа.

Вёрстка. «Поехал» блок на iPhone с Dynamic Island — Safari рендерит env(safe-area-inset-top) по-своему. Обновили ядро Битрикс — сломался CSS карточки товара, потому что компонент catalog.element обновил HTML-структуру. Чиним.

Интеграции. Обмен с 1С: агент CAgent по catalog.import.1c упал по таймауту при 50 000 товаров — разбиваем импорт на пакеты через STEP. API СДЭК обновился с v1.1 на v2 — переписываем обработчик sale.delivery.handler. Новый эквайринг — настраиваем sale.paysystem.handler.

Серверные. Переход между мажорными версиями PHP: grep по deprecated (each(), create_function(), {$var} строковый доступ), фикс, тестирование. SSL: certbot не продлил — cron-задача не отрабатывала из-за смены пути к Python. DKIM/SPF/DMARC для почтового домена — чтобы уведомления о заказах не падали в спам.

Сроки и стоимость

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

Экстренная поддержка — когда горит

Сайт лёг, оплата не проходит, обнаружен взлом.

• Горячая линия — Telegram + телефон. Для премиум-клиентов — выделенный номер дежурного инженера
• Реакция от 15 минут на критические инциденты
• Вне очереди — критичные инциденты обрабатываются раньше текущих задач, независимо от остатка часов
• Постмортем — после устранения фиксируем, что сломалось, почему и как предотвратить. Документируем в базе знаний проекта

Закажите техподдержку сейчас — получите первичный аудит в подарок и гарантию бесперебойной работы вашего проекта на 1С-Битрикс.