Good day.

Scenario 1:

On active only agent, if user wishes to run some API logic (to achieve automation) via item, they need to use a rather hacky way. Of course, they could set some trigger expression resulting in informational or not classified event and have trigger action handle that but doing it without an event seems to cumbersome.

One might think that a script item would be ideal choice to achieve this as it can take built-in macros as parameters and execute javascript on those. The issue here is that usually that host with active agent is monitored via proxy and that script item will be executed by that proxy and not the server, thus the API call will fail, unless that proxy has backwards connectivity to the Zabbix Server and that may not be the case in isolated environments.

Another good choice appears to be choosing a calculated item, which - as per docs - is always executed by the Zabbix Server and has javascript preprocessing available. Again, unfortunately, for some unknown reason, javascript preprocessing does not resolve built-in macros inside that javascript preprocessing, so no access to {HOST.HOST}.

Only workaround seems to be to create a script item, pass in {HOST.HOST} as a parameter and return that parameter as the value. Then, create a calculated item that checks the key of the script item and has therefore access to the value inside javascript preprocessing, where the API logic can finally be ran against the current host.

Two proposals here:

• allow user to choose whether the script item should be executed on the Zabbix Server or not
• allow built-in macros to be resolved within calculated items

Scenario 2:

Application host discovered from host prototype on OS host needs the same data about discovery (services, filesystems, ...). It seems redundant to need to create separate item for the same discovery key on the application host, if a discovery value from that same key is already returned from the parent (OS) host.

One would think that using dependent item would be a good choice for this case only to find that dependent items can depend only on items on the same host.Another approach would be to store LLD macro that contains OS host's {HOST.HOST} macro's value inside the user macro on the host prototype and create a calculated item, which takes that user macro in the place of host (ex: last(/{$PARENT.HOST}/some.discovery), then again, inline validator will scream that the formula is incorrect.
Finally, the way to achieve this (apart from trigger actions) seems to be to store both parent (OS) host's {HOST.HOST} and application host's {HOST.HOST} macro's values inside the application host's user macros, then create a calculated item with some arbitrary string in the place of host such as: last(/CHANGE_ME/some.discovery) and use javascript preprocessing to execute API on the application host (user macro allowed) to update the calculated item and replace the value of CHANGE_ME with the value from the user macro containing parent host's {HOST.HOST}.

 

Four proposals:

• allow user and LLD macros in the place of host inside calculated item formula's functions
• allow dependent items to have dependency on different hosts, where the different host can be set dynamically
• ensure item sharing in 8.0 is dynamic, i.e. think of a way to allow user to automate the process of item sharing between parent host and child hosts
• provide {PARENT.HOST} built-in macro available to host's created from host prototypes, where this macro could be used in calculated items in the place of host inside the formula's functions

Overall it would be great to restrict the use of macros as less as possible and pass the responsibility over to the user, where the misconfigured item leads to being unsupported instead of impossible to set up.