Вот прошло уже 2 недели с появления новой версии Zabbix, а именно, версии 6.4.0. И поскольку новым версиям посвещено довольно мало статей, а интерфейс и логику работы они поменяли прямо очень сильно, я решил написать кратенькую инструкцию как с актуальной на данный момент времени вообще жить. Сейчас начнём с основ, а там посмотрим на реакцию публики. Итак...

Собственно, установка

Тут всё просто. Советую воспользоваться официальным гайдом.

Только обратите внимение, что на этой странице в пункте 1 надо выбрать то, что соответствует вашим пожеланиям, в зависимости от выбора каждого пункта инструкция будет изменяться. Я предпочитаю использовать Zabbix в комплекте с Postgres, потому дальнейшие советы будут про него.

Еще для установки на восьмёрку придётся обновить версии пары пакетов относительно штатных системных, иначе установка пройдёт успешно, но потом ничего работать не будет:

dnf install -y epel-release
# Устанавливаем сторонний репозиторий, содержащий нужные нам версии php
dnf install -y https://rpms.remirepo.net/enterprise/remi-release-8.rpm

dnf module reset php
dnf module enable php:remi-7.4 -y
dnf -qy module disable postgresql
dnf install -y postgresql15 postgresql15-server

После установки необходимых пакетов и создания базы данных нужно зайти в конфиг сервера /etc/zabbix/zabbix_server.conf и внести некоторые изменения, я ограничился следующими:

# Данные для подключения к базе, должны соответствовать тому, 
# что использовалось при установке базы:
DBName=zabbix
DBUser=zabbix
DBPassword=password

# Параметры, отвечающие за быстродействие, оптимизированы под меня
StartDiscoverers=10
StartHTTPPollers=10
StartVMwareCollectors=5
VMwareCacheSize=32M
VMwareTimeout=120

StatsAllowedIP=127.0.0.1,::1,2001:db8::/32,zabbix.your-company.ru

Сохраняем изменения, перезагружаем сервер

systemctl restart zabbix-server.service

… и выполняем первый вход через веб, в процессе которого надо будет указать параметры подключения к базе. А потом еще зайти в интерфейс и сменить пароль администратора с Admin/zabbix на что-нибудь более безопасное.

Если почему-то веб-интерфейс не открывается, то «чиним» фаерволл:

firewall-cmd --add-service=http --permanent
firewall-cmd --add-service=https --permanent
firewall-cmd --add-service=zabbix-agent --permanent
firewall-cmd --add-service=zabbix-server --permanent
firewall-cmd --reload

Настройка

А дальше начинается самое интересное… Если вы ранее работали с более старой версией (как например я, который до этого использовал версию 4.5), то интерфейс вы можете не узнать вообще.

Для начала зайдём в Data Collection — Discovery. Тут нам нужно пока 2 правила, первое зададим так:

Data Collection — Discovery
Data Collection — Discovery

Это правило позволит нам обнаруживать все пингующиеся узлы в сети. Если сетей нужно несколько, пишем их через запятую.

Далее, создаём второе правило, которое позволит нам находить все узлы с установленным Zabbix-агентом:

Теперь, если мы зайдём в Monitoring — Discovery, то мы уже увидим какие-то найденные узлы, но сверху можно выбрать конкретное Discovery rule, применить его и мы узнам, какой именно узел, подпадающий под это правило, находится в каком состоянии:

Отличие живых узлов от мертвых
Отличие живых узлов от мертвых

Первые строки соответствуют узлам в статусе «доступен» и отображают непрерывное время доступности, последние же соответствуют узлам в статусе «не доступен» и отображают время недоступности.

Узлы, находящиеся тут, это все узлы, активность которых Zabbix зафиксировал. Реального сбора с них вполне может не идти!

Далее, устанавливаем заббикс-клиент на узел, который мы хотим мониторить. Для этого на каком-то сервере точно также добавляет репозиторий, устанавливаем пакет zabbix-agent, после чего вносим правки в конфиг и перезапускает сервер. В конфиге я лично ограничусь следующими необходимыми и достаточными мне на первое время правками:

Server=zabbix.yourcompany.ru
ServerActive=zabbix.yourcompany.ru
#Hostname=Zabbix server
HostnameItem=system.hostname
HostMetadata=Linux

Строчку Hostname надо убрать любым способом, например закомментировать как в моем примере. Конечно, вы можете указать имя сервера и напрямую (и тогда не указывать HostnameItem), но на мой взгляд это неудобно потому, что тогда каждый конфиг будет уникальным, в данном же случае, все конфиги всех серверов оказываются строго идентичными, благодаря чему их можно раскладывать централизованно например при установке через ansible или любой другой механизм. А имя сервера будет браться из его собственного имени хоста, для работы с которым существует две удобные команды:

