[ZBXNEXT-4382] Multiple icmp* items for one host Created: 2018 Feb 13  Updated: 2018 Feb 14  Resolved: 2018 Feb 14

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Agent (G), Server (S)
Affects Version/s: None
Fix Version/s: None

Type: Change Request Priority: Trivial
Reporter: Markus Fischbacher Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File HostConfig-1.png     PNG File item ping node a.png     PNG File item ping node b.png    
Issue Links:
Duplicate
duplicates ZBXNEXT-1490 Unable to use same SNMP trap item key... Open

 Description   

Currently it's not possible to have more than one icmp* item with the same arguments on a host as that would result in the same key. But that would be crucial for clustered checks on ip for example.

I found some issues and bugs reported but most of them are stale or closed and none off them used a simple approach to accomplish. The easiest way to get that would be an additional argument for all the icmp* functions - let's just call it an keymodifier or a ordinal number.



 Comments   
Comment by Markus Fischbacher [ 2018 Feb 13 ]

icmpping[<target>,<packets>,<interval>,<size>,<timeout>,<keymod>]
icmppingloss[<target>,<packets>,<interval>,<size>,<timeout>,<keymod>]
icmppingsec[<target>,<packets>,<interval>,<size>,<timeout>,<mode>,<keymod>]

In adding that argument to the end of the list no current usage would become broken.

Comment by Markus Fischbacher [ 2018 Feb 13 ]

Hmm... as i copied over the keys from the documentation i realized that nearly every simple check would benefit from that change?

for example: net.tcp.service[service,<ip>,<port>, <keymod>]

So it would be possible to check net.tcp.service[ftp,,45,A] on the first added interface and net.tcp.service[ftp,,45,B] on the second one. Why anyone would want that? Clustered services or internal and external addresses for example!

Comment by Glebs Ivanovskis (Inactive) [ 2018 Feb 13 ]

If this additional parameter does not have any meaning with respect to item behaviour, what will be the point in having multiple items which do the same?

Comment by Markus Fischbacher [ 2018 Feb 14 ]

The parameter just allows to have multiple items of same simple check on one host as otherwise the "key already in use" error is thrown.
And the usecase for that would be a host with multiple agent/snmp/* interfaces which should be checked. That would be crucial for example for a multi-node storage system. Node A has a IP/SNMP address to get values from and Node B too. Currently there we have to create two separate hosts - heck often i have to create three hosts. Node-A, Node-B and a combined node where i store the calculated items... ugly.

I already had a look at the source but i am not a C guy. Have to dig in a little more. Would be great if a experienced contributor would have a look at it.

Comment by Glebs Ivanovskis (Inactive) [ 2018 Feb 14 ]

From what you say I understand that <target> parameter will be different in those items and you won't have any key conflict.

Comment by Markus Fischbacher [ 2018 Feb 14 ]

No. I don't want to use macros for the items and the <target> parameter as i already configured the addresses in the interfaces. Just change the used interface for the item.
Added 3 Screens to clarify what i mean. That wouldn't work as icmpping is already in use on node a.

Comment by Glebs Ivanovskis (Inactive) [ 2018 Feb 14 ]

You can use host interface discovery and item prototype(s) with key of the sort icmpping[{#IF.CONN}] to automatically create ICMP ping items for all host interfaces you've configured.

Comment by Glebs Ivanovskis (Inactive) [ 2018 Feb 14 ]

Closing as Duplicate of ZBXNEXT-1490.

Generated at Fri Apr 19 03:30:46 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.