Моніторинг доступності сервера 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С-Бітрікс.