Серверы падали незаметно: внедрение Zabbix 7 для розничной сети из 12 магазинов

Мы провели полный аудит инфраструктуры клиента: побывали в трёх магазинах, изучили серверное оборудование, каналы связи между точками и текущие средства администрирования. По результатам аудита мы предложили внедрить Zabbix 7 — одну из самых зрелых и функциональных систем мониторинга с открытым исходным кодом.

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

• Переработанный веб-интерфейс — быстрая загрузка дашбордов, улучшенная навигация, поддержка тёмной темы
• Улучшенный механизм Proxy — поддержка пассивных и активных прокси-групп для балансировки нагрузки
• Новые типы элементов данных — расширенная поддержка Prometheus-метрик и браузерного мониторинга
• Оптимизация работы с БД — значительное ускорение операций с историей данных при использовании TimescaleDB
• Расширенный API — новые методы для управления конфигурацией через автоматизацию

В ходе аудита мы обнаружили, что в каждом магазине работает по 2-4 устройства: кассовый сервер (Debian Linux), коммутатор, Wi-Fi точка доступа и иногда IP-камера. В головном офисе — основной сервер базы данных, файловый сервер и маршрутизатор. Суммарно — около 50 устройств, которые никто не контролировал. Мы также выяснили, что VPN-каналы между магазинами и офисом работают нестабильно — пропадают на 5-15 минут несколько раз в день. Это определило выбор архитектуры с локальными Proxy-серверами в каждом магазине.

Исходя из распределённой структуры сети клиента, мы спроектировали многоуровневую архитектуру мониторинга:

• Zabbix Server — центральный процесс в головном офисе, собирающий данные, обрабатывающий триггеры и отправляющий оповещения
• Zabbix Frontend — веб-интерфейс на PHP для управления и визуализации, доступный IT-отделу
• PostgreSQL Database — хранилище конфигурации и исторических данных
• Zabbix Agent 2 — лёгкий агент, установленный на каждом сервере в магазине и офисе
• Zabbix Proxy — промежуточные серверы в каждом магазине для надёжного сбора данных даже при нестабильном VPN-канале

Агенты на серверах собирают метрики (CPU, RAM, диски, сеть) и отправляют их на локальный Proxy в магазине. Proxy буферизирует данные и передаёт на центральный Zabbix Server в офисе. Сервер обрабатывает триггеры и при необходимости отправляет уведомления через Telegram. Для инфраструктуры клиента (около 50 хостов) одного центрального сервера было достаточно.

Мы подготовили план ресурсов с запасом на рост:

Центральный сервер Zabbix мы разместили на существующем сервере в офисе — 4 ядра, 8 ГБ RAM, SSD. В качестве СУБД рекомендовали PostgreSQL — она показывает лучшую производительность и поддерживает TimescaleDB для сжатия исторических данных.

Обновили систему и установили необходимые пакеты:

# Обновление системы
apt update && apt upgrade -y

# Установка необходимых пакетов
apt install -y wget gnupg2 lsb-release software-properties-common

# Добавление репозитория Zabbix 7
wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.0+debian12_all.deb
dpkg -i zabbix-release_latest_7.0+debian12_all.deb
apt update

Установили основные компоненты:

# Установка Zabbix сервера, фронтенда и агента
apt install -y zabbix-server-pgsql zabbix-frontend-php php8.2-pgsql \
  zabbix-nginx-conf zabbix-sql-scripts zabbix-agent2

# Установка PostgreSQL
apt install -y postgresql postgresql-client

Проверили корректность установки:

dpkg -l | grep zabbix
zabbix_server --version

Создали пользователя и базу данных для Zabbix:

# Переключаемся на пользователя postgres
sudo -u postgres psql

-- Создаём пользователя
CREATE USER zabbix WITH PASSWORD 'STRONG_PASSWORD_HERE';

-- Создаём базу данных
CREATE DATABASE zabbix OWNER zabbix;

-- Устанавливаем расширение для TimescaleDB (опционально)
-- \c zabbix
-- CREATE EXTENSION IF NOT EXISTS timescaledb;

\q

Импортировали начальную схему:

# Импорт схемы (занимает 1-3 минуты)
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | \
  sudo -u zabbix psql zabbix

Настроили пароль в конфигурации Zabbix Server:

# Редактируем конфигурацию
nano /etc/zabbix/zabbix_server.conf

# Находим и устанавливаем параметры:
DBPassword=STRONG_PASSWORD_HERE
DBHost=localhost
DBName=zabbix
DBUser=zabbix

Сконфигурировали Nginx для фронтенда:

