Как обойти невозможность использования макроса в имени айтема?

[csr]

День добрый

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

Какое-то время назад убрали (давно deprecated) возможность использования пользовательского макроса в имени айтема.

Как это обойти? Хочется видеть что-то вроде "CPU usage by realprocessname.exe", а не безликое "CPU usage by proc1"

[csr]

Всем спасибо. Плакаться это не наш вариант. Переделал через lld (хотя так не хотелось )

Сделал как предлагал Alex_UUU: Discovery rule, Type - script, там разбираю макросы, в которых значения разделены запятыми. Таким образом и один шаблон для нескольких процессов и правильные названия айтемов. Если кому интересно - могу поделиться примером

[Kos]

Разработчики убрали этот функционал (в версии 6.0), поскольку он затрудняет отображение в веб-интерфейсе (например, экран "Latest data"), и при этом не смогли найти реальных сценариев (use cases), где он был бы так уж необходим.
Хотя для меня, честно говоря, это выглядит, скорее, отговоркой: ведь те же пользовательские макросы по-прежнему нормально раскрываются, скажем, в именах триггеров.
В большинстве случаев имя элемента данных можно прописать статически без необходимости использования макросов (что и рекомендовалось делать).
В вашем случае, скорее всего, в шаблоне мониторится некий процесс (например, сервер Apache2), а в макросе задан конкретный путь к бинарнику либо набор параметров, чтобы иметь возможность подкорректировать на конкретном хосте (скажем, "/usr/sbin/httpd-prefork", "/usr/local/sbin/httpd-prefork" или "/usr/sbin/httpd-event"). Но тогда в имени элемента данных необязательно указывать именно этот конкретный путь, достаточно указать что-то достаточно общее вроде "CPU usage by Apache2".

Ещё одно стандартное место, где раньше активно использовались позиционные макросы ($1, $2 и т.д.) - это элементы данных, генерируемые из прототипов правилами LLD.
Была распространённая практика указывать что-то вроде следующего:

Name: Filesystem $1: Free disk space
Key: vfs.fs.size[{#FSNAME},free]

Но в этом случае это элементарно "лечится" подстановкой LLD-макроса вместо позиционного в прототипе элемента данных:

Filesystem {#FSNAME}: Free disk space

[csr]

Есть шаблон(ы), который используем для мониторинга совсем разных процессов. В основном, или "больных" или "важных". Процессы разные и одинаковых шаблонов несколько (чтобы на одном хосте по-простому могли мониторить несколько процессов).
Как здесь статически сделаешь имя процесса? Это уже не шаблон будет, а ручной набор настроек под каждый процесс. А с одного хоста делать графики по proc1, proc2 не хочется, хочется видеть говорящие названия - apache, nginx и пр.

Как правильно и не по-колхозному решить данную задачу?

[Kos]

Как правильно и не по-колхозному решить данную задачу?

Я вижу два способа:

• плакаться в жилетку разработчикам, открывая кейс на support.zabbix.com, описывая там на английском языке свой сценарий и объясняя, почему убранный функционал вам так необходим - глядишь, и прислушаются (особенно, если найдутся ещё те, кто готов вас в этом поддержать);
• переделать этот шаблон на использование LLD. Идея такая:
  • в макросе на уровне шаблона задаётся список процессов (одной строкой через какой-то разделитель - например, запятую);
  • на уровне хоста этот макрос можно переопределить;
  • шаблон содержит одно правило LLD, в котором через шаг препроцессинга JavaScript значение этого макроса преобразуется в JSON нужного вида;
  • далее на основе этого JSON-а из прототипов генерируются нужные элементы данных в нужном количестве. У каждого из них название конкретного процесса будет и в ключе, и в имени.

[Alex_UUU]

Name: Filesystem $1: Free disk space
Key: vfs.fs.size[{#FSNAME},free]​

Использование $1 - зло т.к. они не раскрывались на вкладках "Последние данные" и невозможно было сделать поиск. Макросы {#Макрос} раскрывались прекрасно.
Я обычно однотипные вещи делаю через обнаружение. Где тип - "скрипт", который нужный json и далее - по накатанной с макросами.

[csr]

Всем спасибо. Плакаться это не наш вариант. Переделал через lld (хотя так не хотелось )

Сделал как предлагал Alex_UUU: Discovery rule, Type - script, там разбираю макросы, в которых значения разделены запятыми. Таким образом и один шаблон для нескольких процессов и правильные названия айтемов. Если кому интересно - могу поделиться примером