ZABBIX FEATURE REQUESTS

allow wildcards (or macros) in aggregate items

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 2.0.3
  • Fix Version/s: None
  • Component/s: Server (S)
  • Zabbix ID:
    NMR

Description

example:

grpsum["somegroup","net.if.in[bond*,bytes]","last","0"]

Issue Links

Activity

Hide
richlv added a comment -

ZBXNEXT-1420 asks for this in calculated items

Show
richlv added a comment - ZBXNEXT-1420 asks for this in calculated items
Hide
Oleksiy Zagorskyi added a comment -

An alternative way - identically to currently supported an array for hostgroups implement support of such array for item key.

Support of macros or wildcards here (for item key) look as different things.

Show
Oleksiy Zagorskyi added a comment - An alternative way - identically to currently supported an array for hostgroups implement support of such array for item key. Support of macros or wildcards here (for item key) look as different things.
Hide
Justin McNutt added a comment -

I think a wildcard would work better, especially in cases like mine. The Items I want to aggregate are external checks. For each Host, one of the parameters sent to the external script changes. But otherwise, all of the keys in the Items are exactly the same.

Example:
On each Host in the Host Group "Clydesdale Hall" is an external check (which was, in turn, created by a Discovery rule). The key for the external check looks like this:

SessionStats["byap", "10.5.3.23"]

Only the IP address of the access point changes. I'd like to be able to create an aggregate Item with a key like one of these:

Based on the Discovery rule:
grpsum["Clydesdale Hall","SessionStats[byap,{#STATID}]",last,0]

Wildcard parameter:
grpsum["Clydesdale Hall","SessionStats[byap,%]",last,0]

"Raw" wildcard:
grpsum["Clydesdale Hall","SessionStats%",last,0]

In my case, an exception for aggregating external checks that would match against only the script name and ignore the parameters would work as well (perhaps as a checkbox in the configuration of the aggregate item?), but that may be too specific a case to write code for. A true wildcard would be far more flexible, if it's feasible.

If wildcards create the potential for users to accidentally aggregate thousands of Items and destroy their systems, the Web UI could run a check when the user clicks Save. If the number of aggregated Items is more than 1000, a warning could pop up that asks the user to confirm the change. "The key you've entered will aggregate 13947810 Items. Are you sure you want to proceed? [ OK ] [ Back to Item Config ]"

Show
Justin McNutt added a comment - I think a wildcard would work better, especially in cases like mine. The Items I want to aggregate are external checks. For each Host, one of the parameters sent to the external script changes. But otherwise, all of the keys in the Items are exactly the same. Example: On each Host in the Host Group "Clydesdale Hall" is an external check (which was, in turn, created by a Discovery rule). The key for the external check looks like this: SessionStats["byap", "10.5.3.23"] Only the IP address of the access point changes. I'd like to be able to create an aggregate Item with a key like one of these: Based on the Discovery rule: grpsum["Clydesdale Hall","SessionStats[byap,{#STATID}]",last,0] Wildcard parameter: grpsum["Clydesdale Hall","SessionStats[byap,%]",last,0] "Raw" wildcard: grpsum["Clydesdale Hall","SessionStats%",last,0] In my case, an exception for aggregating external checks that would match against only the script name and ignore the parameters would work as well (perhaps as a checkbox in the configuration of the aggregate item?), but that may be too specific a case to write code for. A true wildcard would be far more flexible, if it's feasible. If wildcards create the potential for users to accidentally aggregate thousands of Items and destroy their systems, the Web UI could run a check when the user clicks Save. If the number of aggregated Items is more than 1000, a warning could pop up that asks the user to confirm the change. "The key you've entered will aggregate 13947810 Items. Are you sure you want to proceed? [ OK ] [ Back to Item Config ]"
Hide
Justin McNutt added a comment -

ZBXNEXT-1532 (duplicate) suggests supporting regular expressions, which I don't like unless the different key parameters became separate fields in the GUI. Even then, parsing the key would likely become a nightmare.

ZBXNEXT-1532 also suggests supporting macros. I like this much better, though I'm not sure how complicated this would make processing. As each Host in the Host Group (or array of Host Groups) was evaluated, the macro values in the aggregate item's key would have to be re-evaluated for that Host.

If that's easy, great! I could put {HOST.IP1} in there and I'm done.

If not, then we're back to wildcards.

Show
Justin McNutt added a comment - ZBXNEXT-1532 (duplicate) suggests supporting regular expressions, which I don't like unless the different key parameters became separate fields in the GUI. Even then, parsing the key would likely become a nightmare. ZBXNEXT-1532 also suggests supporting macros. I like this much better, though I'm not sure how complicated this would make processing. As each Host in the Host Group (or array of Host Groups) was evaluated, the macro values in the aggregate item's key would have to be re-evaluated for that Host. If that's easy, great! I could put {HOST.IP1} in there and I'm done. If not, then we're back to wildcards.

People

  • Assignee:
    Unassigned
    Reporter:
    Samgarr
Vote (3)
Watch (4)

Dates

  • Created:
    Updated: