Developing for Splunk Enterprise

How would one correctly configure DATETIME_CONFIG for an app that could be installed in either an indexer cluster or standalone splunk?

Influencer

If I had a need for a custom datetime.xml, for example if I need to pull from a non-standard filename, this seems relatively straightforward, but the setting of DATETIME_CONFIG seems awkward.

The Splunk docs state that this must be relative to $SPLUNK_HOME but this feels weird because of differing needs.

As my power users are developing these configurations, they are likely running on their local laptops (standalone Splunk), so that they can setup, test, reset, tweak, test again, etc. very quickly without impacting others. As they are developing apps locally in a standalone environment, their apps (and thus their custom datetime.xml lives under $SPLUNK_HOME/etc/apps/appname)

For resiliency however, our production environments are Indexer clusters. Apps on indexers are ideally centrally managed and pushed from the cluster master. These apps land on the cluster slaves in $SPLUNK_HOME/etc/slave-apps/appname and thus seem to have a different configuration for a custom datetime.xml location.

SO the question is how is it possible to configure DATETIME_CONFIG in an app relative manner (similar to how we can specify scripted inputs relative to the app defining the stanza) That way those developing the app can have the same setting as me who deploys the app across the cluster.

I'll note that yes it is possible to install apps on each slave individually, but then it feels like I'm then doing the job of the cluster master, managing apps that need to be the same across all of my indexers.

0 Karma
1 Solution

Legend

Assume that you have stored the custom datetime.xml as $SPLUNK_HOME/etc/apps/appname/local/mydatetime.xml Then, in the props.conf in the SAME app $SPLUNK_HOME/etc/apps/appname/local, you can put the following stanza

[mysourcetype]
DATETIME_CONFIG = ./local/mydatetime.xml

You can use relative path names in an app, as long as you remember that the dot . refers to the path to the app itself $SPLUNK_HOME/etc/apps/appname.

This is not well documented, but it works.

View solution in original post

Legend

Assume that you have stored the custom datetime.xml as $SPLUNK_HOME/etc/apps/appname/local/mydatetime.xml Then, in the props.conf in the SAME app $SPLUNK_HOME/etc/apps/appname/local, you can put the following stanza

[mysourcetype]
DATETIME_CONFIG = ./local/mydatetime.xml

You can use relative path names in an app, as long as you remember that the dot . refers to the path to the app itself $SPLUNK_HOME/etc/apps/appname.

This is not well documented, but it works.

View solution in original post

Engager

This doesnt work in more recent versions and results in the following error:

ERROR AggregatorMiningProcessor - Uncaught exception in Aggregator, skipping an event: Can't open DateParser XML configuration file "./local/datetime.xml": No such file or directory - data_source

So currently you have to use a static path and separate apps per deployment.

0 Karma

Motivator

Could not get this to work on 6.5.2. I know it used to work in earlier Versions.

My previous config was the following:

[cisco:ise:syslog]
DATETIME_CONFIG = ./default/datetime_udp.xml

But resulted in no indexed events from this sourcetype:

03-02-2017 16:18:13.956 +0100 ERROR AggregatorMiningProcessor - Uncaught exception in Aggregator, skipping an event: Can't open DateParser XML configuration file "./default/datetime_udp.xml": No such file or directory - data_source="/data/logs/cisco_ise/acs11.example.com/syslog-2017030216", data_host="acs11.example.com", data_sourcetype="cisco:ise:syslog"

I had to change it to the following to make it work:

[cisco:ise:syslog]
DATETIME_CONFIG = /etc/slave-apps/Splunk_TA_cisco-ise/default/datetime_udp.xml

Influencer

Thanks for letting the community know @mikaelbje ! Having not yet upgraded to 6.5.x I personally appreciate the heads up. Have you filed a support case for it (that the rest of us can pile on and say that we're interested too or if they have logged a JIRA out of the case we can have our SEs watch it?)

0 Karma

Motivator

No, no time to open a support case. Since the solution that used to work is not referenced in the props.conf documentation and is possibly only a workaround, I doubt Support will spend much time on this.
Feel free to open a case if required and reference this thread.

0 Karma

Engager

If you use Windows platform, the slash (/) in path should be changed to backslash (\).

0 Karma