Налаштування моніторингу сервера (Zabbix) для вашого сайту
Zabbix — це не "встановив і забув". Це платформа, яка потребує обдуманої архітектури: що моніторити, як часто, які пороги дійсно означають проблему, а не просто шум. Типова установка "за туторіалом" створює 200 тригерів на сервер, половина з яких спрацьовує постійно, і через тиждень їх усі вимикають.
Цей посібник описує підхід до налаштування Zabbix, який працює у production: від архітектури розгортування до конкретних елементів та політик алертів.
Архітектура розгортування
Для одного сайту з декількома серверами стандартна схема: Zabbix Server + PostgreSQL на виділеній VM, агенти на кожному цільовому хості.
Для більше ніж 20 серверів або географічно розподіленої інфраструктури додайте Zabbix Proxy в кожній зоні. Proxy буферизує дані локально і відправляє їх на сервер партіями, зменшуючи навантаження на центральний сервер і будучи стійким до розривів з'єднання.
[Веб-сервер] [БД сервер] [Кеш сервер]
| | |
zabbix-agent zabbix-agent zabbix-agent
\ | /
\ | /
[Zabbix Proxy (опціонально)]
|
[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
# Для активних перевірок — агент сам ініціює з'єднання
# Корисно коли сервер за NAT
# Дозволити користувацькі параметри
AllowKey=system.run[*]
# Моніторинг процесів
# system.process.num[nginx] тощо
EOF
systemctl enable --now zabbix-agent2
Автоматичне додавання хостів через API (для infrastructure-as-code):
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, пам'ять, диск, мережа, процеси
- Nginx by Zabbix agent — активні з'єднання, запити/с, коди статусу
- PostgreSQL by Zabbix agent — з'єднання, транзакції, лаг реплікації
- PHP-FPM by Zabbix agent — статус пулу, повільні запити
Посилання шаблонів до хосту через 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:
- Type: Zabbix agent
- Key:
php-fpm.status[] - Information type: Text
- Preprocessing: JSONPath
$.active processes
Тригери — реальні пороги
Не копіюйте сліпо дефолтні тригери. Ось робочі пороги для production веб-сервера:
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 для всіх веб-серверів
- Top hosts — за CPU utilization
- Web monitoring — uptime для всіх web scenarios
Інтеграція з Grafana через Zabbix datasource plugin (alexanderzobnin-zabbix-app):
grafana-cli plugins install alexanderzobnin-zabbix-app
Grafana забезпечує більш гнучку візуалізацію та зручна для побудови користувацьких дашбордів, особливо якщо дані з кількох джерел.
Збереження даних та продуктивність
Для великих інсталяцій Zabbix рекомендує TimescaleDB як розширення для 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 днів
- History storage: 90 днів (або менше для high-frequency метрик)
Типові розклади робіт
Базова установка з моніторингом 3-5 серверів (агенти, шаблони, основні тригери, Telegram-сповіщення): 1 робочий день.
Повноцінне налаштування для production-середовища з користувацькими елементами, web scenarios для всіх критичних URL, налаштованими дашбордами та AlertManager-інтеграцією: 3-5 днів.
Мігрування з існуючого моніторингу або інтеграція з Grafana як єдиним фронтендом: додатково 1-2 дні.