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!

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

ICYMI - Check out the latest releases of Splunk Edge Processor

Splunk is pleased to announce the latest enhancements to Splunk Edge Processor.  HEC Receiver authorization ...

Introducing the 2024 SplunkTrust!

Hello, Splunk Community! We are beyond thrilled to announce our newest group of SplunkTrust members!  The ...