Graylog2 / Graylog2/graylog2-server

rows excluded from the limit should be summed up into a single row named "other"

Open
#11,773 4 comments 2 reactions 1 assignee Claimed by @maxiadlovskii View on GitHub
feature frontend
Dominant language
Java
Stars
8.1k
Forks
1.1k
Avg merge
1d 20h
Merged PRs (30d)
217

Description

The way the "limit" option works within aggregations is not intuitive and produces strictly misleading outputs/visualisations.

## Expected Behavior

Rows excluded from an aggregation using the limit option should be summed up into a single row named "other". This way, the relative percentages of each row always remain constant and accurate.

## Current Behavior
At present, if I have a pie chart that would have 7 diferent "rows" in the legend, and I apply a limit of 5, I will get a pie chart that excludes the remaining 2 "rows" entirely from the results.

## Context

The limit option in Aggregations should **not** exclude results from the series.

At present, if I have a pie chart that would have 7 diferent "rows" in the legend, and I apply a limit of 5, I will get a pie chart that excludes the remaining 2 "rows" entirely from the results.

This distorts the ability of the output to correctly show relativity (eg. what % of events captured are from each row) and can make for very misleading results.

For Example, does kernel represent 52.3% of results? or 41% of results? Or in fact, neither?

these two pie charts show the SAME DATASET, just with a different "limit" on set rows.

![Screenshot 2021-12-08 at 10 28 25](https://user-images.githubusercontent.com/85873295/145192665-31ba1a8c-ee2f-4852-84e1-3cecc2ed1d2a.png)

![Screenshot 2021-12-08 at 10 28 08](https://user-images.githubusercontent.com/85873295/145192675-c9a67e34-e0d0-4fbc-998c-ff6dd206987e.png)

The way it should work in my view (this is the way it works on Splunk for example) is that rows excluded from the limit should be summed up into a single row named "other". This way, the relative percentages always remain constant and accurate.

Why is the current way the limit function works a cardinal sin?
I think because the aggregation controls should **not** be able to affect which messages are encompassed by the aggregation visualisation - **only** the search filter should be able to define which results are encompassed. The aggregation controls should only be allowed to show how those results are displated. It's important to seperate powers in the interface this way so the user can understand where their results are coming from - by effectively having two seperate ways to filter out results, you make neither one definitive.

## Your Environment

* Graylog Version:
4.2.0

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.