What is .ent-search-*-logs-*,-.ent-search-*? where is it from?

Elastic Stack Elasticsearch
1

Hi everyone,

In everyone of our Elasticsearch instances in Azure, there is a persistent setting entry like below:

"action.auto_create_index": ".ent-search-*-logs-*,-.ent-search-*,+*"

But nobody remembers/knows who added this setting and which applications/processes would create such indices .ent-search--logs-.

I do find similar settings in this community but it's still not clear where this index pattern comes from, below are a few examples:
cant-connect-to-endpointbase-from-aws-server
how-to-print-logs-in-json-format-for-enterprise-search
not-able-to-view-overview-page-analytics-page-api-logs-page-in-appsearch

I wonder if anyone could help me understand this, appreciate it.

2

This is related to Enterprise Search, another tool from Elastic that integrates with Elasticsearch.

There is a similar configuration setting mentioned here.

1 Like
3

That’s great! Finally I got an official document mentioning this!

The thing is, we have this index name patterns in all of our Azure ES deployments but none of our GCP deployments — all GCP ones have auto_create_index = true.

What can be the cause for the difference?

4

By deployement you mean Elastic Cloud or just VMs running in Azure or GCP?

If it is Elastic Cloud you may need to check with support, if it is just VMs you need to check with who created the clusters.

Changing this setting is basically not required unless in specific cases.

5

I believe it's Elastic Cloud. we're managing the deployments at https://cloud.elastic.co

Thank you @leandrojmp I'll check with support.

6

Hi @Richard_Zhang the above indices most likely depends on whether deployed the Enterprise search / features / components.... Whether on purpose or accident

It can also depend on when they initially deployed, upgraded etc... the clusters lifecycle.

The components could have been removed but that does not necessary mean the backing system indices would get removed

Curious why the focus ... Soon these system type indices will be completely hidden...

I will be the first to say that our documentation can be better... But I have been a reading a few of your posts and am trying to figure out what you're are trying to accomplish.

There is a lot going on in Elasticsearch... It can be easy to get distracted ... With less important items ... But perhaps these are really important for you.

In short auto create is an important feature...
I work with 100s of clusters and very very few disable that setting.

Properly creating indices or proper dynamic mapping are often better approaches

Also least privilege can be used with clients so I they can not randomly create indices etc..

1 Like
7

Thanks for reading my other posts as well to figure out my circumstance.

Curious why the focus

Yes, as you know, the focus is on auto_create_index.

In short auto create is an important feature...
I work with 100s of clusters and very very few disable that setting.

We're trying to make sure only a whitelist of name patterns be allowed to auto creation, the purpose is to prevent some random indices are created without knowing.

Currently, we don't use index templates in our system and it's an existing system for which we only want minimal change to achieve that effect. So we feel like making auto_create_index a whitelist is the most straightforward and simplest option to go with.

I'm considering if someone can help or some official documents can recommend a whitelist that we can put in this setting? we can include more as needed in the future.

8

That sounds like a good approach for your use case.

The official documentation is here complete with some examples

1 Like