Kibana CSV export fails with 'index_closed_exception'

[rgr78]

Kibana version: 6.2.2

Elasticsearch version: 6.2.2

Server OS version: RHEL 7

Browser version: Google Chome Version 66.0.3359.139 (Official Build) (64-bit)

Browser OS version: Windows 10 1609

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

Description of the problem including expected versus actual behavior:
Using Kibana, when exporting a CSV from an index pattern which includes closed indices, Kibana reports the exception 'index_closed_exception', and fails.
It should ignore the closed indices, and use the open ones.

Steps to reproduce:

1. Create two identical indices
2. Put some events on them
3. Create an index pattern in Kibana which includes both indices
4. Close only one of them.
5. Export a CSV, which will fail.

Errors in browser console (if relevant): Not relevant

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

Discussion thread with more details: https://discuss.elastic.co/t/export-to-csv-fails-with-index-closed-exception/130840

[stacey-gammon]

Sounds like the fix for this will be relatively simple, but it deserves tests to go along with it, and that will take some extra time.

[tsullivan]

Sounds like the fix for this will be relatively simple, but it deserves tests to go along with it, and that will take some extra time.

I'm interested in taking this on. The fix suggested by @kobelb in Discuss was to use the ignoreUnavailable: true flag in the query to get data for CSV. We do that in many places to avoid problems like this, also avoid throwing a 404 error when an index doesn't exist, when a 404 isn't useful. I'm not super sure it merits additional testing, other than ensuring things work smoothly when the response has 0 hits.

[tsullivan]

Hi @rgr78 on further inspection, I was not able to reproduce the issue in our master branch, and I went back to 6.4.2 and wasn't able to reproduce it there either.

I'll check if something changed in Elasticsearch to make this more lenient. When I try a raw multi-index search where the pattern includes a closed index, I am not seeing an exception happen.

[joelgriffith]

After testing this on 6.2.4 and 6.2.2 I'm unable to reproduce as well. It's entirely possible that I'm missing something in my setup. FWIW here is what I've done in detail:

• Pulled both ElasticSearch and Kibana 6.2.2 from docker, and used docker-compose to boot them.
• Created 3 log indices from here (Note that the timestamps are from 2015, so you'll have to update time filters in the Discover area).
• Created a index pattern of log* in Kibana.
• Did some generic CSV export in discover.
• Closed one of the three indices in DevTools (using this document).
• Re-exported that same CSV.

Given the inactivity on this ticket, and both @tsullivan and I being unable to reproduce on multiple versions, I'm going to close this issue. Please feel free to re-open if either of us have missed something, or if this is still a problem. We'll likely need more details as it's apparent we've missed something in either case.

[joshdover]

I was able to reproduce this on 6.6.1 and 7.3.0.

I believe it has to do with an aliasing & Security bug in Elasticsearch: #20920

Steps to reproduce (security enabled):

• Create two indices:

PUT data1/_doc/1
{"test":"test"}

PUT data2/_doc/1
{"test":"test"}

• Create an alias that points to both:

POST /_aliases
{
    "actions" : [
        { "add" : { "index" : "data1", "alias" : "alias1" } },
        { "add" : { "index" : "data2", "alias" : "alias1" } }
    ]
}

• Close one of the indices:

POST data2/_close

• Create an index pattern in Kibana that matches the alias: "alias*"
• Open the new index pattern in Discover
• Try to export CSV
• See error message

[tsullivan]

There seems to be a category of bugs with CSV generation when the data is visible in Discover but breaks in CSV.

As for more in that category:

• [Reporting] Not able to generate CSV report on object fields; Discover is able #25068
• CSV report (saved search@dashboard): defer to the dashboard panel's selection of fields, not the fields in saved search data #43977
• Reporting URL from Discover has no relative time range mode #22261

@elastic/kibana-app we need to team up on how to unite the code. Are there resources that exists in re-usable server-side code that CSV generation can share? So far, to build these features we've had to reverse-engineer Discover code. Fixing the bugs as they come in will feel like we're fixing bugs that Discover team has fixed before.

[MikeD-Respond]

getting this error

Unable to generate report
[index_closed_exception] closed,

when trying to generate CSV report,

Any update on when a fix might be available?
Is it helpful to provide the error message I got

[tsullivan]

@elastic/kibana-app how do you handle closed indices in Discover?

[MikeD-Respond]

I've read through this several times and I'm not sure if I'm understanding everything. Also full disclosure I did not set up our ELK stack - I'm just a user thru Kibana.

Is this an Kibana bug?

Is there something we did in the setup of our indices that is causing this problem that we could possibly change that would address this problem?

Is there any more information I can provide that will help with the resolution of this issue?

Thanks - Mike

[tsullivan]

Is this an Kibana bug?

Hi, this is a Kibana bug where CSV Export is not properly ignoring closed indices when they are involved in the pattern of indices to search against. I need to work with @elastic/kibana-app to find an appropriate change to make in the code.

The workaround isn't nice, but it would mean not having any closed indices for the saved search's index pattern.

[timroes]

According to elastic/elasticsearch#15730 using the (as far as I can tell undocumented) ignore_unavailable=true request parameter would exclude those indexes. But due to the lack of documentation I have no idea what else it might exclude. For me this doesn't feel like something we must handle in Discover specific, but need to address in either the index pattern services or data access layer. Will move this to app arch team.

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[lukasolson]

If this is a matter of sending ignore_unavailable=true in the request, it should be just a matter of using the data plugin search service in the CSV reporting functionality.

[tsullivan]

Relevant PR for consolidating the Reporting CSV generation code: #67027

I'm not sure if the data plugin is ready to be used on the server for replacing Reporting's CSV generation logic. Right now Reporting has to duplicate a lot of functionality built-into Discover, and we have had to reverse engineer Discover's features to build them into the server-side for export. The steps we take to build the query DSL, inject filters, add the required request parameters, etc - is all outside of the domain of Reporting Services. These things are integration concerns of Discover export.

We need to define a saner payload of parameters for exporting CSV. The payload to export CSV should just be: the ID of the saved search, client time zone for formatting, and date filter parameters. Currently, the payload of parameters is a lot of blobs of JSON that Reporting has to figure out what to do with.

[tsullivan]

Will be fixed in #67027

cafa929

[elasticmachine]

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

[tsullivan]

Closed in #67027