-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Logs UI] Add sorting capabilities to categories page #88051
[Logs UI] Add sorting capabilities to categories page #88051
Conversation
Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui) |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So... this sorts the 25 categories in the browser after the server already sorted them by document count and truncated them to the requested number.
Doesn't that mean that an anomaly with a very high score in a category with low document count might never show up even though the user sorts by anomaly score?
Should we delegate the sorting to ES? It'll be tricky for the trend column because these values are fetched separately. 🤔
@weltenwort Yes, I think my interpretation was probably wrong here. I thought we'd be keeping the "top" nature but then allowing a sort. But in hindsight that doesn't really make sense.
Yeah. It will largely mirror the sort implementation I did for the anomalies page.
Yeah. I'm just looking at the way |
TODO: Trend sorting
Maybe we can reduce the scope to not make the trend sortable? (@mukeshelastic) |
👍 Makes sense to me. The "new" aspect makes things more complicated as well. It's not a particularly good field for a primary sort. |
I've pushed the changes that switch this for server side sorting for maximum anomaly score and message count. I've also reversed anything to do with trend sorting. @mukeshelastic Do you think this is a suitable compromise? It's not trivial to sort on the trend as the values are derived from different places. There might be a way to combine the queries, but it's certainly not a small change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Kerry350, thanks for revisiting the server-side sorting. It works great for the count and the anomaly score and is implemented very cleanly. 👍
While I'd still like to hear from @mukeshelastic about the trend column, I think this can stand on its own and could be merged at your convenience.
x-pack/plugins/infra/common/http_api/log_analysis/results/log_entry_categories.ts
Show resolved
Hide resolved
@@ -29,6 +30,8 @@ export const TopCategoriesSection: React.FunctionComponent<{ | |||
sourceId: string; | |||
timeRange: TimeRange; | |||
topCategories: LogEntryCategory[]; | |||
sortOptions: SortOptions; | |||
changeSortOptions: ChangeSortOptions; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
total nit: Do we want to keep the on*
naming schema for such functions?
changeSortOptions: ChangeSortOptions; | |
onChangeSortOptions: ChangeSortOptions; |
@@ -14,13 +14,33 @@ import { | |||
createDatasetsFilters, | |||
} from './common'; | |||
|
|||
import { CategorySort } from '../../../../common/http_api/log_analysis'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This import makes my slightly uncomfortable because it couples the query to the HTTP types, but I'm not sure it's worth dwelling on.
Do you think it would be worth it to duplicate that type here so they are technically independent but happen to line up without conversion (how convenient)?
Alternatively we could move that type to a location like common/log_analysis/log_entry_rate_analysis.ts
so it's independent of the HTTP layer. 🤔
…entry_categories.ts Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
@weltenwort I'm going to merge this without the further type / naming changes as I think they'll make more sense addressed alongside #79770. As part of that I've lifted a few (other) bits into
But my intention is to hoist them to |
Sounds good, thank you! |
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
* Add sorting capabilities to categories page Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
@Kerry350 @weltenwort Thanks for looking into this. I am good with not making the trend column sortable?. |
Summary
This PR implements #58314.
Note
For maximum anomaly score and message count this is a simple numeric sort. For the "trend percentage" there is a little more work involved as the change factor is based off of two values, and if a category is newly detected it won't have a change factor.
If there's a mixture of new items, and items with a change factor, then depending on the order the new items are prepended (ascending sort) or appended (descending order) to the sorted items.
If the list only contains new items, there will be no visual change on sort.
Testing