What are some App Best Practices?

[EricPartington]

<p>Looking for some feedback on best practices on how to seperate different sources by app for a splunk install.
there will be individual support teams interested in their technology as well as overall views of all technologies logged with splunk.</p>

<p>Is it best to have an app created for each technology (unix, windows, firewall, webservers) and limit/grant access based on apps?
Is keeping the inputs, props and transforms related to each technology best kept with each app?
How does this help or hinder distributing these apps(and configuration) across distributed search heads?</p>

<p>I will be taking the online course you provide, and that may provide some answers but thought i would ask for the collective wisdom of the 'Answers' people while i wait for my course to start.</p>

<p>thanks</p>

[gmelnik]

Additionally, [Splunk Developer Guide - Building Splunk Solutions]1 contains many good and proven app building practices discussed in the context of real-world apps.

[gkanapathy · Accepted solution]

So, first, I have a partial answer here about how to subdivide an app: http://answers.splunk.com/questions/4559/best-practices-for-installing-and-configuring-apps-in-a-dis...

As for how to decide what to make into separate apps, I'd say there are two sets, and you need to have both kinds:

• Data-oriented apps. These are what I had in mind when I wrote my above post. They basically cover configurations needed in the "Data acquistion" and "Data comprehension" (or "knowledge") phases of a Splunk deployment lifecycle, i.e., inputs.conf, props.conf, transforms.conf for the most part, but also most index-time knowledge and some other search-time "knowledge" that is event or sourcetype-specific

• User-oriented apps. These are the elements like reports, alerts, dashboards, etc., that are built on top of the data, as well as search-time knowledge that is application-specific (as in "application" the generic term, not "app" the Splunk object).

The data-oriented apps, as I said are in the linked post. The latter kind are just split up according to user needs.

One problem right now is that it is sometimes hard to prevent "leakage" between apps, because "exporting" of app knowledge is either everywhere or nowhere (Global or App). But for the most part, it's okay to have the data-oriented apps export globally, and then govern access just to the user-oriented ones.