Getting Data In

Best Practices for Managing Applications from Splunkbase?

mburgess97
Path Finder

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:

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!

0 Karma
1 Solution

PickleRick
SplunkTrust
SplunkTrust

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 😉

View solution in original post

PickleRick
SplunkTrust
SplunkTrust

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
SplunkTrust
SplunkTrust

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.

---
If this reply helps you, Karma would be appreciated.
Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...