I'm writing an app that I know will index loads of data and then do some calculations on changes from day to day. To make my dashboards and reports faster I want to include saved searches that put data into a summary index. What is the best practice on this? The docs imply that all summary indexes needs to be configured via the ui, which will put the saved searches in local/, does that mean that you're not supposed to have summary indexes in apps by default?
http://www.splunk.com/base/Documentation/4.1.2/Knowledge/Configuresummaryindexes
Thanks
The docs may give that impression but no it's quite common for apps to have preconfigured summary indexing searches. The windows app is a common example - it runs a search called win_eventlog_count_sum_index and you'll see the relevant stanza has summary indexing going on, and it's just sitting in the app's default directory.
I think some app developers have success using the manager UI to create and edit items destined for an app, and then they use the manager UI to 'move' the items up into the app space. Possibly there's some final merging of the app/local into app/default, im not sure.
And other crustier app developers just bypass the UI and manually create and edit the app's default config on disk, refreshing changes by either hitting the refresh endpoint or restarting the server.
The docs may give that impression but no it's quite common for apps to have preconfigured summary indexing searches. The windows app is a common example - it runs a search called win_eventlog_count_sum_index and you'll see the relevant stanza has summary indexing going on, and it's just sitting in the app's default directory.
I think some app developers have success using the manager UI to create and edit items destined for an app, and then they use the manager UI to 'move' the items up into the app space. Possibly there's some final merging of the app/local into app/default, im not sure.
And other crustier app developers just bypass the UI and manually create and edit the app's default config on disk, refreshing changes by either hitting the refresh endpoint or restarting the server.
yeah, the doc was written with end users in mind more than developers. we'll add some information explaining the available options for developers.