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!

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...

New in Observability Cloud - Explicit Bucket Histograms

Splunk introduces native support for histograms as a metric data type within Observability Cloud with Explicit ...