Настройка Zabbix для мониторинга серверов

Пароль пропиши в /etc/zabbix/zabbix_server.conf в параметре DBPassword. На проде пароль храни в секрет-менеджере, а не в конфиге в открытом виде — но для лабораторного стенда сойдёт и так. Не забудь также проверить параметр DBHost: если MySQL стоит на том же srv-zbx01, можно оставить localhost, но если база вынесена на отдельный сервер (что разумно при большом количестве хостов под мониторингом), сюда идёт её IP-адрес.

Отдельный момент — размер истории. По умолчанию Zabbix хранит "сырые" данные (history) 90 дней, а агрегированные тренды (trends) 365 дней. Для стенда на пару десятков хостов это некритично, но если планируешь мониторить сотни серверов, стоит сразу подумать о партиционировании таблиц MySQL или переходе на TimescaleDB как бэкенд для истории — иначе диск на srv-zbx01 будет расти быстрее, чем ты ожидаешь.

Шаг 3. Запуск сервера и фронтенда

systemctl restart zabbix-server zabbix-agent nginx php8.1-fpm
systemctl enable zabbix-server zabbix-agent nginx php8.1-fpm

Открываем в браузере http://192.168.10.10/zabbix (это адрес srv-zbx01) и проходим мастер установки: он сам проверит соединение с MySQL и создаст файл конфигурации фронтенда. Логин по умолчанию — Admin, пароль — zabbix. Первым делом после входа меняем этот пароль.

Шаг 4. Подключаем агентов

Теперь добавим в мониторинг реальный сервер, например srv-web01 с адресом 192.168.10.21. На нём ставим агент и указываем, куда слать данные.

apt install -y zabbix-agent

sed -i 's/^Server=127.0.0.1/Server=192.168.10.10/' /etc/zabbix/zabbix_agentd.conf
sed -i 's/^ServerActive=127.0.0.1/ServerActive=192.168.10.10/' /etc/zabbix/zabbix_agentd.conf
sed -i 's/^Hostname=Zabbix server/Hostname=srv-web01/' /etc/zabbix/zabbix_agentd.conf

systemctl restart zabbix-agent
systemctl enable zabbix-agent

В веб-интерфейсе Zabbix идём в Data collection → Hosts → Create host, указываем имя srv-web01, группу узлов (например, "Linux servers") и IP-адрес агента. Привязываем шаблон Linux by Zabbix agent — он сразу принесёт метрики CPU, памяти, диска и сети без ручной настройки.

Обрати внимание на два разных режима работы агента: пассивный (сервер сам опрашивает агента по расписанию) и активный (агент сам присылает данные серверу). Активный режим лучше подходит, если между srv-zbx01 и хостами есть NAT или ты не хочешь открывать порт 10050 на приём — агенту достаточно исходящего соединения на 10051. Переключается это в самом шаблоне: большинство официальных шаблонов Zabbix уже используют активные проверки.

Группировка хостов и организация

Когда хостов становится больше десятка, плоский список превращается в кашу. Заведи host groups по смыслу: "Web servers", "Database servers", "Monitoring", "Network devices". Один хост может входить сразу в несколько групп — это удобно, если, например, srv-db01 нужно одновременно видеть и в группе "Database servers", и в группе "Production". На группы потом завязываются права доступа пользователей и области видимости на дашбордах.

Макросы и переиспользуемые пороги

Жёстко прописывать в каждом триггере "если диск заполнен больше 90%" — плохая практика: для одного сервера порог в 90% нормален, а для другого, где логи сыпятся быстрее, критично уже при 80%. Здесь помогают пользовательские макросы. На уровне хоста или шаблона задаётся макрос вида {$DISK_CRIT_WARN} со значением по умолчанию, а на конкретном хосте его можно переопределить в разделе Macros карточки хоста. Триггер при этом ссылается не на число, а на макрос, и логика становится гибкой без копирования триггеров под каждый сервер.

Шаг 5. Настройка триггеров и уведомлений

Голые графики никого не разбудят ночью — нужны триггеры. Большинство базовых триггеров уже приезжают вместе с шаблоном (например, "Disk space is low" или "High CPU utilization"). Остаётся настроить канал уведомлений. Для Telegram это делается через Media Type:

1. В разделе Alerts → Media types включаем встроенный тип Telegram и указываем токен бота.
2. В профиле пользователя (Users → Users → твой аккаунт → Media) добавляем медиа с этим типом и своим chat ID.
3. В Alerts → Actions → Trigger actions создаём действие, которое отправляет сообщение при срабатывании триггера с severity выше "Warning".

Дальше остаётся только добавлять новые хосты по тому же сценарию: srv-db01, srv-mail01, srv-mon01 и так далее — каждый цепляется к srv-zbx01 через агент и типовой шаблон.

