[ZBXNEXT-6068] Ability to use built-in macros as values for user macros Created: 2020 Jul 14 Updated: 2024 Jan 12 |
|
Status: | Need info |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Frontend (F), Server (S) |
Affects Version/s: | 5.0.2 |
Fix Version/s: | None |
Type: | New Feature Request | Priority: | Trivial |
Reporter: | Christian Anton | Assignee: | Valdis Murzins |
Resolution: | Unresolved | Votes: | 6 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: |
![]() |
||||
Issue Links: |
|
Description |
It would be useful to be able to use built-in macros to assign their value to user macros. Example: the currently delivered templates "Template App Remote Zabbix server" and "Template App Remote Zabbix proxy". Both of them use the user macro {$ADDRESS} to access the corresponding Zabbix server. This might make sense in some cases, but in like 99% of all use cases for all those items (ok, it's in fact just three, but anyway) and without a need to change the template (by changing the macro used in the three master items) setting the user macro {$ADDRESS} to just {HOST.CONN} would be a good solution. |
Comments |
Comment by Andrei Gushchin (Inactive) [ 2020 Jul 15 ] |
Hello Christoper, Probably you could use the built-in macro instead of user macro in the key, it already supported. |
Comment by Christian Anton [ 2020 Jul 22 ] |
Yes, of course I could just use {HOST.CONN} directly in the corresponding items, but this would imply a change of the template delivered by Zabbix, which I would like to avoid in this specific case. The template is designed in a way that the "Ip address for the remote zabbix server to monitor" is set as "{$ADDRESS}" user macro. Generally spoken, this procedure makes a lot of sense, as it could be the template would be used by someone wanting exactly this separation between host settings and template settings. But for those who would use it like I would like to, it would be easiest to just assign {HOST.CONN} as a value to {$ADDRESS} though. |
Comment by Glebs Ivanovskis [ 2020 Jul 22 ] |
I see that {$ADDRESS} macro is used in zabbix[stats,...] items and that second parameter (<ip>) is optional. Documentation says that it defaults to 127.0.0.1 which is kinda strange, because for net.*.service* items optional <ip> parameter defaults to host IP/DNS, i.e. {HOST.CONN}. If same was true for zabbix[stats,...] (I mean if zabbix[stats,...] defaulted to use host address like net.*.service* items do), christiananton could just leave {$ADDRESS} empty. neogan, could you please explain why zabbix[stats,...] defaults to 127.0.0.1? |
Comment by Christian Anton [ 2020 Jul 22 ] |
Glebs, how would defaulting to localhost help me in this case? Indeed, I am REMOTELY monitoring a Zabbix server by an other Zabbix server. I am using the zabbix[stats, ...] INTERNAL items to do that (not the zabbix.stats[...] ones which are indeed AGENT items and COULD work with localhost). For the internal items used by me, I need to supply IP address of the remote Zabbix server. And yes, of course I have fixed the problem just by placing the corresponding IPs/host names in the host based user macros {$ADDRESS} for every of those hosts. BUT this is duplification of data and due to the fact that I cannot do this by "mass update" because every of the hosts needs the macro been set differently, I had the idea that being able to actually assign a built-in macro to a user macro would make it more easy to use for others (and for myself). |
Comment by Glebs Ivanovskis [ 2020 Jul 22 ] |
I meant that defaulting to host IP/DNS ({HOST.CONN}) would help. Defaulting to localhost doesn't help in your case and I wonder if it helps in any other case. This implementation detail isn't discussed/mentioned in |
Comment by Christian Anton [ 2020 Jul 22 ] |
Indeed, I fully agree. I didn't understand your prior comment in that way though. |
Comment by Glebs Ivanovskis [ 2020 Jul 22 ] |
I updated my previous comment to be a bit more explicit. |