Forums: SplunkAdministration: Best way stop "sample_app" logs events from being forwarded to the primary indexer

I recently upgraded several forwarders to Splunk 4.0.10 and found that in doing so new events were sent to the indexers "sample" index.

I use a client/serer deployment setup and have a "dummy" app (simply an empty folder) that gets deployed over top of splunk's "sample_app" folder and therefore wipes out all sample_app logs and configuration settings. (Since there is no way to have one application "disable" another app, as there was in Splunk 3.4.x ). I think what's happening is that when I install a new version of splunk, the "sample_app" gets installed again, and the deployment client doesn't know that it needs to overwrite (aka obliterate) the "sample_app" folder, because it hasn't changed on the deployment server, and the client doesn't know that it's locally deployed app was modified, and therefore should be deploy again. This is especially frustrating on Windows where the installer starts splunkd automatically, before you can go manually delete the "sample_app" folder.

So, what's the best way to deal with this? (I have a couple different ideas, but I'm not sure what's the best/recommended approach)

1.) Setup a props rule in my forwarder app, something like:
[source::$SPLUNK_HOME...sample_app...]
sourcetype = ignored_type

2.) Simple disable the forwarder input in my forwarder app, using something like:
[monitor://$SPLUNK_HOME/etc/apps/sample_app/logs]
disabled = 1

(Obviously need to make to version, one for unix, and one for windows)

3.) Disable the "sample" index on the indexer. I think in this case the events are simply dropped, I think. Sometime things seem to end up in the default index, which would be an even bigger pain.

4.) Use some kind of transformer to route to the nullQueue.... i dunno. Is there a way to setup the indexer instance so that it takes all data destined for one index and sends it somewhere else? I'm not sure how you would set that up.

5.) Do some deployment voodo, and deploy a new app for different version of splunk. (I think that's possible, I'd have to check the docs). But this may not happen fast enough to keep the sample_data from being sucked in before the deployment process happens.

I'm looking for any thoughts or suggestions. Thanks,

- Lowell

If you want to make sure sample_app stays disabled between upgrades, just put this into $SPLUNK/home/etc/sample_app/local/app.conf

[install]
state = disabled

This file will not get overwritten on upgrade, or in your case (using Deployment Server) just make your dummy app contain a local/app.conf with the above contents, rather than being completely empty.

[Revised on Thu, 18 Mar 2010 13:46:12 -0700]

You can also use the "stateOnClient = disabled" flag in serverclass.conf, but it's kind of ugly, and you still need to make sure the "local" folder exists. (at least in some versions).