Note, this is old stuff now… but legacy lives on even when new solutions become available.

What are Splunk Apps and Add-ons? What’s the difference?

• https://docs.splunk.com/Splexicon:App
• https://docs.splunk.com/Splexicon:Addon 

If you’re still confused… it’s not just you. The confusion roots back to fundamental disagreements on approach that are encoded into every product the company has ever shipped, so it’s tough to recommend a meaningful change.

Splunk apps are folders in $SPLUNK_HOME/etc/apps. They’re containers that you put splunk objects into. You can put anything in them: code, knowledge management configuration, dashboard elements, libraries, binaries, images, whatever. If you just want to put some stuff together and run it on your laptop, you’re done at this point. Put things in a folder for organization. Or don’t. Whatever.

If you want to distribute components in a large environment, if you want to depend on shared components, if you want to avoid huge multi-function monoliths, then you start dividing apps into different types. This is why you see the terms “App” and “Add-on” in Splunk. The App refers to the visible front-end app that a user will interact with. The Add-on refers to administrator-only components. This is where the Splexicon definitions start and stop.

There are multiple types of Add-ons. Their definitions are not entirely well established, and have come and gone in official documentation. Right now, it’s here, but don’t be surprised if that breaks:

• http://dev.splunk.com/view/enterprise-security/SP-CAAAFBN

Since I helped to write these definitions in the first place, I feel confident in stating what they should be. However, these rules are breached as often as they are observed, and Splunk themselves are the most likely to ignore all of this guidance. If you want to follow the best possible practice, buy Kyle Smith’s book and read that. Here are the possible types:

IA: Input Add-on

This includes and configures data collection inputs only. In practice, these are rare and the functionality is usually stuffed into a TA.

• Example: Input Add On for G Suite App
• Goes on Forwarders only
• You should absolutely have inputs.conf
• It would make sense to include a binary folder, and some dashboards to do setup and configuration with

TA: Technology Add-on

This includes and configures knowledge management objects. In practice, many TA’s also include data collection inputs. A TA would be able to translate the field names provided by a vendor to field names expected by your users, as well as recognizing and tagging specific event types.

• Example: Splunk Add-on for Symantec Endpoint Protection 
• Maybe goes on Forwarders and Indexers? Definitely goes on Search Heads. See Windex
• You should absolutely have props.conf, transforms.conf, eventtypes.conf, tags.conf
• It would make sense to include lookups and savedsearches.conf
• Many TA’s include all the IA stuff mentioned above. If they don’t, then they don’t need to be on Forwarders, unless there are index-time operations

SA: Supporting Add-on

This includes supporting libraries and searches needed to manage a class of data. Let’s say we’re building a security monitor and considering whether authentication attempts seem malicious or not. An SA could include lookup and summary generators to normalize and aggregate the data from many authentication systems and ask generic questions for reporting and alerting.

• Example: Splunk Common Information Model (CIM) 
• Goes on Search Heads
• You should absolutely have savedsearches.conf
• It would make sense to include lookups and some dashboards, prebuilt panels, modular alerts, modular visualizations
• Some SA’s include all the IA stuff mentioned above.

DA: Domain Add-on

This includes supporting libraries and searches needed to manage a domain of problems. Let’s say we’re considering PCI requirement 4, focused on antivirus software being present, configured, and not reporting infections. A DA might include lookup and summary generators to prepare those answers, dashboards to investigate further, and correlation searches to alert on problems.

• Example: Splunk App for PCI Compliance (the “dirty dozen” PCI requirements that can be measured from machine data are each represented with a DA).
• Goes on Search Heads
• You should absolutely include dashboards, prebuilt panels, modular alerts, modular visualizations
• It would make sense to include lookups and savedsearches.conf

And so finally, the App.

App