How applications work
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Contents
How applications work
A Splunk application can be as simple as a collection of event types and as complex as an entirely new program that uses Splunk underneath the hood. This document is a general discussion of building Splunk applications, linking off to pages handling more specific issues.
Note: Be sure to check SplunkBase to see if there's already an application there that does what you need, or is close enough that it can be modified faster than you can build one from scratch.
Plan your application
Not all Splunk applications need a lot of planning, but it certainly doesn't hurt to give some thought to what you're trying to do before you start. Some things to keep in mind:
- The more complex the application, the more beneficial you may find it to utilize your preferred flowcharting method to lay out the logic/process first.
- It is in general a good idea to use the Splunk Application Standard so that your application will interact seamlessly with other Splunk applications.
- Do you intend to share this application on SplunkBase? If so, when you pull out the pieces to make the sharable version, be sure to alter any vital internal information so you aren't revealing anything. You may find it useful to mark a section off in the configuration with text that explains that the user should change these values to their own internal ones.
You also want to try to think of an application at two different levels:
- General applications - The overall logic, which consists of using Splunk Application Standard-compliant field names, event type tags, and host tags along with the tags that you use internally. This component shouldn't at all deal with preparing the data from any particular technology to integrate with the Splunk Application Standard.
- Data-level applications - Focuses just on a particular technology (for example, sendmail), bringing it into compliance with the Splunk Application Standard. If necessary, an application may also have a separate section devoted to bringing the data into compliance with your own internal tagging and other standards, or you may choose to make a third application that just handles your internal needs. The two different approaches are illustrated in Figures 1 and 2.
Figure 1: Creating separate applications for a particular technology and for your internal needs can be one way of maintaining your company's settings, without having to scrub them before sharing an application with the public.
Figure 2: Creating a section for your internal settings inside an application built for a specific technology allows you to maintain things in one place, but may need to be scrubbed to prevent sensitive internal from escaping into the wild.
And, of course, as with any code or scripting, it's always a good idea to add comments in your application as much as possible. That way, you don't have to remember why you set up a stanza the way you did, and someone else needing to change the configuration doesn't have to reverse-engineer things.
Apply the Splunk Application Standard to your data
Once you know which data sources (log files, configuration files, etc. for particular technologies) your application needs to interact with, you can look at samples of this data side by side with the Splunk Application Standard. See How to apply the Splunk Application Standard for a discussion on how to do this. You may find that somebody else has already done part of the work!
Build your application
At this stage, it is more useful to look at specific documents discussing different features your application has than it is to discuss building in general. Documents of interest here include:
- The Splunk developer docs
- The resources listed here
- The Splunk admin guide's reference section
Test your application
Once you've built your application, it's wise to test it and ensure that it works as expected. Be sure that if you directly edited or created configuration files, that you've restarted your Splunk instance to load them. Then walk through the process of using the application as someone in the field would, or get a few people in the field to do so and report back their experiences and suggestions.
The larger variety of data you have loaded when testing, the more you can be sure that you aren't going to generate false positives and other unexpected results.
You can share your application with the rest of the Splunk community through SplunkBase. To do so, you'll need to package it up, which means pulling all of the pieces out of your general Splunk configuration and into a collection of isolated files meant just for this application. Documentation helpful toward this goal is the Splunk developer docs.
In general:
- Create a new directory in
$SPLUNK_HOME/etc/bundlesfor your application. Name it something meaningful so people can easily spot it among the other applications. - In the new directory, create the files you'll need. You may find the list of configuration files helpful.
- If you saved event types, searches, fields, or other items out from the UI, you will find them in the configuration files contained in the directory
$SPLUNK_HOME/etc/bundles/local. Just copy the relevant stanzas out to your new files in your custom directory. - Don't forget to alter or remove any items that reveal too much about your internal information.
- Make a final pass over the comments in your application to make sure they're clear and people understand what changes they need to make and what each section does.
Once your application is ready to go, upload it to SplunkBase for the rest of the Splunk community to share.
This documentation applies to the following versions of Splunk: 3.2 , 3.2.1 , 3.2.2 , 3.2.3 , 3.2.4 , 3.2.5 , 3.2.6 View the Article History for its revisions.