Use index-pattern by name and not by ID

Elastic Stack Kibana
1

Using index-pattern ID is not clear at all.
For example i have a problem - i have dasboards, that use "winlogbeat-*" index-pattern and than i delete it (during trying fixing a problem). And that create it again. Now all my dashboards and visualisations are broken.
"Could not locate that index-pattern (id: winlogbeat-*), [click here to re-create it]" but this index-pattern exist!
03
I even can't import saved searches in JSON format - it generates same error. You cant "click here", because it is not a link. And re-creation of the same index-pattern doesn't help.
So, my questions:

  1. Why i cant use index-pattern name instead of id?
  2. Where can i find hardcoded IDs in dashboards, for example and change it?
  3. How can fix this problem and not re-create every visualisation and search?
1 Like
2

I add more screenshots to better understand the problem.
I have this error, if i open any built-in visualisation or search through "Saved objects" and close it.
07
And if i click a link to create that index-pattern, i will get an error - it already exist. So i coundn't do anything.
50

3

Hey @smerzlyakov,

Replied to your ticket at github. Let's continue discussion here to get it more visible to other people who may experience this as well. Happy to help if you're still having issues with that.

Best,
Oleg

4

Ok, so the main question - is it OK behaviour with broken saved objects?And how to fix this problem?

5

So now you have a new windlogbeat-* index pattern and it has a new ID. If you open this index pattern in Kibana you should observe this new ID in the URL. Then you can go to the Management -> Saved Objects and edit the source of broken SO (update index pattern ID to the new one, see references field).

6

Thank you for your response, but the main problem is that there is NO ID in saved object in referense field. There is only "winlogbeat-*" string.
18
It is FULL code of reference field for built-in "Winlogbeat - Successful User Logon" visualisation.

[
  {
    "name": "kibanaSavedObjectMeta.searchSourceJSON.index",
    "id": "winlogbeat-*",
    "type": "index-pattern"
  },
  {
    "name": "kibanaSavedObjectMeta.searchSourceJSON.filter[0].meta.index",
    "id": "winlogbeat-*",
    "type": "index-pattern"
  },
  {
    "name": "kibanaSavedObjectMeta.searchSourceJSON.filter[1].meta.index",
    "id": "winlogbeat-*",
    "type": "index-pattern"
  },
  {
    "name": "kibanaSavedObjectMeta.searchSourceJSON.filter[2].meta.index",
    "id": "winlogbeat-*",
    "type": "index-pattern"
  },
  {
    "name": "kibanaSavedObjectMeta.searchSourceJSON.filter[3].meta.index",
    "id": "winlogbeat-*",
    "type": "index-pattern"
  },
  {
    "name": "kibanaSavedObjectMeta.searchSourceJSON.filter[4].meta.index",
    "id": "winlogbeat-*",
    "type": "index-pattern"
  },
  {
    "name": "kibanaSavedObjectMeta.searchSourceJSON.filter[5].meta.index",
    "id": "winlogbeat-*",
    "type": "index-pattern"
  }
]

I also double-check all other fields - there is no ID.
So, where it can be hardcoded?

7

I also double-check all other fields - there is no ID.
So, where it can be hardcoded?

Hmm, I think I see your problem now. So your visualization is actually easy to fix it seems since it's referring to an index pattern with a custom ID ( winlogbeat-*, if you don't specify custom ID Kibana will generate UUID-like ID instead). So I guess your issue here is that when you re-created an index pattern for winlogbeat-*, you didn't specify this custom ID and Kibana generated a random UUID for it. Can you try to delete index pattern (assuming you don't have anything important in it, like scripted fields, otherwise - back it up first) and re-create it with a custom ID (see gif below):

index-pattern
index-pattern1912×966 403 KB

2 Likes
8

Thank you!That helps! By the way, now i broke another visualisations, that uses IDs)
But it is not a big problem, i hope i will fix it by exporting in JSON - script renaming and importing again. By thae way - is there is an option to export in json pretty readble format instead of Ndjson?
So, i hope that Elastic team separate this termins soon in https://github.com/elastic/kibana/issues/44955
So, i think it is better to move all index-patterns to IDs and not custom strings?What is best practice?

9

Thank you!That helps!

Nice, glad it helped!

By thae way - is there is an option to export in json pretty readble format instead of Ndjson?

No, it's not possible out-of-the-box since import supports only ndjson and corresponds to what Elasticsearch uses for _bulk operations.

So, i hope that Elastic team separate this termins soon in https://github.com/elastic/kibana/issues/44955

Yeah, we'll try to make index-pattern story less confusing for sure.

So, i think it is better to move all index-patterns to IDs and not custom strings?What is best practice?

I don't think there is a best pracise necessarily because it depends on your usage pattern. Some people prefer to use "human readable" IDs or plan to delete/create index patterns without breaking all dependent visualizations. But at the same time custom IDs are not "unique" enough that may lead to collisions when you decide to import index pattern that has exactly same ID (say your collegue also uses human readable names for index patterns). So since we're in a process of improving this, I'd advice you to use approach that works best for you right now.

10

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.