# Редактируем конфигурацию Nginx
nano /etc/zabbix/nginx.conf

# Раскомментируем и настраиваем:
listen 80;
server_name zabbix.example.com;

Настроили параметры PHP:

# Редактируем PHP-FPM конфигурацию
nano /etc/zabbix/php-fpm.conf

# Проверяем параметры:
php_value[max_execution_time] = 300
php_value[memory_limit] = 256M
php_value[post_max_size] = 32M
php_value[upload_max_filesize] = 16M
php_value[max_input_time] = 300
php_value[date.timezone] = Europe/Moscow

Запустили все службы:

# Запуск и включение служб
systemctl enable --now zabbix-server zabbix-agent2 nginx php8.2-fpm

# Проверка статуса
systemctl status zabbix-server
systemctl status nginx

Прошли мастер первоначальной настройки, сменили пароль по умолчанию и создали отдельные учётные записи для IT-специалистов клиента.

На каждый сервер в магазинах мы установили Zabbix Agent 2 — новую версию агента на Go с поддержкой плагинов:

# На Debian/Ubuntu целевого хоста
wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.0+debian12_all.deb
dpkg -i zabbix-release_latest_7.0+debian12_all.deb
apt update
apt install -y zabbix-agent2

# Настройка агента
nano /etc/zabbix/zabbix_agent2.conf

Мы применили следующую конфигурацию:

# IP-адрес Zabbix сервера
Server=192.168.1.10

# Для активных проверок
ServerActive=192.168.1.10

# Уникальное имя хоста (должно совпадать с именем в веб-интерфейсе)
Hostname=web-server-01

# Разрешаем удалённые команды (опционально)
AllowKey=system.run[*]

# Таймаут выполнения проверок
Timeout=10

# Запуск и автозагрузка агента
systemctl enable --now zabbix-agent2

# Проверка работоспособности
zabbix_agent2 -t system.uptime

Для Windows-систем в офисе использовали MSI-установщик с аналогичными параметрами (C:\Program Files\Zabbix Agent 2\zabbix_agent2.conf).

Для каждого хоста настроили мониторинг: Data collection → Hosts → Create host:

• Host name — совпадает с Hostname в конфигурации агента
• Visible name — «Магазин №3 — Кассовый сервер»
• Groups — группы по магазинам и типам устройств
• Interfaces — Agent interface с IP-адресом и портом 10050

Шаблоны для Linux-серверов:

• Linux by Zabbix agent — CPU, память, диски, сеть, процессы
• Zabbix agent — состояние агента
• Nginx by Zabbix agent — для серверов с Nginx
• PostgreSQL by Zabbix agent 2 — для серверов с PostgreSQL

Встроенных шаблонов оказалось недостаточно — клиенту требовался мониторинг кассового ПО. Мы создали пользовательский шаблон:

• Template name: Custom Web Application
• Groups: Templates/Applications

Добавили элемент данных для мониторинга отклика кассы:

• Name: Application response time
• Type: HTTP agent
• Key: app.response.time
• URL: http://localhost:8080/health
• Type of information: Numeric (float)
• Update interval: 30s

Для мониторинга специфических метрик использовали UserParameter:

# В zabbix_agent2.conf или в /etc/zabbix/zabbix_agent2.d/custom.conf
UserParameter=app.connections,ss -tn state established | grep :8080 | wc -l
UserParameter=app.queue.length,redis-cli llen task_queue 2>/dev/null || echo 0
UserParameter=app.disk.usage[*],df -P $1 | tail -1 | awk '{print $5}' | tr -d '%'

systemctl restart zabbix-agent2

# Проверка с сервера
zabbix_get -s 192.168.1.20 -k app.connections

Мы настроили триггеры, ориентированные на критичные для розничной сети события:

# Высокая загрузка CPU (более 90% в течение 5 минут)
Name: CPU utilization is too high on {HOST.NAME}
Severity: High
Expression: min(/Linux by Zabbix agent/system.cpu.util,5m)>90

# Диск заполнен более чем на 90%
Name: Disk space is critically low on {HOST.NAME}
Severity: Disaster  
Expression: last(/Linux by Zabbix agent/vfs.fs.size[/,pused])>90

# Сервис не отвечает
Name: {HOST.NAME} is unreachable
Severity: Disaster
Expression: max(/Linux by Zabbix agent/agent.ping,3m)=0

# Мало свободной памяти (менее 10%)
Name: Lack of free memory on {HOST.NAME}
Severity: Warning
Expression: last(/Linux by Zabbix agent/vm.memory.util)>90

