What are the best practices for creating and distributing apps to UF from a DS in a Splunk Cloud scenario?

[pvarelab]

I have a Splunk Cloud instance where we send logs from servers with the Universal Forwarder installed. All UF are managed by a Deployment Server.

My questión is: what are the best practices on howw to organize apps, both Splunkbase downloaded and in-house built and also configuration-only apps, if they are a best practice?

Right now we are experimenting with deploying the Splunkbase apps as they are (easier to update them) and deploying the configuration in an extra app named starting with numbers so its configuration takes precedence. But we have run into some issues in the past with this approach.

[PickleRick · Accepted solution]

The approach may differ but there are typically two approaches

1) You push whole preconfigured app (for example with already enabled inputs) - the upside is that you can - if needed - selectively upgrade it across serverclasses and easier keep track of versions. The downside is that you need to store each copy of the "main" app and separately apply needed config changes to each "instance".

2) You distribute the base app separately and separately distribute app(s) containing default and custom settings. - It's  easier to maintain specific settings for small serverclasses using layering. But if you need to prepare separate configs for separate main app versions, it's getting bloated.

But I'm more of a fan of the second approach - split your config into small pieces, isolate them into separate apps and push them selectively where needed.

And it has nothing to do with Cloud or on-prem. It's a general idea of maintaining pushed apps.

[pvarelab]

Your second approach is what we are trying to do now, and it has worked very well for the most part, but we've run into some issues with file precedence —when using the [default] stanza.

I guess we'll keep doing this, since I think, as you do, that it is more manageable to have the small pieces of configuration in their own apps. BTW, we are naming this apps starting with numbers following the example of the 100_app that contains the tls credentials to forward traffic to the cloud.

The issue with the Cloud vs. Enterprise is that to deploy to the cloud you need to pass the inspection proccess, and it fails if you have inputs.conf, which for the forwarders you always want. So that's another good reason to have them in separate pieces.

[gcusello]

Hi @pvarelab,

sorry but your question isn't so clear for me:

you have an On-Premise DS that you use to deploy Apps to your on-premise Forwarders.

At firsrt, I hint to put two Heavy Forwarders as Concentrators to avoid to open an internet connection from all systems and Splunk Cloud.

If you haven't so many clients, you could use one of these HFs as DS.

Then in the DS you store all the apps to deploy to the clients and you deploy them based on ServerClasses.

Why do you want to manage a precedence in installation? you should deploy already configured apps.

The only attention point is to analyze your deploy requirement and design very carefully your ServerClasses.

Ciao.

Giuseppe