ZABBIX FEATURE REQUESTS
  1. ZABBIX FEATURE REQUESTS
  2. ZBXNEXT-1521

allow wildcards (or macros) in aggregate items

    Details

      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 - - edited

          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 - - edited 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 - - edited

          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 - - edited 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.
          Hide
          Oleksiy Zagorskyi added a comment -

          Something similar could be implemented for host groups, then it would resolve ZBXNEXT-423.

          Show
          Oleksiy Zagorskyi added a comment - Something similar could be implemented for host groups, then it would resolve ZBXNEXT-423 .
          Hide
          richlv added a comment -

          ZBXNEXT-2456 asks for regexp or wildcard support in host group names

          Show
          richlv added a comment - ZBXNEXT-2456 asks for regexp or wildcard support in host group names
          Hide
          Alex Bellia added a comment - - edited

          Just want to record my use case here in the hope it makes the issue clearer:-

          I have an external check which is called with a parameter set to {HOST.IP1}.
          I'd like to be able to use grpmin to get the minimum value for all hosts in a hostgroup.
          The aggregate item key looks like this:-
          grpmin["my host group","myexternalcheck[{HOST.IP1}]",last,0]
          currently this item becomes unsupported with this error in zabbix_server.log
          28577:20150318:181345.165 item [myhost:grpmin["my host group","myexternalcheck[{HOST.IP1}]",last,0]] became not supported: No items for key [myexternalcheck[*UNKNOWN*]] in group(s) [my host group]

          So as seems logical there is a problem with evaluating {HOST.IP1} for an item which aggregates values from multiple hosts in a host group.

          Fixing this by allowing an array of values sounds problematic as each time I add a host to my host group I'd need to add another ip address
          to the array. So a wildcard sounds like the better option from this narrow point of view at least.

          In the meantime I will work around by turning the external check into a trapper item to get rid of {HOST.IP1}.

          Show
          Alex Bellia added a comment - - edited Just want to record my use case here in the hope it makes the issue clearer:- I have an external check which is called with a parameter set to {HOST.IP1}. I'd like to be able to use grpmin to get the minimum value for all hosts in a hostgroup. The aggregate item key looks like this:- grpmin["my host group","myexternalcheck[{HOST.IP1}]",last,0] currently this item becomes unsupported with this error in zabbix_server.log 28577:20150318:181345.165 item [myhost:grpmin["my host group","myexternalcheck[{HOST.IP1}]",last,0]] became not supported: No items for key [myexternalcheck[*UNKNOWN*]] in group(s) [my host group] So as seems logical there is a problem with evaluating {HOST.IP1} for an item which aggregates values from multiple hosts in a host group. Fixing this by allowing an array of values sounds problematic as each time I add a host to my host group I'd need to add another ip address to the array. So a wildcard sounds like the better option from this narrow point of view at least. In the meantime I will work around by turning the external check into a trapper item to get rid of {HOST.IP1}.
          Hide
          richlv added a comment -

          min/max etc for specific items is ZBXNEXT-1829

          Show
          richlv added a comment - min/max etc for specific items is ZBXNEXT-1829

            People

            • Assignee:
              Unassigned
              Reporter:
              Samgarr
            • Votes:
              14 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated: