Skip to content
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

Support for number, date and IP range data types #76971

Merged
merged 25 commits into from
Mar 8, 2021

Conversation

wylieconlon
Copy link
Contributor

@wylieconlon wylieconlon commented Sep 8, 2020

Elasticsearch range types, like integer_range, date_range, or ip_range, are now supported in only the following:

  • KQL filtering
  • Filtering using filter pills
  • Adding positive & negative filters from Discover
  • Visualize histograms
  • Visualize cardinality
  • Lens unique count
  • Lens field stats (no data is shown)

Filtering support:

Screen Shot 2020-09-08 at 2 40 27 PM

Support in esaggs:

Screen Shot 2020-09-08 at 2 40 40 PM

Closes #12751

Checklist

@lukeelmers lukeelmers added the Feature:Aggregations Aggregation infrastructure (AggConfig, esaggs, ...) label Sep 16, 2020
@joealex
Copy link

joealex commented Sep 22, 2020

What is the plan for ip_range support in Kibana. Without the support in Discover (search, filter, interesting fields, tables), Visualizations the power of this field cannot be used. Also the documentation is slightly confusing on field type ip_range and the range aggregation for field type ip

@wylieconlon wylieconlon marked this pull request as ready for review January 29, 2021 23:45
@wylieconlon wylieconlon requested a review from a team January 29, 2021 23:45
@wylieconlon wylieconlon requested review from a team as code owners January 29, 2021 23:45
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-services (Team:AppServices)

@wylieconlon wylieconlon changed the title Support for number, date and IP ranges Support for number, date and IP range data types Jan 29, 2021
@wylieconlon
Copy link
Contributor Author

I think this PR actually needs to go back into draft mode, sorry for the noise. While it does kind-of-work, I would like to test all the apps that are affected by this. For example, adding a filter from Discover causes an invalid query.

@wylieconlon wylieconlon marked this pull request as draft January 30, 2021 00:04
@spalger
Copy link
Contributor

spalger commented Feb 3, 2021

jenkins test this

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly checked out Lens, this works pretty well. Do we have an issue already for adding the ability to do number histograms on number ranges?

I noticed a bug based on this, opened a separate issue because it's not directly related: #93433

