Базовая настройка Zabbix 6.4.0 под CentOS 8 / Rocky Linux 8

Kate

Administrator
Команда форума
Вот прошло уже 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-агентом:

59a3d425516a2b9839445bb28d32e94c.png

Теперь, если мы зайдём в 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 или любой другой механизм. А имя сервера будет браться из его собственного имени хоста, для работы с которым существует две удобные команды:

37b5559136d268c272b3981a53011898.png

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

f561ce0fa4033c4794a8ca315f9f5ab3.png

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

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

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

95865e0d05222f6b463e15cb40fee1fe.png

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

eb297bf3348f0046da0dd5e4340385b9.png

И опять видим что-то новое! Что за «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 и начнёт отображаться его доступность. При параметрах, которые приведены в примере, это должно занять менее полутора часов.

 
Сверху