Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-9729 revision 55075.

(1) While the m == bl comparison is correct it's somewhat confusing. It would be better to add a new variable with appropriate naming (for example indexed_macro), so that the comparison is obvious.

Also in some comparisons this check is done first, in others - last. We should keep the same order in all comparisons. Having it done at the beginning seems logical.

glebs.ivanovskis Applied proposed changes in r55175. RESOLVED

wiper Please check my changes in r55206.
CLOSED

Successfully tested

Fixed in pre-3.0.0alpha2 (trunk) r55215.

Ok, you completely break working configurations.
I can't see anywhere in docs about "n-th items in trigger expression". For this type there is {ITEM.VALUEx} macros.
Which macros I should use for ping secondary IP address from host config?

Could you please elaborate a bit more on how this breaks a working configuration? {HOST.IP2} always expanded to the same value as {HOST.IP}.

rev 55215 breaks expansion for "indexed" macro in keys. Completely.

 15897:20151007:220001.720 In substitute_key_macros() data:'icmppingsec[{HOST.IP1},5,,1472]'
 15897:20151007:220001.720 In substitute_simple_macros() data:'{HOST.IP1}'
 15897:20151007:220001.720 In substitute_simple_macros() nothing matched: idxmacro=1, type=00000040, m={HOST.IP}
 15897:20151007:220001.720 End substitute_simple_macros() data:'{HOST.IP1}'
 15897:20151007:220001.720 End of substitute_key_macros():SUCCEED data:'icmppingsec[{HOST.IP1},5,,1472]'
 15897:20151007:220001.720 In add_icmpping_item() addr:'{HOST.IP1}' count:5 interval:0 size:1472 timeout:0
 15897:20151007:220001.720 End of add_icmpping_item()

reverted patch:

 17017:20151007:223501.730 In substitute_key_macros() data:'icmppingsec[{HOST.IP1},5,,1472]'
 17017:20151007:223501.730 In substitute_simple_macros() data:'{HOST.IP1}'
 17017:20151007:223501.730 End substitute_simple_macros() data:'127.0.0.1'
 17017:20151007:223501.730 End of substitute_key_macros():SUCCEED data:'icmppingsec[127.0.0.1,5,,1472]'
 17017:20151007:223501.730 In add_icmpping_item() addr:'127.0.0.1' count:5 interval:0 size:1472 timeout:0
 17017:20151007:223501.730 End of add_icmpping_item()

Find two differences.

Ah, thank you! Anyway, the ability to use {HOST.IP1} in an item key was a bug. If someone relied on that bug, well, sorry.

HOST.IP == HOST.IP1 isnt't it?

It was. And {HOST.IP2} was equivalent to {HOST.IP}. And {HOST.IP3}. And {HOST.IP4}... Which was clearly nonsense.

In the context where is only one host it is logical to use simply {HOST.IP}.

Maybe it should expand to empty string if there no second/third/four/.... IP in host config? This is more logically then always expand to first IP.

Documentation says:

Note that the numbered macro syntax of {MACRO<1-9>} is used to reference hosts in the order in which they appear in a trigger expression. Thus, macros like {HOST.IP1}, {HOST.IP2}, {HOST.IP3} will expand to the IP of the first, second and third host in the trigger expression, providing the expression contains those hosts.

Multiple IPs in host configuration have nothing to do with indexed macro.

If we don't recognize the sequence of symbols as macro or user parameter or alias it is logical to leave it as it is, not replace it with empty string. Maybe it's simply text.

{HOST.IP5} never had the semantics that it would expand to the 5th IP in host config, so in this regard nothing is broken.

Request ZBXNEXT-1154 seems to talk along the lines of being able to refer to alternative interfaces on the host. You might wish to add a comment there.

Related issue: ZBX-10376

Hello,

I more or less understand the issue that prompted the change but I would like to discuss it a bit.

I'm monitoring a lot of customer's routers (~300) that have 2 internet connections, on zabbix 2.4, I used {HOST.IP1} and {HOST.IP2} to ping them, raise average alert when 1 interface was down and raise high alert when both interface were down.

How can I do that now?

Use user macros, create multiple icmpping[{$HOST.IP_X}] items. Or use LLD if your routers support SNMP (walk over IP-MIB::ipAdEntAddr).

lynxchaus: I ended up doing exactly this after talking about it on irc with Gleb, thank you for your time.