Однако, пока новый агент в списке доступных серверов не появится. И чтобы это исправить надо произвести еще несколько действий. Во-первых, заходим в "Alerts-Action-Autoregistration actions", создаём новое действие («Create Action» в правом верхнем углу), которое по наличию в Metadata слова "Linux" будет добавлять хост в группу "Linux Servers", при этом там создаём условие ("Add" в поле "Condition")

А после нажатия кнопки сохранения ("Add") переходим на вкладке "Operations" и там также жмём "Add", добавляем соответствующее действие и опять сохраняем.

Тут кстати важно заметить, что в отличие от старых версий, сейчас есть возможность добавлять узлы не только по метаданным, но также по PSK-ключам, что конечно гораздо безопаснее и о чём подробнее вы можете почитать тут: https://www.zabbix.com/documentation/current/en/manual/discovery/auto_registration#secure-autoregistration

Я же не буду на этом останавливаться потому, что если сервер находится в закрытой корпоративной сети, что является типовой схемой применения системы мониторинга, такие меры безопасности на мой взгляд являются избыточными.

Во-вторых, заходим в "Alerts-Action-Discovery actions", там создаём новое "Discovery action" примерно с такими условиями, как на картинке выше и примерно с такими действиями, как на картинке ниже.

И опять видим что-то новое! Что за «Set host inventory mode?»- спросите вы — Оказывается, если раньше правила автоопределения просто работали, то сейчас мало того, что их поделили на 2 группы, так еще по умолчанию их выполнение не может добавить узел в Inventory! И исправить эту ситуацию можно одним из двух путей: либо через дополнительный пункт в действиях правила автоопределения, как на изображении выше, либо через смену поведения по-умолчанию, которая производится в Administration-General-Other-Default host inventory mode.

Теперь те Linux-сервера, на которых установлен Zabbig agent, будут автоматически добавляться в Inventory hosts, хотя и не сразу… В начале узел должен пропинговаться и стать «Доступен», потом к нему попытается сходить правило Autoregistration action, оно уточнит, точно ли агент настоящий, потом хост он будет добавлен в список узлов Data collection-Hosts, потом к нему будет применено Discovery action и только после этого узел появится в Inventory и начнёт отображаться его доступность. При параметрах, которые приведены в примере, это должно занять менее полутора часов.

Если статья окажется интересна и наберёт положительные отзывы, я напишу как подружить Zabbix с VmWare ESXi.

А если будут просто какие-то пожелания или возражения -- пишите, с удовольствием исправлю. Я -- не частый автор статей для Хабра, потому с большим вниманием отнесусь к критике и постараюсь исправить возможные ошибки. Рука не набита, как говорится.

Комментарии (2)


  1. vldmrmlkv
    00.00.0000 00:00

    А если есть zabbix proxy то может быть ещё дольше и нужно контролировать, что добавился. Если это несколько серверов то проще вручную сделать. Ещё можно ускорить процесс установив агент заранее в шаблон, по которому, наверняка, создается новый сервер. А чтобы не ждать я пришёл к тому, что можно использовать Zabbix API + Python и добавлять сервера скриптом, что гарантрует добавление сервера даже если агент ещё не установлен и если все ок, нет проблем с сетью, файрволами на хосте и т.п. агент определяется сразу. И так быстрее. Но не всегда сервера создаются по шаблону и агенты нужно обновлять - для этого можно использовать Ansible, вести списки серверов в инвентари файле и запускать это всё в Gitlab, там же и контролировать процесс.


    1. nioliz Автор
      00.00.0000 00:00

      Я считаю, что заббикс во многих случаях должен дополняться графаной. В графане метрики собирают программисты для отладки своего ПО, в заббиксе метрики собираются для админов, чтобы искать проблемы инфраструктуры. И если метрики программистов нужны им сразу, то метрики админов обычно могут подождать не то, что пару часов, но и пол дня. Поэтому именно ускорять процесс специально я для себя смысла не вижу. Но если бы захотел, я бы снизил таймауты обновления скажем до 10 минут и получал бы добавленный сервер за 20.

      А так, для меня автообнаружение сервера является критерием правильной настройки всей цепочки. Если оно не работает, возможно сервер не получает каких-то данных, необходимых для добавления хоста в конфигурацию?

      Но если всё же хочется подойти к ситуации с той стороны и жестко использовать ансибл, советую посмотреть вот сюда:

      https://github.com/ansible-collections/community.zabbix

      Мы в своё время его изучали, продукт интересный, но под наши бизнес-процессы не подошёл, а Вам может и зайдёт :).