Как правильно создать шаблон для однотипной проверки 1..n количества показателей

[csr]

День добрый

Как правильно создать шаблон для однотипной проверки 1..n количества показателей, когда n может быть разным, а количество этих показателе заранее (на этапе проектирования шаблона) не известно?

Например, необходимо следить за определенным процессом: его память, загрузка. В таком случае, подготавливается шаблон, где создаются айтемы, триггеры и пр. Для унификации используется макрос с именем процесса мониторинга.

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

Как правильно подходить к таким задачам?

[Kos]

Как правильно подходить к таким задачам?

Использовать низкоуровневое обнаружение (LLD).

[csr]

Есть понимание, что такое lld, но как его применить здесь - не совсем понятно. У меня нет понятия поиска/обнаружения чего-то. Мне надо вручную указать, что для данного узла надо мониторить два конкретных процесса, а для другого - 5 других, заранее известных процессов. Можете объяснить, как воспользоваться lld для этого?

[Victor Vislobokov]

Видимо нет у вас понимания, что такое LLD


Давайте на примере. disclamer: я не претендую, что данный пример является best-practice, но он прост и нагляден.

Однажды у меня возникла необходимость мониторить состояние служб в системе через systemd. Как вы уже писали, одну службу можно замониторить простым шаблоном, А если их 10? Вот и пришлось написать маленький LLD.
1. На стороне хоста создан файл /var/lib/zabbix/data/systemd.status где в каждой строчке находится имя службы, которую надо мониторить.
2. На стороне хоста создан файл конфигурации /etc/zabbix/zabbix-agent.d/systemd.conf следующего содержимого:

UserParameter=systemd.activestate.discovery, echo '{"data":['; FL=0; cat /var/lib/zabbix/data/systemd.status|while read a; do if [ $FL -eq 1 ]; then echo ","; fi; echo "{\"{#SERVICE}\":\"$a\"}"; FL=1 ;done; echo ']}'
UserParameter=systemd.activestate[*], /usr/bin/systemctl show '$1'|grep -e '^ActiveState='|cut -f2 -d '='

который выполняет как discovery для LLD, так и получает данные по состоянию службы.

На Zabbix Server создан шаблон, в котором в качечестве ключа для правила обнаружения используется: systemd.activestate.discovery, который в свою очередь возвращает JSON нужный для LLD, а также в данном правиле обнаружения создан прототип данных:
Состояние службы {#SERVICE} с ключом: systemd.activestate[{#SERVICE}]. Также добавлен прототип триггера, который "зажигает лампочку" если возвращаемое значение отлично от active

Вот собственно и всё. Надо мне одну службу мониторить - пишу в файл /var/lib/zabbix/data/systemd.status одну службу, надо десять - пишу десять. Шаблон один, всё работает.

[csr]

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

Например есть несколько совсем простых NAS. На всех разное количество шар (1-5 штук), на каждую шару свой логин/пароль. Как поступить в таком случае? Делать на каждом насе файл с другими шарами и их паролями - ну костыли же, да и не безопасно.

Или по-другому: мониторится группа объектов, на которых есть однотипные объекты мониторинга, но их количество может быть разным. Что-то положить "в объект" мониторинга нельзя. Какие бэст практикс в данном случае?

[Victor Vislobokov]

Если у вас Zabbix 5.0, то можно так извратится:
Вы можете сделать правило обнаружения на любой ключ (да хоть system.uptime), а потом воспользоваться препроцессингом и запилить JavaScript, который вернёт вам LLD JSON в котором вы можете указать все необходимые для LLD данные.

[csr]

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

[Hamardaban]

…. или сразу использовать тип эд «скрипт» - далее так же JS генерящий json …

[csr]

…. или сразу использовать тип эд «скрипт» - далее так же JS генерящий json …

Познаний именно в заббиксе не очень много, чтобы понять мысль до конца. Создаем item, тип скрипт. А дальше как будем создавать шаблонно проверки с графиками и пр? Из JS мы можем это сделать?

[Victor Vislobokov]

Вы создаёте элемент данных, который будет использоваться для автообнаружения. Ключ можно спросить любой, например system.uptime. Затем для этого элемента данных вы переходите на вкладку "Предобработка" и там добавляете JavaScript. Из кода javascript вы можете вернуть совершенно любое значение (главное чтобы тип совпадал с элементом данных), вот и пишите скрипт так, чтобы он возвращал JSON для LLD. А прототипы элементов данных и прототипы графиков вы будете уже создавать обычным образом руками, используя в качестве параметров макросы LLD, значения в которые будут подставляться из JSON который вы вернёте через JavaScript

[Victor Vislobokov]

…. или сразу использовать тип эд «скрипт» - далее так же JS генерящий json …

У меня в 5.0 у элементов данных нет типа скрипт.

[Hamardaban]

с 5.2 появился