Repository navigation
[Meta] Kibana support for ES aggregations #58628
Description
Activity
Pinging @elastic/kibana-app (Team:KibanaApp)
Reacted by Roberto RieloReacted by Roberto RieloPinging @elastic/kibana-app-arch (Team:AppArch)
Hi @lukeelmers and @ppisljar, I notice that there are no plans to leverage the auto-date histogram since Kibana has a workaround for this. Is there a similar perspective to the proposed auto-numeric histogram feature (elastic/elasticsearch#31828), in that there is a kibana workaround at the moment?
Related, can I ask why this is the case:
There are no plans to support Auto-interval date histogram in Kibana, since we're supporting auto interval via an implementation in Kibana. Due to technical reasons we'll keep using that Kibana side implementation for auto intervals.
My understanding is that auto-date-histo was prioritized and added in 7.0 because it was requested in part by Kibana (elastic/elasticsearch#9572 (comment), #3757, etc) precisely so that Kibana didn't have to worry about auto-interval logic anymore? Is there some context somewhere as to why Kibana wants to continue supporting it's own auto-interval?
@talevy Hi, there is currently no real workaround for creating auto intervals on numeric fields. I think you'll need to wait for us to implement the auto histogram for numeric fields (which would leverage the ES aggregation) for this to work. Sorry. :-/
@polyfractal I read through some of the linked issues, and it seems some of those comments are really old, so it could simply be that we thought at that time it might be better to have it in Elasticsearch (for auto (non-date) histogram) that's also most likely still true, but for the date histograms there are a couple of issues:
- I unfortunately don't find the issue where that was discussed anymore, but I remember that
auto_date_histogramhad problems withextended_bounds. So we could not set the extended bounds, and would get a reasonable interval based on that extended bounds. We use that within the charts, because we want the actual chart time range be used for reasonable interval calculations, so that if you e.g. look at a chart from the past year, but the data only exists within one week of that year, we still want that the interval is 100 (arbitrary number I just made up) over that one year and not over that 1 week that contains data. I also think there were (in the past) some problems withmin_doc_count = 0for auto date histograms? - We are showing the interval that will be used for the query in a couple of places before making the request, which would become impossible if we don't calculate it client side and thus don't know it before doing the request. (Even if we would do it after the request, I think we'd need an explicit part in the response that tells us what interval was used, since there could be buckets missing, so we can't calculate it from the buckets we have. But still we need it before the request in a couple of places).
- Last but not least: it works with the clientside logic. There is currently for us simply no real need to replacing that (rather deep sitting) logic, which would be a huge huge properly fragile change.
I hope this could shine some light onto the reasoning here, and happy to help with any further details.
- I unfortunately don't find the issue where that was discussed anymore, but I remember that
@rayafratkina are there any plans to add percentile aggregation in Kibana Lens?
what's the status about
nestedentities visualization in kibana?Reacted by fatihakafou, Mindaugas Vaitiekūnas, Keven Bouchard, Daron Zwink, Feynman Liang and oscartunjanoReacted by Andrey Morozov and Keven BouchardThank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.
Re-opening as we are still using this
Closing old meta issues in favor of more granular, current meta issues. Going forward, we expect aggregation support to come via ES|QL support
Closing old meta issues in favor of more granular, current meta issues. Going forward, we expect aggregation support to come via ES|QL support
thank you, could you please clarify the ES|QL support? Thanks.
This issue will track support for ES aggregations within Kibana. The list below is not in a priority order, just an inventory.
Bucket aggregations
Metrics aggregations
Matrix aggregations
Pipeline aggregations
Other aggregation ideas (not directly supported by ES)
Notes
autointerval via an implementation in Kibana. Due to technical reasons we'll keep using that Kibana side implementation forautointervals. Auto interval on all time fields #4312 for the enhancement to supportautointerval on all fields (not only the primary time field of an index pattern).AggConfigslives in thedataplugin'ssearchservice, and is used behind the scenes for aggregations in Visualize and Lens. Work onAggConfigsis tracked in [Meta] Aggregations Roadmap #60126. A checkmark here means that we have the technical foundation to implement it into visualizations, but not that it's already available to the user anywhere.