Well, expanding macros is already supported for some API methods - e.g. for trigger.get().

Which version does support that ?
I've just checked against 2.4.5:

{
  "status": "0",
  "description": "{$COMPONENT} Status URI HTTP Code",
  "state": "0",
  "url": "",
  "type": "0",
  "templateid": "17983",
  "lastchange": "1433361132",
  "value": "0",
  "priority": "3",
  "triggerid": "17992",
  "flags": "0",
  "comments": "",
  "error": "",
  "expression": "{22975}=1"
}

I'm particularly interested in having macros expanded in item keys, but having macros expanded in all object properties would be even better.

zerthimon, regarding trigger.get() see corresponding API documentation and watch out for "expand*" method parameters.
As for item.get() that would actually make no real sense to me, since the unresolved macro is part of the item key and gets resolved later depending on context by server. Afaik there is no technical use case of an item key with resolved macros in Zabbix at all.

I understand that there might be a custom need to get macros of item key parameters resolved. Anyhow, from my personal pov this should probably not be part of this method. Such a edge case is likely better covered by resolving it in the custom application if needed.

I disagree, knowing what the macro value was at the time of data collection is very useful, particularly if it has ever been changed. Also, if you are archiving data elsewhere, the expanded key is more useful than a macro. I assume this is already being expanded in order to tell agents what the value is, can't this code be reused?

From our testing, even host.get only returns expanded macros for macros set on the host, not ones inherited from templates.

In more wide case, it will be rigth to have possibility to "expand" macro's value in every place, where mocros can be used. Isn't it?

What is the developers' reason to go in other way?

Agree (with David and viktorkho). There's also some precedent on external libs to try and manage this, like Zabbix2 Perl API client - and interesting note by the developers on this: "we are not expanding hostmacros or globalmacros, those are problematic". I think the implementation details of this are trapped inside the Zabbix application and should be properly supported via the API.

Another example of macro replacement challenges: https://github.com/alexanderzobnin/grafana-zabbix/pull/106

It's may be really useful! In another case we should have expand method for every parameter which can has macros.

For example there is no expandUrl method now but you can use macro there.

The same with tags results in trigger.get (selectTags set)

might be worth listing where expansion would be desired. please correct and expand as needed.

trigger.get explicitly allows 3 fields to be expanded already :

• expandComment (actually, description)
• expandDescription (actually, name)
• expandExpression

items :

• name
• key
• description
• update interval

hosts :

• description
• interface... something ?

Hi Richlv,

Were suffering a fair bit with this.

We use user macros a lot to allow configuration in templates that is controlled per host for example in template for PgBouncer port monitoring we have

ITEM NAME - PgBouncer Port - Status ({$APP.PORT.CONF.NUMBER:"PgBouncer"}:tcp)
ITEM KEY - net.tcp.listen[\{$APP.PORT.CONF.NUMBER:"PgBouncer"}]
MACRO - {$APP.PORT.CONF.NUMBER:"PgBouncer"} = 6432

On specific hosts we just override the macro '{$APP.PORT.CONF.NUMBER:"PgBouncer"}' with another port such as 7432 which requires no template change to monitor PgBouncer on a different port.
 
We use Grafana for some visualization and it pulls out the item name as 'PgBouncer Port - Status ({$APP.PORT.CONF.NUMBER:"PgBouncer"}:tcp)' rather than 'PgBouncer Port - Status (6432:tcp)'.

We also have some SLA reporting which uses Zabbix data and this is affected in the same way.

It would be nice for the API to perhaps have an option (ExpandMacros) which would be non breaking and this would replace all macros where ever you can set them in the object (Item/Trigger/Hosts etc...)

We try to use user macros everywhere we can to enable template flexibility across several clients as they all have different needs and configurations.

Cheers

James