# Высокая нагрузка на диск (iowait)
Name: High disk IO wait on {HOST.NAME}
Severity: Warning
Expression: avg(/Linux by Zabbix agent/system.cpu.util[,iowait],10m)>30

Уровни серьёзности настроили с учётом приоритетов клиента: Disaster (касса не работает) вызывает немедленный звонок, High — Telegram с требованием реакции, Warning — для планового обслуживания.

Создали специальный дашборд для видимости всех 12 магазинов на одном экране:

• Problems — список текущих проблем с фильтрацией по серьёзности
• Host availability — карта доступности хостов по магазинам
• Graph (classic) — графики загрузки CPU и памяти кассовых серверов
• Top hosts — топ хостов по загрузке ресурсов
• Map — топологическая карта сети с расположением магазинов

Также создали топологическую карту в Monitoring → Maps со всеми магазинами, офисом и связями между ними. Состояние каждого магазина отображается цветом иконки.

Настроили email через SMTP Яндекса (Alerts → Media types → Email) и создали Telegram-бота для мгновенных оповещений IT-отделу:

curl -s https://api.telegram.org/bot<TOKEN>/getUpdates | python3 -m json.tool

Шаблон информативного сообщения:

Subject: [{TRIGGER.SEVERITY}] {TRIGGER.NAME} on {HOST.NAME}

Body:
Проблема: {TRIGGER.NAME}
Хост: {HOST.NAME} ({HOST.IP})
Серьёзность: {TRIGGER.SEVERITY}
Время: {EVENT.DATE} {EVENT.TIME}

Текущее значение: {ITEM.LASTVALUE}
Описание: {TRIGGER.DESCRIPTION}

Event ID: {EVENT.ID}

Теперь IT-специалист получает Telegram-уведомление за секунды вместо часов ожидания звонка из магазина.

Для каждой подсети настроили правила обнаружения: Data collection → Discovery:

• IP range: 192.168.1.1-254
• Update interval: 1h
• Checks: Zabbix agent, SNMP, ICMP ping

Действия для обнаруженных хостов: автоматическое добавление в группу «Discovered hosts» и привязка шаблона. Новое оборудование в магазине подхватывается автоматически.

Для облачных сред Zabbix 7 поддерживает обнаружение через API: VMware vCenter, AWS CloudWatch, Azure Monitor.

Сетевое оборудование подключили через SNMP:

apt install -y snmp snmp-mibs-downloader

# Проверка доступности SNMP на устройстве
snmpwalk -v2c -c public 192.168.1.1 sysDescr

Для каждого устройства создали хост с SNMP-интерфейсом и привязали соответствующий шаблон:

• Cisco IOS by SNMP — для Cisco
• MikroTik by SNMP — для RouterOS
• Generic by SNMP — универсальный шаблон
• HP Enterprise Switch by SNMP — для HP/Aruba

Шаблоны автоматически обнаружили интерфейсы и создали метрики для каждого порта: трафик, ошибки, состояние, скорость.

На каждом сервере магазина установили Proxy с SQLite:

# Установка
apt install -y zabbix-proxy-sqlite3

# Конфигурация
nano /etc/zabbix/zabbix_proxy.conf

Мы применили следующую конфигурацию:

# Режим работы: 0 — активный
ProxyMode=0

# Адрес Zabbix сервера
Server=zabbix.example.com

# Уникальное имя прокси
Hostname=proxy-office-spb

# Путь к базе данных SQLite
DBName=/var/lib/zabbix/proxy.db

# Частота отправки данных
DataSenderFrequency=5

# Буферы
ProxyLocalBuffer=2
ProxyOfflineBuffer=24

# Процессы сбора данных
StartPollers=10
StartPollersUnreachable=3

systemctl enable --now zabbix-proxy

Для стабильной долгосрочной работы выполнили оптимизации:

Housekeeper — очистка старых данных:

# В zabbix_server.conf
HousekeepingFrequency=1
MaxHousekeeperDelete=10000

Оптимизация PostgreSQL:

# В postgresql.conf
shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 64MB
maintenance_work_mem = 512MB
wal_buffers = 64MB
checkpoint_completion_target = 0.9
random_page_cost = 1.1

Настроили ежедневное резервное копирование:

# Бэкап конфигурации Zabbix
pg_dump -U zabbix --schema-only zabbix > /backup/zabbix_schema_$(date +%Y%m%d).sql

# Бэкап конфигурационных данных
pg_dump -U zabbix -t hosts -t items -t triggers -t actions \
  -t media -t users zabbix > /backup/zabbix_config_$(date +%Y%m%d).sql