Как добавить один шаблон для нескольких э

[olorin]

Здравствуйте.

Есть несколько серверов, на которых работает некий процесс (для простоты пусть это будет nginx). Для шаблона, привязанного к хосту, настроено автоопределение сервиса, что nginx слушает порт 80. Далее к узлу сети подключается шаблон, в котором идет опрос нескольких параметров запросами к IP-сервера к порту 80; также ведется мониторинг логов nginx активным zabbix-агентом.

Все работает отлично, но появился еще один сервер, на котором nginx запущен в нескольких экземплярах; он по-прежнему слушает порт 80, на нескольких IP-адресах, и имеет логи в нескольких местах. Соответственно, мониторить и собирать по ним статистику надо по отдельности.

Создать автоопределение нескольких независимых сервисов, у которых критерием уникальности будет IP-адрес, - не проблема. Но я не понимаю, как настроить, чтобы подключалось несколько экземпляров шаблонов, для мониторинга нескольких независимых экземпляров одного сервиса. Может быть, у кого-то есть практический опыт или идеи реализации такой схемы?

[sadman]

Громоздко, но быстро - lld, прототипы в соотв. аппликейшны и вот это всё.

Без самописного скрипта, который возвращал бы адреса, к которым биндится сервис, не обойтись.

[olorin]

Спасибо за ответ.

Без самописного скрипта, который возвращал бы адреса, к которым биндится сервис, не обойтись.

Да, это само собой.

Громоздко, но быстро - lld, прототипы в соотв. аппликейшны и вот это всё.

Так. Нужно добавить в шаблон обнаружение, что сервис работает на каких-то ip, и элементы данных перенести в прототипы, добавив макросы. Тогда, если обнаружение нашло сервис на ip-адресе, макросом в элемент данных будет подставлен ip-адрес. Если ничего на найдено - будет использоваться ip хоста. С путями - то же самое. Я все правильно понял?

Если не громоздко, но изящно - есть ли еще варианты?

[sadman]

Так. Нужно добавить в шаблон обнаружение, что сервис работает на каких-то ip, и элементы данных перенести в прототипы, добавив макросы. Тогда, если обнаружение нашло сервис на ip-адресе, макросом в элемент данных будет подставлен ip-адрес. Если ничего на найдено - будет использоваться ip хоста. С путями - то же самое. Я все правильно понял?

В целом - да, но если перенести элементы в прототипы, то если ничего в LLD-JSON не вернулось, то никакой дефолтовый IP подставлен не будет.

Т.е., конечно, тут вариантов несколько:
1) LLD возвращает дополнительные IP за исключением основного и одинаковые элементы данных существуют в виде статичных и прототипов;
2) LLD возвращает все IP и правило обнаружения создает всё или ничего.
3) ...

Вобщем, тут по задаче выбирается подход.

Обратите внимание, что в Zabbix 3 есть "Прототип группы элементов данных" https://www.zabbix.com/documentation...evel_discovery). Таким образом можно "раскидать" создаваемые элементы данных по группам, создаваемым в соответствии с каким-нибудь макросом, в который от скрипта обнаружения приходит мнемоническое обозначение сервиса (например - "Service Private", "Service Public", "Service Secure").

Если не громоздко, но изящно - есть ли еще варианты?

У меня - нет. Громоздко - это если для одного хоста такое наворачивать. При масштабировании можно получить выигрыш.

[yukra]

Здравствуйте.

Есть несколько серверов, на которых работает некий процесс (для простоты пусть это будет nginx). Для шаблона, привязанного к хосту, настроено автоопределение сервиса, что nginx слушает порт 80. Далее к узлу сети подключается шаблон, в котором идет опрос нескольких параметров запросами к IP-сервера к порту 80; также ведется мониторинг логов nginx активным zabbix-агентом.

Все работает отлично, но появился еще один сервер, на котором nginx запущен в нескольких экземплярах; он по-прежнему слушает порт 80, на нескольких IP-адресах, и имеет логи в нескольких местах. Соответственно, мониторить и собирать по ним статистику надо по отдельности.

Создать автоопределение нескольких независимых сервисов, у которых критерием уникальности будет IP-адрес, - не проблема. Но я не понимаю, как настроить, чтобы подключалось несколько экземпляров шаблонов, для мониторинга нескольких независимых экземпляров одного сервиса. Может быть, у кого-то есть практический опыт или идеи реализации такой схемы?

