Getting Data In

DS: Disable specific input (not the app) on a specific UF host

Kindred
Path Finder

We have one host where one of the inputs in an app distributed by the Deployment Server is causing too much traffic.

As the App is distributed by the DS, is there any way of disabling a specific input on a specific server? (or server class)

You can obviously blacklist the host for the entire app - but the rest of the app is providing data we need, just one input is causing an issue.

0 Karma
1 Solution

FrankVl
Ultra Champion

I see three options:

  1. As @gpradeepkumarreddy mentioned: create a separate version of the app which you push to this server only, which has the particular input disabled (and stop pushing the original app). Downside: 2 versions of the app to maintain.
  2. Create a small app with only that particular monitor stanza and disabled=1 and give that app a name such that it will take precedence over the original app. Then push this new app to the particular server (in addition to the original app). This should allow you to override the status of that particular monitor input, without having to create a complete parallel version of the app.
  3. Similar to option 2, but put that config manually into system/local on the UF. Bit of a dirty hack, as it cannot be managed from the DS and if you ever forget about that system/local config being there, it could cause a lot of confusion later.

View solution in original post

FrankVl
Ultra Champion

I see three options:

  1. As @gpradeepkumarreddy mentioned: create a separate version of the app which you push to this server only, which has the particular input disabled (and stop pushing the original app). Downside: 2 versions of the app to maintain.
  2. Create a small app with only that particular monitor stanza and disabled=1 and give that app a name such that it will take precedence over the original app. Then push this new app to the particular server (in addition to the original app). This should allow you to override the status of that particular monitor input, without having to create a complete parallel version of the app.
  3. Similar to option 2, but put that config manually into system/local on the UF. Bit of a dirty hack, as it cannot be managed from the DS and if you ever forget about that system/local config being there, it could cause a lot of confusion later.

Kindred
Path Finder

Had similar ideas, with 2) being the most logical. We use Puppet so 3) could be an option, but I don't like two independent systems fighting over control.

I was hoping there was an easier native Splunk DS method but it looks like option 2) is closest to that.

0 Karma

pradeepkumarg
Influencer

You can disable the monitor inside the app. disabled=1. But this will disable the monitor for all the hosts that are getting this app. your best bet would be create another version of this app with the monitor disabled and create a new server class with just the host in question and target the new version of the app.

Get Updates on the Splunk Community!

Build Scalable Security While Moving to Cloud - Guide From Clayton Homes

 Clayton Homes faced the increased challenge of strengthening their security posture as they went through ...

Mission Control | Explore the latest release of Splunk Mission Control (2.3)

We’re happy to announce the release of Mission Control 2.3 which includes several new and exciting features ...

Cloud Platform | Migrating your Splunk Cloud deployment to Python 3.7

Python 2.7, the last release of Python 2, reached End of Life back on January 1, 2020. As part of our larger ...