ZBXNEXT-1420 asks for this in calculated items

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.

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 ]"

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.

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

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

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}.

glebs.ivanovskis I want to let you know that for such use case there is a solution - protect {HOST.IP} from resolving in aggregated item key by putting it into user macro. So, {$MACRO} => {HOST.IP} and your aggregated item looks like grpfunc[...,"item[{$MACRO}]",...]. ZBX-2866 begs for ability to escape macro resolution.

aabell53 Thanks Glebs. I'll give this a go.

min/max etc for specific items is ZBXNEXT-1829

Just wanted to add that my use case for this is basically the same as the one detailed by Justin previously. Currently, without the wildcard function for aggregate keys, I believe my only option is to create a calculated item first that includes all the keys I'm interested in, and then make an aggregate check of the calculated item. Being able to use a wildcard in the key would greatly streamline that process.

ZBXNEXT-3446 asks to eliminate aggregate items completely

+1000005000

Please also add filter by Application. I use it to separate traffic on internal and external interfaces with custom LLD.

It will be implemented under ZBXNEXT-6451 in Zabbix 5.4 very soon.

Implemented in Zabbix 5.4 under ZBXNEXT-6451