Best Practices for Managing Applications from Splunkbase?

[mburgess97]

On the topic of managing applications from Splunkbase, I have a few questions. Take the TA-Exchange-Mailbox as an example:

Firstly, the installation documentation for this application seems incorrect. While it references the application being installed at the Collection tier/input phase, it doesn't mention anything about the Search Tier/Phase, despite the existence of stanzas in props/transforms. Is the installation location implied?

Here are the links to the documentation for reference:

• https://docs.splunk.com/Documentation/Splunk/9.0.4/Admin/Configurationparametersandthedatapipeline
• https://docs.splunk.com/Documentation/AddOns/released/MSExchange/About#Splunk_Add-on_for_Microsoft_E...

Secondly, how should I manage the application at the various tiers of my deployment? The TA-Exchange-Mailbox application has inputs, props, transforms, and so on. Should I delete inputs.conf before putting the application on my Search Head? Do I delete props or transforms before adding to my Universal Forwarders? If it doesn't matter because Splunk will only use what is appropriate at various phases, then I can manage a single app with all of the configs and deploy everywhere, which seems to be the least overhead.

Thirdly, if I need to modularize the application and apply config files at their respective tiers, can I rename it? This way, I would have two separate applications to better manage changes in source control:

• TA-Exchange-Mailbox_inputs
• TA-Exchange-Mailbox_props (or parsing or whatever)

I would appreciate any advice or best practices on managing applications from Splunkbase. Thank you!

[PickleRick · Accepted solution]

There isn't a "one size fits all" solution.

Ad.1 True, the add-on does seem to contain search-time definitions. Submit a feedback on the documentation page. It works 🙂

Ad.2 Typically, well written add-ons will have inputs defined but disabled by default. So you can push your app with the default settings and enable the input you want either by placing proper settings in app's local directory or by creating another app. But I don't trust any non-splunk supported apps and review all apps before deployment.

Ad.3 If the app is properly written - see above - you can push the whole app to all needed tiers. Unused configurations will be... well, unused. OK, if some app needs a huge blob of code to run or something like that, you might reconsider splitting it up into smaller chunks.

I would probably have the app with default settings in default directory and overwrite the settings in local directory before pushing to indexers/SHs/forwarders. Unless there were specific settings, for example, pushed differently to different classes of forwarders. Then I'd probably split the local settings into several apps.

As I said - there is no one "right" choice. It's up to you to make it easy to understand, convenient to manage and cheap to maintain. If you get some convention, stick to it so that a person which comes to maintain the environment after you've been struck by a bus is not surprised too many times 😉

[richgalloway]

You can put the add-on on all instance types.  The most important thing to do is ensure the input runs on only one server, either a UF or HF.  All other instance types should have the input disabled.

Put the same add-on on your SH, your indexers or Cluster Manager, and on your Deployment Server (DS).  Use local/inputs.conf to disable inputs on all except the DS.