Налаштування моніторингу сервера (Zabbix) для сайту

Стандартна установка Zabbix за туторіалом генерує сотні тригерів, які створюють шум і пропускають реальні збої. Після підключення готових шаблонів Linux by Zabbix agent на кожному сервері з'являється 200+ тригерів — половина спрацьовує постійно, а критичні інциденти залишаються непоміченими. Ми вирішуємо цю проблему налаштуванням production-ready моніторингу: усвідомлена архітектура, чіткі метрики та розумні пороги. За 6 років роботи ми заощадили клієнтам понад 5 мільйонів гривень на інфраструктурі за рахунок оптимізації моніторингу, а загальну кількість хибних спрацьовувань скоротили на 80%.

Як вибрати схему розгортання Zabbix?

Для одного сайту з кількома серверами підходить схема Zabbix Server + PostgreSQL на окремій VM, агенти на кожному хості. При числі хостів більше 20 або географічній розподіленості додаємо Zabbix Proxy в кожній зоні. Proxy буферизує дані та відправляє пачками — знижує навантаження на сервер і стійкий до розривів.

Мінімальні вимоги для сервера з 10 хостами: 2 vCPU, 4 GB RAM, 50 GB SSD (облік історії на 90 днів). Для індивідуальної консультації зв'яжіться з нами — ми підберемо оптимальну схему для вашого проєкту.

Як встановити Zabbix Server за 5 кроків

1. Додайте репозиторій Zabbix 7.0 та встановіть пакети: server, frontend, agent2.
2. Створіть PostgreSQL користувача та базу даних для Zabbix.
3. Імпортуйте схему бази даних.
4. Налаштуйте конфігурацію сервера.
5. Запустіть сервер та налаштуйте автозавантаження.

wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-2+ubuntu22.04_all.deb
dpkg -i zabbix-release_7.0-2+ubuntu22.04_all.deb
apt update && apt install -y zabbix-server-pgsql zabbix-frontend-php zabbix-sql-scripts zabbix-agent2
sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbix

Конфігурація /etc/zabbix/zabbix_server.conf:

DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=your_password
StartPollers=10
StartPingers=5
CacheSize=128M
HistoryCacheSize=64M
ValueCacheSize=256M

Установка Zabbix Agent на цільовому хості:

apt install -y zabbix-agent2
cat > /etc/zabbix/zabbix_agent2.conf << EOF
Server=<ZABBIX_SERVER_IP>
ServerActive=<ZABBIX_SERVER_IP>
Hostname=web-server-01
AllowKey=system.run[*]
EOF
systemctl enable --now zabbix-agent2

Чому кастомні шаблони кращі за готові?

Готові шаблони включають сотні метрик, більшість з яких не потрібні. Ми відключаємо неінформативні тригери та додаємо бізнес-метрики: час відповіді API, кількість активних сесій, помилки в логах. На одному проєкті відключили 80% дефолтних тригерів — кількість хибних спрацьовувань знизилася з 50 до 2 на день.

Приклад налаштування користувацького параметра для PHP-FPM:

UserParameter=php-fpm.status[*],curl -s --unix-socket /run/php/php8.2-fpm.sock http://localhost/status?json

Тригери, які не шумлять:

Як оптимізувати зберігання даних з TimescaleDB?

При великому обсязі метрик PostgreSQL може гальмувати. Рішення — TimescaleDB. Міграція існуючої бази та налаштування стиснення:

