Настройка мониторинга сервера (Zabbix) для сайта
Zabbix — не «поставил и забыл». Это платформа, которая требует осознанной архитектуры: что мониторить, с какой частотой, какие пороги реально означают проблему, а не просто шум. Типичная установка «по туториалу» даёт 200 триггеров на сервер, половина из которых срабатывают постоянно и через неделю их все отключают.
Здесь описан подход к настройке Zabbix, который работает в production: от выбора схемы развёртывания до конкретных элементов данных и alert-политики.
Архитектура развёртывания
Для одного сайта с несколькими серверами стандартная схема: Zabbix Server + PostgreSQL на отдельной VM, агенты на каждом целевом хосте.
Если серверов больше 20 или они распределены географически — добавляют Zabbix Proxy в каждой зоне. Proxy буферизует данные локально и отправляет на сервер пачками, что снижает нагрузку на центральный сервер и устойчиво к разрывам связи.
[Web server] [DB server] [Cache server]
| | |
zabbix-agent zabbix-agent zabbix-agent
\ | /
\ | /
[Zabbix Proxy (optional)]
|
[Zabbix Server]
|
[PostgreSQL]
|
[Zabbix Frontend]
Минимальные требования для сервера с ~10 хостами: 2 vCPU, 4 GB RAM, 50 GB SSD под базу (с учётом хранения истории на 90 дней).
Установка Zabbix Server
На Ubuntu 22.04:
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-apache-conf 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
StartTrappers=5
CacheSize=128M
HistoryCacheSize=64M
TrendCacheSize=32M
ValueCacheSize=256M
# Хранение истории (дни)
# Переопределяется на уровне элементов данных
Установка агента на целевых серверах
Zabbix Agent 2 (Go-based, более производительный):
# На каждом мониторируемом сервере
apt install -y zabbix-agent2
cat > /etc/zabbix/zabbix_agent2.conf << 'EOF'
Server=<ZABBIX_SERVER_IP>
ServerActive=<ZABBIX_SERVER_IP>
Hostname=web-server-01
# Для active checks — агент сам инициирует соединение
# Полезно когда сервер за NAT
# Разрешить пользовательские параметры
AllowKey=system.run[*]
# Мониторинг процессов
# system.process.num[nginx] и т.д.
EOF
systemctl enable --now zabbix-agent2
Автодобавление хостов через API (при инфраструктуре как код):
import requests
ZABBIX_URL = "http://zabbix.example.com/api_jsonrpc.php"
def zabbix_login(user, password):
resp = requests.post(ZABBIX_URL, json={
"jsonrpc": "2.0",
"method": "user.login",
"params": {"username": user, "password": password},
"id": 1
})
return resp.json()["result"]
def add_host(token, hostname, ip, group_id, template_ids):
resp = requests.post(ZABBIX_URL, json={
"jsonrpc": "2.0",
"method": "host.create",
"auth": token,
"params": {
"host": hostname,
"interfaces": [{
"type": 1, # agent
"main": 1,
"useip": 1,
"ip": ip,
"dns": "",
"port": "10050"
}],
"groups": [{"groupid": group_id}],
"templates": [{"templateid": tid} for tid in template_ids]
},
"id": 2
})
return resp.json()
Шаблоны и элементы данных
Zabbix поставляется с готовыми шаблонами. Для веб-сервера:
- Linux by Zabbix agent — CPU, memory, disk, network, processes
- Nginx by Zabbix agent — active connections, requests/s, status codes
- PostgreSQL by Zabbix agent — connections, transactions, replication lag
- PHP-FPM by Zabbix agent — pool status, slow requests
Подключение шаблонов к хосту через UI: Configuration → Hosts → Templates → Link new templates.
Кастомный элемент данных для мониторинга PHP-FPM через unix socket:
# /etc/zabbix/zabbix_agent2.d/php-fpm.conf
UserParameter=php-fpm.status[*],curl -s --unix-socket /run/php/php8.2-fpm.sock http://localhost/status?json 2>/dev/null
Элемент данных в Zabbix:
- Тип: Zabbix agent
- Ключ:
php-fpm.status[] - Тип информации: Text
- Препроцессинг: JSONPath
$.active processes
Триггеры — реальные пороги
Не копируйте дефолтные триггеры слепо. Вот рабочие пороги для production web-сервера:
CPU:
Предупреждение: avg(/hostname/system.cpu.util,5m) > 75
Критично: avg(/hostname/system.cpu.util,5m) > 90 and avg(/hostname/system.cpu.util,1m) > 90
Память (с учётом кэша):
Критично: last(/hostname/vm.memory.size[pavailable]) < 10
Диск — не процент, а абсолютное значение:
Предупреждение: last(/hostname/vfs.fs.size[/,pfree]) < 15
Критично: last(/hostname/vfs.fs.size[/,pfree]) < 5
Nginx — падение запросов (аномалия):
# Если rps упал в 3 раза по сравнению со средним за последний час
last(/hostname/nginx.requests) < avg(/hostname/nginx.requests,1h) * 0.3
and avg(/hostname/nginx.requests,1h) > 10
Доступность сайта:
last(/hostname/web.test.fail[site-check]) <> 0
Web Scenarios — HTTP мониторинг
Встроенная проверка доступности через HTTP:
Configuration → Hosts → Web → Create web scenario:
Name: Site availability check
Update interval: 60s
Steps:
1. Homepage
URL: https://example.com/
Required status codes: 200
Required string: (что-то уникальное на странице)
Timeout: 15s
2. Health endpoint
URL: https://example.com/health
Required status codes: 200
Required string: ok
Это создаёт автоматические элементы данных: web.test.fail, web.test.time, web.test.error.
Медиа и нотификации
Настройка Telegram-нотификаций через Media Type:
Administration → Media types → Telegram:
Bot token: <your_bot_token>
Chat ID: <your_chat_id>
Action для отправки при триггере:
Name: Notify on PROBLEM
Conditions:
- Trigger severity >= Warning
- Maintenance status not in maintenance
Operations:
Send message to: Admin group
Via: Telegram
Recovery operations:
Send recovery message
Шаблон сообщения, который реально информативен:
{TRIGGER.SEVERITY}: {TRIGGER.NAME}
Host: {HOST.NAME} ({HOST.IP})
Time: {EVENT.TIME} {EVENT.DATE}
Value: {ITEM.LASTVALUE}
{TRIGGER.URL}
Дашборды и визуализация
Для веб-команды стандартный дашборд включает:
- Problem widget — активные проблемы, отсортированные по severity
- Graph widget — CPU/memory overlay для всех web-серверов
- Top hosts — по CPU utilization
- Web monitoring — uptime всех web scenarios
Интеграция с Grafana через Zabbix datasource plugin (alexanderzobnin-zabbix-app):
grafana-cli plugins install alexanderzobnin-zabbix-app
Grafana даёт более гибкую визуализацию и удобнее для построения custom дашбордов, особенно если данные из нескольких источников.
Хранение данных и производительность
Для больших инсталляций Zabbix рекомендует TimescaleDB как extension для PostgreSQL:
-- Миграция существующей базы
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);
-- и для других таблиц history_*
TimescaleDB даёт компрессию ~10:1 и значительно ускоряет агрегатные запросы по временным рядам.
Partitioning через встроенный Housekeeping (Administration → Housekeeping):
- Trend storage: 365 days
- History storage: 90 days (или меньше для high-frequency метрик)
Типичные сроки работ
Базовая установка с мониторингом 3-5 серверов (агенты, шаблоны, основные триггеры, Telegram-нотификации): 1 рабочий день.
Полноценная настройка для production-окружения с кастомными элементами данных, web scenarios для всех критичных URL, настроенными дашбордами и AlertManager-интеграцией: 3-5 дней.
Миграция с существующего мониторинга или интеграция с Grafana как единым фронтендом: дополнительно 1-2 дня.