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

Values above ignore_above mapping limit don't show up in Discover anymore #101232

Closed
andrewkroh opened this issue Jun 2, 2021 · 5 comments · Fixed by #115040
Closed

Values above ignore_above mapping limit don't show up in Discover anymore #101232

andrewkroh opened this issue Jun 2, 2021 · 5 comments · Fixed by #115040
Assignees
Labels
blocked bug Fixes for quality problems that affect the customer experience Feature:Discover Discover Application impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. regression Team:DataDiscovery Discover, search (e.g. data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL.

Comments

@andrewkroh
Copy link
Member

andrewkroh commented Jun 2, 2021

Kibana version: 7.13.1

Elasticsearch version: 7.13.1

Server OS version: Elastic Cloud hosted

Browser version: Firefox 89.0

Browser OS version: macOS

Original install method (e.g. download page, yum, from source, etc.):

Describe the bug:

The event.original field is missing in Kibana Discover for some events.

Steps to reproduce:

  1. Ingest data using a Beat that creates event.original.
  2. Open discover and look at the field event.original. Note that some events appear to be missing event.original.
  3. Get one of the event's _id and query it directly from Elasticsearch and it will have event.original.
  4. I'm attaching a file that contains both the Kibana discover JSON and the direct ES query output.

missing-event.original.txt

Expected behavior:

event.original would be displayed. Or if it is being dropped for some reason, such as length, that there would be an indication that this is happening.

One interesting data point is that querying for _id:aKSBznkBdD5BTT25BM6w and event.original:* returns no results so even the KQL query seems to think that event.original does not exist despite aKSBznkBdD5BTT25BM6w having an event.original.

Screenshots (if relevant):

Errors in browser console (if relevant): There are none.

Provide logs and/or server output (if relevant):

Any additional context:

I'm not sure if it has something to do with the length of the field or possibly the field's content. I saw this in cases where the event.original contained both JSON and in a Windows event log use case where event.original contained a big XML blob.

My workaround has been to modify Kibana advanced settings to turn on discover:searchFieldsFromSource (this will affect runtime fields and fields not in _source).

@andrewkroh andrewkroh added the bug Fixes for quality problems that affect the customer experience label Jun 2, 2021
@botelastic botelastic bot added the needs-team Issues missing a team label label Jun 2, 2021
@tsullivan tsullivan added the Team:Visualizations Visualization editors, elastic-charts and infrastructure label Jun 9, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app (Team:KibanaApp)

@botelastic botelastic bot removed the needs-team Issues missing a team label label Jun 9, 2021
@kertal kertal added the Feature:Discover Discover Application label Jun 9, 2021
@andrewkroh
Copy link
Member Author

The mapping for event.original has ignore_above: 1024. The theory is that because it's not indexed that it doesn't show up in the fields that are returned by the query. The docs do say that it honors ignore_above.

        "event": {
          "properties": {

            "original": {
              "type": "keyword",
              "index": false,
              "ignore_above": 1024
            },

I can replicate what I was seeing initially in Discover with this query. fields does not contain the event.original for the long values.

GET journalbeat-8.0.0-2021.05.07-000013/_search
{
  "query": {
    "term": {"_id": "aKSBznkBdD5BTT25BM6w"}
  },
  "fields": [
    "*"
  ]
}

I think this will be mitigated by #95946 (comment). And we could bump the ignore_above slightly for some Fleet integrations that are expected to have larger event.original values.

@kertal
Copy link
Member

kertal commented Jun 15, 2021

@andrewkroh thx for opening this issue, we will investigate

@timroes
Copy link
Contributor

timroes commented Jun 15, 2021

Blocked on: elastic/elasticsearch#74121

@timroes timroes changed the title Sometimes fields (event.original) are missing from Kibana Discover Values above ignore_above mapping limit don't show up in Discover anymore Jun 15, 2021
@timroes
Copy link
Contributor

timroes commented Jun 22, 2021

Discussing the desired behavior with PMs, we came to the following conclusion: We want to show ignored values (e.g. because they are above ignore_above) in the Discover table in columns and expanded documents directly. We'd additionally want to add a warning icon with a tooltip beside them explaining that those values are not indexed, and thus cannot be searched through.

@timroes timroes added the impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. label Jul 15, 2021
@timroes timroes added Team:DataDiscovery Discover, search (e.g. data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL. and removed Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Aug 31, 2021
@timroes timroes self-assigned this Oct 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked bug Fixes for quality problems that affect the customer experience Feature:Discover Discover Application impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. regression Team:DataDiscovery Discover, search (e.g. data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants