So basically there is an app in one of our universal forwarders that monitors a file. Recently we decided to stop having that file forward its data. For some reason blocking it (using the props and transform combo) doesn't seem to work, but, in a test environment I have determined disabling it at the app level by setting [install] to be disabled in the app.conf and it works (it indexes next to nothing since its coming from a demo machine which would only be used internally). However, I tried in our production environment (~100 events a second) and its still indexing that data.
So my question is, is there an amount of time it will pick up the changes for the new config? Or should it have been working instantly?
So I think changing the state = disabled worked after all. It appears that two things happened
1) I had to restart splunk again on the universal forwarder that I disabled it on (it didn't seem to take, while others did)
2) I had to wait for a time for the affects to take (in my case, it seemed to take 7 hours).
I'm not altogether sure why, and I could be wrong in that it takes time to become disabled, but now it is completely blocked.
Is it perhaps the amount of traffic it receives and therefore how often the logs are written to? So it may need to wait until it isn't receiving any more?
Not sure if you're managing your forwarders through the Deployment Server or not, but in either scenario, setting the state of the app to disabled in it's app.conf will disable the app.
state = disabled | enabled
That said, in order for your forwarder to pick up that change, you must restart it.
If you are using the Deployment Server, you should either comment out the app from being sent, or blacklist the machine from the stanza that ships the app. By doing so, you will guarantee that the data will not be monitored at all, and therefore not sent to your indexers.
Another option would be to comment out the stanza in your inputs.conf to prevent it from being monitored, and then restart the forwarder.