SELECT create_hypertable('history', 'clock', chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable('history_uint', 'clock', chunk_time_interval => 86400, migrate_data => true);
ALTER TABLE history SET (timescaledb.compress, timescaledb.compress_segmentby = 'itemid');
SELECT add_compression_policy('history', INTERVAL '7 days');

TimescaleDB стискає дані в 10 разів ефективніше за стандартний PostgreSQL — це знижує навантаження на диск і прискорює запити. Налаштовуємо Housekeeping: зберігати тренди 365 днів, історію — 90 днів. Після включення компресії обсяг зайнятого місця зменшується на 90%, а швидкість запитів за останню добу зростає в 5-10 разів.

Що входить в роботу

• Розгортання Zabbix Server + PostgreSQL
• Встановлення та налаштування агентів на всіх серверах
• Підключення готових та розробка кастомних шаблонів
• Налаштування тригерів та дій (Telegram, e-mail)
• Створення веб-сценаріїв для моніторингу доступності URL
• Побудова дашбордів (Zabbix + Grafana при необхідності)
• Оптимізація зберігання (TimescaleDB, housekeeping)
• Документація та навчання адміністраторів

Наш досвід та гарантії

За 6 років роботи ми розгорнули моніторинг для 50+ веб-проєктів — від невеликих інтернет-магазинів до високонавантажених сервісів з 500+ хостами. Наші інженери сертифіковані Zabbix та мають досвід роботи з кластерними конфігураціями. Гарантуємо: після налаштування ви будете отримувати тільки значущі сповіщення, а дашборд відображатиме реальний стан системи.

Терміни та вартість

Базова установка з моніторингом 3–5 серверів — 1 робочий день. Повноцінне налаштування з кастомними елементами та дашбордами — 3–5 днів. Міграція з іншої системи — додатково 1–2 дні. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту.

Отримайте консультацію — напишіть нам, і ми запропонуємо оптимальне рішення під ваш бюджет та терміни.

Як налаштувати веб-аналітику: GA4, GTM, Яндекс.Метрика та Amplitude

Ми часто бачимо: конверсія 1.2 %, трафік зростає, а конверсія стоїть. Маркетолог дивиться в Google Analytics і каже: «користувачі йдуть з кроку 2 оформлення замовлення». Розробник відкриває той самий крок — помилок немає, в Sentry тиша. Значить, справа не в JS-базі, а в UX або в кривих даних, які показує аналітика. Аналітика ламається непомітно: подія перестала трекатися після редеплою — ніхто не помітив; GTM-тег стріляє двічі — дані задвоїлися; фільтр GA4 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.

Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 50 000 сесій на день, де дедуплікація purchase повернула 20 % невірно приписаних конверсій.

Чому події GA4 дублюються і як це виправити?

Universal Analytics закрито, його місце зайняла подієва модель GA4. У ній немає фіксованих хітів сторінок і транзакцій — лише події з параметрами. Це гнучкіше, але вимагає правильного дизайну подій.

Автоматичні події GA4 збирає сам: page_view, scroll, click, session_start. Рекомендовані події потрібно реалізувати самостійно: purchase, add_to_cart, begin_checkout, view_item. Google очікує конкретну схему параметрів — якщо передати product_id замість item_id, дані потрапляють в GA4, але не в стандартні звіти e-commerce. Кастомні події для специфіки проєкту: filter_applied, video_progress, form_step_completed. Кастомні параметри необхідно зареєструвати в GA4 Admin → Custom definitions, інакше вони не будуть доступні у звітах.

Часта помилка — подія purchase з дублями. Причина: тег спрацьовує на сторінці /thank-you, користувач оновлює сторінку — другий purchase іде в GA4. Рішення: на бекенді генеруємо унікальний transaction_id і передаємо в подію. GA4 de-duplicates по ньому — перевіряйте через DebugView. Правильна атрибуція економить до 20 % рекламного бюджету, який раніше йшов на невірно приписані конверсії.

Як налаштувати data layer, щоб не втратити дані?

GTM — інструмент для керування тегами без деплою коду. Але «без коду» не означає «без архітектури». Data Layer — основа всього. Передаємо дані з застосунку в GTM через dataLayer.push(). Структура: event + контекстні дані. Для e-commerce: перед відкриттям сторінки продукту — push з даними товару. GTM-тег читає з dataLayer, не з DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Назва товару',
      price: null,
      currency: null
    }]
  }
});

Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-side за показником втрати подій через розширення браузера.

Як Яндекс.Метрика доповнює веб-аналітику?

Для російської аудиторії Метрика обов'язкова — особливо Вебвізор. Запис сесії користувача, який кинув кошик, часто дає відповідь швидше, ніж тиждень аналізу воронки. Цілі в Метриці: подієві (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) або автоматичні (клік по кнопці, відвідування сторінки). Зв'язка з CRM через Метрика Плюс — передача офлайн-конверсій. Наш досвід: у 8 з 10 проєктів після налаштування Метрики знаходили приховані баги в UX, які не показували інші системи.

Що дає product analytics в Amplitude?

Amplitude — продуктовий інструмент, на відміну від маркетингових GA4 та Метрики. Він заточений під аналіз поведінки користувачів всередині продукту: воронки, ретеншн, user paths. Amplitude підходить для SaaS-продуктів, мобільних застосунків та будь-яких сервісів із зареєстрованими користувачами, де важливо зрозуміти, як проходять онбординг, на якому кроці йдуть, які фічі використовують частіше. Ключові концепції: identify (пов'язати анонімного користувача з userId після авторизації), group (акаунт у B2B SaaS), когорти для утримання. Amplitude Chart — воронка кроків за останні 30 днів з розбивкою за джерелом.

Моніторинг якості даних

Аналітика без моніторингу — чорна скринька. Налаштовуємо:

• GA4 Realtime — перевіряємо після кожного деплою, що ключові події приходять
• Alerting в GA4 — аномалія в кількості подій purchase (різке падіння = щось зламалося)
• GTM Preview в staging-оточенні перед продакшеном
• Ручні тести воронок раз на тиждень — просто пройти шлях покупця і перевірити, що все трекається

Якщо ви помітили розбіжності в даних — зв'яжіться, проведемо безкоштовний аудит коректності тегів.

Що перевіряємо після кожного деплою

• Чи всі рекомендовані події присутні в DebugView
• Чи немає задвоєнь (рахуємо кількість purchase на 100 сесій)
• Чи не змінилася структура dataLayer після оновлення фронтенду

Що входить в роботу

Процес та терміни

1. Аудит поточних тегів та даних (2 дні)
2. Дизайн подієвої схеми (2 дні)
3. Розробка Data Layer та налаштування тегів (3–5 днів)
4. QA в Preview Mode та на staging (2 дні)
5. Деплой та налаштування дашбордів (1 день)

Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.