Splunk Apps and Add-ons
App versus add-on
An app typically has a UI and appears in the launcher; an add-on (often a technology add-on, TA) supplies inputs, field extractions, lookups, or CIM mappings and usually has no UI. Both share the same layout: default/ (vendor-owned, overwritten on upgrade), local/ (preserved), metadata/, appserver/, bin/, and app.conf.
app.conf and metadata
app.conf holds [package] id and version, [launcher] author and description, [ui] is_visible (hide add-ons from the launcher), and [install] is_configured (forces the first-run setup prompt). metadata/default.meta controls sharing: export = system makes objects globally available, and access = read : [ * ], write : [ admin ] sets role permissions.
Installing and scoping
Install from the UI, Splunkbase, or splunk install app <file> -auth <user>:<pass> -update true. In distributed deployments, place components on the right tier: parsing configs on indexers or heavy forwarders, search-time knowledge on search heads, inputs on forwarders through the deployment server.
Traps
- Editing
default/files, which are lost on the next upgrade. - Forgetting
export = system, so macros and lookups are invisible outside the app. - Installing a search-time-only add-on on indexers and expecting an effect.
- Ignoring version compatibility declared in
[package], or leaving noisy update checks enabled.
Rule of thumb
Local for edits, default for vendor content, system for sharing. Every customization belongs in local/, and only export what genuinely must be global.