Стандартная установка Zabbix по туториалу генерирует сотни триггеров, которые создают шум и пропускают реальные сбои. После подключения готовых шаблонов Linux by Zabbix agent на каждом сервере появляется 200+ триггеров — половина срабатывает постоянно, а критичные инциденты остаются незамеченными. Мы решаем эту проблему настройкой production-ready мониторинга: осознанная архитектура, чёткие метрики и разумные пороги. За 6 лет работы мы сэкономили клиентам более 5 миллионов рублей на инфраструктуре за счёт оптимизации мониторинга, а общее количество ложных срабатываний сократили на 80%.
Как выбрать схему развёртывания Zabbix?
Для одного сайта с несколькими серверами подходит схема Zabbix Server + PostgreSQL на отдельной VM, агенты на каждом хосте. При числе хостов более 20 или географической распределённости добавляем Zabbix Proxy в каждой зоне. Proxy буферизует данные и отправляет пачками — снижает нагрузку на сервер и устойчив к разрывам.
| Схема |
Число хостов |
Преимущества |
Недостатки |
| Один сервер |
1–20 |
Простота, низкие затраты |
Единая точка отказа |
| С прокси |
20–200 |
Масштабирование, отказоустойчивость |
Дополнительный слой |
| Распределённая (HA) |
200+ |
Почти 100% uptime |
Сложность настройки |
Минимальные требования для сервера с 10 хостами: 2 vCPU, 4 GB RAM, 50 GB SSD (учёт истории на 90 дней). Для индивидуальной консультации свяжитесь с нами — мы подберём оптимальную схему для вашего проекта.
Как установить Zabbix Server за 5 шагов
- Добавьте репозиторий Zabbix 7.0 и установите пакеты: server, frontend, agent2.
- Создайте PostgreSQL пользователя и базу данных для Zabbix.
- Импортируйте схему базы данных.
- Настройте конфигурацию сервера.
- Запустите сервер и настройте автозагрузку.
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
Триггеры, которые не шумят:
| Метрика |
Условие |
Уровень |
Пояснение |
| CPU |
avg(/hostname/system.cpu.util,5m) > 75 |
Warning |
Длительная высокая загрузка |
| CPU |
avg(/hostname/system.cpu.util,1m) > 90 |
Critical |
Мгновенная перегрузка |
| Память |
last(/hostname/vm.memory.size[pavailable]) < 10 |
Critical |
Почти нет свободной памяти |
| Диск |
last(/hostname/vfs.fs.size[/,pfree]) < 15 |
Warning |
Скоро закончится место |
| Nginx RPS |
last(/hostname/nginx.requests) < avg(1h) * 0.3 |
Warning |
Аномальный спад трафика |
Как оптимизировать хранение данных с 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 исключает бота, который на самом деле — реальный трафик с корпоративного прокси. Закажите аудит текущих тегов — мы найдём причину за неделю.
После правильной настройки экономия рекламного бюджета может достигать 150 000 ₽ в месяц — это реальный кейс интернет-магазина с 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: 1990.00,
currency: 'RUB'
}]
}
});
Плохая практика: GTM-тег парсит DOM — ищет цену в span.price, название в h1. Это ломается при любом изменении верстки. Хорошая практика: всегда dataLayer. Используем Preview Mode для отладки и GTM Server-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 после обновления фронтенда
Что входит в работу
| Компонент |
Описание |
| Аудит текущих тегов |
Проверка существующих GTM-тегов, dataLayer, дублей и ошибок |
| Дизайн событийной схемы |
Документация: список событий, параметры, триггеры |
| Настройка GA4 + GTM |
Создание конфигурации, тегов, Custom definitions |
| Яндекс.Метрика |
Установка счётчика, создание целей, настройка Вебвизора |
| Amplitude (опционально) |
Настройка клиентского и серверного SDK, когорты |
| QA и мониторинг |
Тестирование в Preview Mode, Alerting |
| Обучение и передача |
Доступы, инструкция по добавлению новых событий, консоль |
Процесс и сроки
- Аудит текущих тегов и данных (2 дня)
- Дизайн событийной схемы (2 дня)
- Разработка Data Layer и настройка тегов (3–5 дней)
- QA в Preview Mode и на staging (2 дня)
- Деплой и настройка дашбордов (1 день)
| Сценарий |
Срок |
| Базовая настройка GA4 + GTM |
1 неделя |
| Полный e-commerce tracking + Метрика |
2–3 недели |
| Server-side GTM + Amplitude |
3–5 недель |
Стоимость рассчитывается индивидуально. Получите консультацию по настройке веб-аналитики для вашего проекта — мы оценим объём работ за один день. Свяжитесь с нами, чтобы начать.
Wikipedia: Веб-аналитика — подробнее о методах и метриках. Официальная документация по событийной модели GA4 доступна в Google Analytics 4.