Вот прошло уже 2 недели с появления новой версии Zabbix, а именно, версии 6.4.0. И поскольку новым версиям посвещено довольно мало статей, а интерфейс и логику работы они поменяли прямо очень сильно, я решил написать кратенькую инструкцию как с актуальной на данный момент времени вообще жить. Сейчас начнём с основ, а там посмотрим на реакцию публики. Итак... Тут всё просто. Советую воспользоваться официальным гайдом. Только обратите внимение, что на этой странице в пункте 1 надо выбрать то, что соответствует вашим пожеланиям, в зависимости от выбора каждого пункта инструкция будет изменяться. Я предпочитаю использовать Zabbix в комплекте с Postgres, потому дальнейшие советы будут про него. Еще для установки на восьмёрку придётся обновить версии пары пакетов относительно штатных системных, иначе установка пройдёт успешно, но потом ничего работать не будет:  После установки необходимых пакетов и создания базы данных нужно зайти в конфиг сервера /etc/zabbix/zabbix_server.conf и внести некоторые изменения, я ограничился следующими:  Сохраняем изменения, перезагружаем сервер  … и выполняем первый вход через веб, в процессе которого надо будет указать параметры подключения к базе. А потом еще зайти в интерфейс и сменить пароль администратора с Admin/zabbix на что-нибудь более безопасное.   Если почему-то веб-интерфейс не открывается, то «чиним» фаерволл: А дальше начинается самое интересное… Если вы ранее работали с более старой версией (как например я, который до этого использовал версию 4.5), то интерфейс вы можете не узнать вообще.   Для начала зайдём в Data Collection — Discovery. Тут нам нужно пока 2 правила, первое зададим так: Это правило позволит нам обнаруживать все пингующиеся узлы в сети. Если сетей нужно несколько, пишем их через запятую. Далее, создаём второе правило, которое позволит нам находить все узлы с установленным Zabbix-агентом: Теперь, если мы зайдём в Monitoring — Discovery, то мы уже увидим какие-то найденные узлы, но сверху можно выбрать конкретное Discovery rule, применить его и мы узнам, какой именно узел, подпадающий под это правило, находится в каком состоянии: Первые строки соответствуют узлам в статусе «доступен» и отображают непрерывное время доступности, последние же соответствуют узлам в статусе «не доступен» и отображают время недоступности. Узлы, находящиеся тут, это все узлы, активность которых Zabbix зафиксировал. Реального сбора с них вполне может не идти! Далее, устанавливаем заббикс-клиент на узел, который мы хотим мониторить. Для этого на каком-то сервере точно также добавляет репозиторий, устанавливаем пакет zabbix-agent, после чего вносим правки в конфиг и перезапускает сервер. В конфиге я лично ограничусь следующими необходимыми и достаточными мне на первое время правками: Строчку 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. А если будут просто какие-то пожелания или возражения -- пишите, с удовольствием исправлю. Я -- не частый автор статей для Хабра, потому с большим вниманием отнесусь к критике и постараюсь исправить возможные ошибки. Рука не набита, как говорится.  devops