@@ -127,6 +127,7 @@ export const rangeOperation: OperationDefinition<RangeIndexPatternColumn, 'field
);
},
onFieldChange: (oldColumn, field) => {
// TODO: Handle switch with number_range fields
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leftover?

it('should use provided value when number of generated buckets is less than histogram:maxBars', async function () {
log.debug('Field = machine.ram_range');
await PageObjects.visEditor.selectField('machine.ram_range');
await PageObjects.common.sleep(1000); // fix this
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can retry the assertion in the next line instead of sleeping?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. This pattern is used throughout the file but I don't need it here.

@wylieconlon
Copy link
Contributor Author

@flash1293 yes, I've updated the PR description to remove the Lens histogram changes, since we no longer support fixed interval histograms.

@wylieconlon wylieconlon requested a review from ppisljar March 3, 2021 23:54
Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested around and this looks good to me for the Lens integration.

One thing to consider:
With partially unbounded ranges and histograms it's super easy to run very expensive queries that eventually run into OOM. E.g if there's a date range which starts at 2020-02-03 without an end date and you are doing a date histogram on them, it will eventually cause an OOM error on Elasticsearch (probably because it never stops creating buckets). Not sure how we can help with this from Kibana side though. Maybe you have an idea?

@wylieconlon wylieconlon requested a review from streamich March 4, 2021 15:43
@wylieconlon
Copy link
Contributor Author

wylieconlon commented Mar 4, 2021

@flash1293 Does that happen when issuing the queries from Kibana, or just in dev tools? I think that the Kibana query would not do that because of the time filter + custom extents that are set on date histograms.

Either way, an OOM in Elasticsearch sounds like a bug. I found this issue which appears to have closed the bug: elastic/elasticsearch#50109

@flash1293
Copy link
Contributor

@wylieconlon interestingly it happened to me in Kibana as well. Steps to reproduce:

  • Run these requests
PUT abc
{
  "mappings": {
"properties": {
  "number_range": {
    "type": "integer_range"
  },
  "date_range": {
    "type": "date_range"
  }
}
  }
}

POST abc/_doc
{
  "number_range": {
    "gte": 12,
    "lte": 50
  },
  "date_range": {
    "gte": "2021-03-02",
    "lte": "2021-03-05"
  }
}

POST abc/_doc
{
  "number_range": {
    "gte": 30,
    "lte": 70
  },
  "date_range": {
    "gte": "2021-02-25",
    "lte": "2021-02-28"
  }
}

POST abc/_doc
{
  "number_range": {
    "gte": 60,
    "lte": 80
  },
  "date_range": {
    "gte": "2021-02-27",
    "lte": "2021-03-24"
  }
}


POST abc/_doc
{
  "number_range": {
    "gte": 60,
    "lte": 80
  },
  "date_range": {
    "gte": "2021-02-28"
  }
}
  • Configure abc index pattern
  • Go to Lens and use date_range on the x axis
  • Loads for a while, then the request fails and Elasticsearch logs OOMs

@flash1293
Copy link
Contributor

flash1293 commented Mar 4, 2021

@wylieconlon The issue you sent fixes this by adding a new parameter: hard_bounds (elastic/elasticsearch#59175). Maybe we should take care of adding that to our requests before rolling out this feature in Kibana to make it harder to run into super expensive queries? I don't have a strong opinion on it though, it would be fine as a follow-up for me as well.

@wylieconlon
Copy link
Contributor Author

wylieconlon commented Mar 4, 2021

@flash1293 Okay, I read the docs on hard_bounds. We can set it automatically on date_histograms and I will add that, but we can't set it automatically on histogram aggregations. We would have to ask users to enter the hard bounds as an advanced option. I think hard_bounds only makes sense for range data and I could add to the form here.

If possible, I'd like to do this in a separate PR. This PR has been going on for way too long.

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, let's move it into a separate issue. LGTM otherwise

Copy link
Member

@ppisljar ppisljar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code LGTM

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
data 217.8KB 218.0KB +205.0B
lens 919.9KB 920.6KB +693.0B
visDefaultEditor 241.5KB 241.6KB +120.0B
visTypeTimeseries 1.7MB 1.7MB -2.0B
total +1016.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
data 827.1KB 828.9KB +1.8KB
dataEnhanced 40.6KB 40.8KB +195.0B
kibanaReact 127.2KB 127.3KB +102.0B
total +2.1KB

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@wylieconlon wylieconlon merged commit c33987d into elastic:master Mar 8, 2021
@wylieconlon wylieconlon deleted the range-types branch March 8, 2021 20:50
wylieconlon pushed a commit to wylieconlon/kibana that referenced this pull request Mar 8, 2021
* Support for number, date and IP ranges

* Update tests

* Ranges don't work with range agg

* Fix test case

* Allow Discover to create range filters

* Supports ranges in Visualize, KQL, remove Lens support

* Fix test mappings

* Bring back field cache to work around bug

* Fix some tests

* Fix test expectation

* Respond to review comments

* Fix type error

* Remove added sample data

* Fix api_docs

* Fix test
wylieconlon pushed a commit that referenced this pull request Mar 8, 2021
* Support for number, date and IP ranges

* Update tests

* Ranges don't work with range agg

* Fix test case

* Allow Discover to create range filters

* Supports ranges in Visualize, KQL, remove Lens support

* Fix test mappings

* Bring back field cache to work around bug

* Fix some tests

* Fix test expectation

* Respond to review comments

* Fix type error

* Remove added sample data

* Fix api_docs

* Fix test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Aggregations Aggregation infrastructure (AggConfig, esaggs, ...) release_note:enhancement v7.13.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support ES range datatypes
9 participants