Automatic Index Creation on Indexer


I have a use case where we want build trust between app server and Splunk indexer such that whenever there is post message from app server to the Indexer it should check the index = app name ; if it do not find the index then create one. We are using HEC events.
How is it possible ?
Also is there any performance issue on Indexer because of it?

Tags (1)
0 Karma

Esteemed Legend

No, the closest that you can do is to define a lastChanceIndex in indexes.conf:

lastChanceIndex = <index name>
* Gives ability to define a last chance index for events destined for
  non-existent indexes.
* If an event arrives whose index destination key points to an index that is
  not configured (such as when using index=<index name> in the input stanza or
  by a setting in a transform), it will route that event to the index specified
  by this setting.  The index destination key of that event will be overwritten
  with the specified index name before routing.
* <index name> must name an existing enabled index.  Splunk will not start if
  this is not the case.
* If this setting is not defined or is empty, it will drop such events.
* If set to "default", then the default index specified by the
  "defaultDatabase" will be used as a last chance index.
* Defaults to empty.

Then you can have an alert to notify an admin that new data has arrived. The admin can VERY easily rename the lastChanceIndex as the proper index at which point the data will go into the new index alongside the old data.

0 Karma


Hi rashi83,are you sure of this idea?
in this way you loose the control on indexes creation!
I suggest to analyze your need and put data on a limited number of indexes.

Remember that indexes aren't DB table so you can put different logs in the same index, because they should be divided by sourcetype.

The main rules to put logs in indexes are the following:

  • access rules: data access in Splunk is managed at index level, so you should put in the same index logs with the same access rules,
  • retention policies: you should put in the same index logs with the same retention policy.

In addition, you could analyze you log flows and divide logs based on the timing ingestion: in other words don't put logs of a flow with few data in the same index with logs of a large flow.

At least, you could also divide logs in indexes based on a logical division, but this isn't mandatory.

Anyway I hint not exagerate with the number of indexes, because you cannot manage them.


0 Karma