я для себя пришел к примерно такому решению: раз в несколько часов zabbix-server на zabbix-agent дергает определенный параметр стандартным способом. На агенте скрипт через userparameter делает примерно следующее:
1) Смотрит в спец. директорию и ищет в ней "файлы с описанием возможных сервисов" (это спец. директория у меня на агент приезжает из общего svn репа, как в прочем и все остальные конфиги агента)
2) По описанию из файла пытается обнаружить у себя этот сервис и в случае обнаружения дергает web-скрипт на сайте заббикса, которому передает список "шаблонов, которые нужно навесить на меня"
3) скрипт на стороне заббикс-сервера сверяет список текущих шаблонов и список нужных шаблонов и "довешивает" нужные шаблоны через API.

В итоге получается некое подобие LLD, но оно не создает айтемы, а вешает шаблоны (а шаблоны уже создают айтемы, в том числе и через обычный LLD).
Если интересно - причешу код и могу поделиться.

но сразу об особенностях:
1) Во первых скрипт на веб-сервере не проводит какую-либо аутентификацию (грубо говоря зная вашу инфраструктуру и имея доступ к curl на хосте можно навесить лишних шаблонов на этот хост, а потом по логах можно так же навешать кому-то по голове)
2) Снимать шаблоны с хоста нельзя (вроде как выглядит логичным и вешать и снимать, но у меня в практике часто бывает что на сервере "подняли еще и службу X", а вот "убрали службу" бывает настолько редко, что я предпочитаю руками убедиться в необходимости отключения мониторинга чего-либо)
3) Как понимаете для доступа к api использует пользователь с полным доступом, хоть я и проверяю параметры, полученные из сети, но чисто потенциально через этот скрипт можно получить доступ как минимум в веб-интерфейс с правами администратора (это я про доступ через веб, при доступе на чтение пароль админа можно просто прочитать в тексте)

Ну и все это безобразие в вашем случае может потребоваться только в случае, если вы хотите "совсем разные" шаблоны вешать. Если же нужно просто снимать одни и те же айтемы с разных nginx-ов на одном хосте, то это конечно лишнее, и описанного выше "обычного" LLD вполне хватит

[olorin]

В целом - да, но если перенести элементы в прототипы, то если ничего в LLD-JSON не вернулось, то никакой дефолтовый IP подставлен не будет.

Т.е., конечно, тут вариантов несколько:
1) LLD возвращает дополнительные IP за исключением основного и одинаковые элементы данных существуют в виде статичных и прототипов;
2) LLD возвращает все IP и правило обнаружения создает всё или ничего.
3) ...

В итоге для своих нужд переписал существующие шаблоны с использованием LLD, перенес элементы данных и триггеры в прототипы. В итоге, схема такая:

1. цепляется шаблон к хосту;
2. через userparameter вызывается скрипт обнаружения;
3. скрипт возвращает JSON-массив, в котором передается макрос с IP-адресом и другой информацией, также массив может содержать пустые значения;
4. шаблон и userparameters для приложения изменены для использования макросов:
   1. в шаблоне используются макросы, полученные из LLD, таким образом опрашиваются только нужные экземпляры;
   2. в скрипте, который производит получает параметрами значения макросов, описаны дефолтные значения (в качестве IP-адреса подключаться к localhost, например).

Спасибо за формирование идеи.

Ну и все это безобразие в вашем случае может потребоваться только в случае, если вы хотите "совсем разные" шаблоны вешать. Если же нужно просто снимать одни и те же айтемы с разных nginx-ов на одном хосте, то это конечно лишнее, и описанного выше "обычного" LLD вполне хватит

В описанной мною задаче требовалось произвести более подробный, что ли, поиск сервисов внутри хоста. А ваше решение я бы назвал "интеллектуальным развертыванием zabbix на хосты сети", когда авторегистрации хостов совсем недостаточно, а сетевого обнаружения... Кстати, а почему не сетевое обнаружение? Вроде, должно подходить. На хостах - какой-нибудь userparameter, возвращающий список сервисов. Добавить его в Обнаружение сети (проверка - zabbix_agent), затем в Действиях в зависимости от полученного значения добавлять узел в группы сети, вешать шаблоны, и пр. Не пробовали?