Дашборды и графики

Список триггеров хорош для реагирования на инциденты, но для ежедневного контроля состояния инфраструктуры удобнее дашборд. В разделе Dashboards можно собрать виджеты: карту проблем, топ хостов по загрузке CPU, графики сетевого трафика, статус доступности служб. Один дашборд стоит держать открытым на общем мониторе в серверной или в отдельной вкладке браузера — беглый взгляд на цветовую индикацию сразу показывает, всё ли в порядке в сети 192.168.10.0/24.

Мониторинг доступности служб

Кроме метрик CPU и памяти, Zabbix умеет проверять доступность конкретных сервисов simple-чеками — без установки агента вообще. Например, проверить, что на srv-web01 отвечает HTTP:

Item type: Simple check
Key: net.tcp.service[http,192.168.10.21,80]

Такие проверки полезны для внешних по отношению к Zabbix объектов — принтеров, коммутаторов, устройств, где агент поставить нельзя или не нужно. Для SNMP-совместимого оборудования (свитчи, ИБП) есть отдельный тип элемента данных SNMP agent, который опрашивает нужные OID без установки какого-либо софта на само устройство.

Права доступа и роли пользователей

Если с Zabbix работает не один человек, стоит сразу развести роли. В разделе Users → User roles задаются права: администратор инфраструктуры видит и настраивает всё, а дежурный инженер техподдержки — только читает дашборды и подтверждает проблемы (acknowledge), без права менять конфигурацию триггеров. Права на конкретные группы хостов настраиваются в разделе Users → User groups, в разделе Host permissions — это удобно, если разные команды отвечают за разные сегменты сети.

Автоматическая регистрация новых хостов

Когда серверов становится много, вручную создавать каждый host в интерфейсе утомительно. Zabbix умеет автоматически регистрировать новые агенты по правилу в Data collection → Discovery: указываешь диапазон 192.168.10.0/24, порт агента 10050, и все новые машины, которые появятся в сети и ответят на опрос, попадут в мониторинг сами — останется только привязать к ним нужные шаблоны через action.

Настраивается это в два этапа. Сначала создаётся сам discovery rule с диапазоном IP и методом проверки (например, ICMP ping плюс проверка порта агента). Затем в разделе Alerts → Actions → Discovery actions создаётся действие: "если хост обнаружен и отвечает на порту 10050, добавить его в группу Linux servers и привязать шаблон Linux by Zabbix agent". После этого любой новый сервер с установленным и настроенным агентом появится в мониторинге без единого клика в интерфейсе — тебе останется только раскатать сам агент через Ansible, о чём мы поговорим в одной из следующих статей.

Есть и более тонкий инструмент — low-level discovery (LLD) на уровне отдельного хоста. Он позволяет автоматически находить не сами хосты, а объекты внутри них: диски, сетевые интерфейсы, точки монтирования файловых систем. Официальный шаблон Linux by Zabbix agent уже использует LLD, поэтому если на srv-web01 позже добавится новый раздел диска, Zabbix обнаружит его сам в течение получаса и начнёт собирать по нему метрики — без правки конфигурации.

Обслуживание и плановые окна

Отдельная практическая деталь, про которую часто забывают: при плановых работах — обновлении ядра, перезагрузке, миграции — Zabbix продолжает честно фиксировать "хост недоступен" и слать алерты, хотя ты и сам знаешь, что сервер сейчас выключен намеренно. Чтобы не получать ложные срабатывания и не приучать команду игнорировать уведомления, в разделе Data collection → Maintenance создаётся окно обслуживания: указывается хост или группа хостов, период времени и режим — "без сбора данных" или "собирать данные, но не создавать проблемы". Второй вариант обычно удобнее: график не прерывается, а вот в списке активных проблем и в уведомлениях эти события подавляются.

Частые ошибки и как их избежать

• Забыли открыть порты в firewall. Zabbix Server слушает 10051, агент — 10050. Если между srv-zbx01 и остальными хостами стоит фильтрация, данные просто не дойдут, а в интерфейсе хост будет висеть серым. Проверяется одной командой: telnet 192.168.10.10 10051 с агента.
• Не совпадает Hostname в конфиге агента и в веб-интерфейсе. Zabbix сверяет их буквально посимвольно, регистр важен. Если в конфиге написано srv-web01, а в интерфейсе создан хост Srv-Web01 — связи не будет, и агент будет отдавать "unsupported item" на пустом месте.
• Один Zabbix Server без резервирования истории. База MySQL растёт быстро, особенно если оставить хранение истории по умолчанию (90 дней для всех метрик). Настрой партиционирование или housekeeping под свои реальные потребности, иначе через полгода диск на srv-zbx01 неожиданно закончится.

Автор — Команда IT-Pages