List of interfaces in global query summary is ambiguous
Opened this issue · 2 comments
When performing a global query on a couple of hosts the returned result contains a list of interfaces (obviously):
{
"status": {
"code": "ok"
},
"hosts_statuses": {
"core-1": {
"code": "ok"
},
"fw-1": {
"code": "ok"
},
"fw-2": {
"code": "ok"
}
},
"summary": {
"interfaces": [
"eth0",
"eth1",
"eth1.1",
"eth1.10",
"eth1.11",
"eth1.15",
"eth1.16",
"eth2",
"fabric",
"lo",
"ppp0",
"ppp1",
"t_c1_fw1",
"t_c1_fw2",
"t_c1_fwde",
"t_c1_fwde1",
"tun2",
"tun_3g_c1_fw1",
"tun_3g_c1_fwde",
"tun_core_ark"
],
"time_first": "2023-08-18T14:19:31+02:00",
"time_last": "2023-09-18T14:20:00+02:00",
"totals": {
"br": 1848,
"bs": 1918,
"pr": 27,
"ps": 20
},
"timings": {
"query_start": "2023-09-18T14:24:31.20804655+02:00",
"query_duration_ns": 676775956
},
"hits": {
"displayed": 4,
"total": 4
}
},
"query": {
"attributes": [
"sip",
"dip",
"proto",
"dport"
],
"condition": "(sip = 45.129.14.99 | dip = 45.129.14.99)"
},
"rows": [
{
"labels": {
"iface": "eth0",
"host": "fw-2",
"host_id": "6b8890bdfb10394d59d545547ce860ba"
},
"attributes": {
"sip": "45.129.14.99",
"dip": "144.76.51.228",
"proto": 6,
"dport": 587
},
"counters": {
"br": 901,
"bs": 1025,
"pr": 13,
"ps": 11
}
},
...
]
}
While for a single host query this list makes total sense, for a global query it is inherently ambiguous (because it just contains a list of unique interface names encountered across all hosts). Since every row contains the unambiguous set of labels I'm wondering if we should maybe do either of the following:
- Remove / clear the
interfacesarray in the summary for global queries (usingomitemptyit would then just be missing, which IMHO is fine) - Prefix each interface with the hostname (for global queries only of course) so that we really return a list of all interfaces across all hosts (that being said: for many hosts that might really blow up considerably without adding any practical information)
@els0r What do you think?
Agreed. I tried coming up with a use case where we would benefit from having the list available. Can't think of one. I would also strongly suggest not to go with the second option as that would blow up cardinality/result size considerably with redundant information.
Bringing me to the next point: if there is a need for showing which hosts returned data for which interfaces, the front end calling global-query should synthesize that list.
And the final point: goQuery is a front end for global-query. And capable of running queries across multiple hosts. So if we change the way that this interface list isn't returned, we also have to adjust goQuery to print out the interface-per-hosts information explicitly. Or at least if len(hosts) > 1.
Are you sure it's worth the effort? If so, let's make a separate feature out of how we print the interface list and then tackle the removal of interfaces in the summary.
And the final point:
goQueryis a front end forglobal-query. And capable of running queries across multiple hosts. So if we change the way that this interface list isn't returned, we also have to adjustgoQueryto print out the interface-per-hosts information explicitly. Or at least iflen(hosts) > 1.
But how does goQuery do it then (I haven't tried that in a distributed fashion)? It receives the list of all interfaces, not knowing which host data does belong to, so that information is superfluous at best. All the more reason to drop it in cases of a distributed query, no?
Just to clarify: I'm not really pro showing host + interface and increasing complexity per se (although in the context of e.g. a distributed raw query this might become relevant - otherwise how would you know which flow comes from which host / interface combination), but if the information doesn't serve a purpose it should be dropped IMHO.
TBH I'm a bit confused as to what to do with this. 🤣