Chapter 2. Creating Applications

In this chapter, we will begin covering how to build an actual application. There are many different ways to create an App, ranging from GUI creation to manual editing of configuration files. We will cover the structure of an application, what each folder should contain within the application, and why this is important. Another aspect that will be touched on will be the data that your application will consume. Setting up the data structures beforehand may save you time and energy later on if you have to refactor. It is crucial to get the data in correctly the first time, as any subsequent release of your app will need to make use of the data. We will cover various methods for data consumption, as well as the types of Splunk knowledge objects that can be included in your application. Restricting access to your application may be a priority, so we will also cover metadata and object permissions. Getting your application installed may require your end user to...

A brief clarification

As we continue to progress through this book, we will create an App from the ground up. The App's name is SDG (from a filesystem perspective) and the App label will be Developer's Guide for Splunk. It will be available in its entirety on Splunkbase at https://splunkbase.splunk.com/app/2693/. Additionally, we will be using an API provided by meh.com, a daily deal site that was kind enough to build an API to their website. They were chosen primarily because they fit the geek culture pretty well, and provide a very simple-to-consume API. The data that will be consumed is pulled from their website's API using scripted inputs located in the bin folder of the sample SDG application.

Let's recall the questions from Chapter 1, Application Design Fundamentals, that revolve around App creation. We should answer some of them in preparation for building our demo App:

• Identifying the use case:

  • We are building this App as a learning experience for the reader. By providing an App at...

Methods of creating applications

There are two basic ways of creating applications. They are as follows, in order of difficulty (not that any of them are hard): Splunk Web (we will call this the GUI), and handwritten (henceforth to be recognized as FreeForm). In order to create Apps, you, the developer, must have specific permissions within the Splunk instance.

Tip

Pro tip

Set up a brand new instance of Splunk with a dev license to make sure that you have all the proper permissions to develop an App.

For the GUI method, the user must be an admin within Splunk; additionally, for the FreeForm method, the user must have server access to the command line with as many permissions as required by the user that runs Splunk.

GUI

We will start with the GUI method. This is the simplest of the methods, since access to this feature can be granted via an external authentication system (if authorization is configured within the Splunk instance), or with the built-in role-based access measures. The first step...

Basic application structure

Now that the App has been created, let's take a look at some of the folders that were created, what they may contain, and how they are used with the App. The folders we are going to look at come from the App that was created via Splunk Web.

appserver

The appserver folder contains configurations and other files that relate to some of the inner-workings of the App. In extremely advanced Apps, additional modules and MVC controllers (controllers provide the link between you and the system) are inserted into this folder. For the purpose of this book, we will focus on the static directory, which contains the JavaScript, CSS, and other assets required by the App.

bin

The bin folder contains binary assets, such as those used for modular inputs, scripted inputs, or custom commands. These are most likely Python files, shell scripts, or PowerShell scripts.

default

The default folder contains all the App publisher's configurations and views. When packaging Apps for publishing,...

Application data

Now that we have created a new App, we can start working on how we need our data indexed. Typical Apps may contain configurations for their own indexes, source types, and other input methods.

Indexes

Indexes are very useful in a new App as they allow you to physically separate the data on the disk on the indexers. This helps speed up searches and optimizes macros and event types, since only a smaller subset of data will be searched within the App. The configurations of the indexes are in the indexes.conf file, in the default folder. For our App, let's add an index. The configuration looks like this in the indexes.conf file, located at $APP_HOME/default/indexes.conf:

[splunk_developers_guide]
coldPath = $SPLUNK_DB\splunk_developers_guide\colddb
homePath = $SPLUNK_DB\splunk_developers_guide\db
thawedPath = $SPLUNK_DB\splunk_developers_guide\thaweddb

That's it! Defining indexes is a quick way of optimizing your App's data. You can also create indexes using the GUI. To make sure...

Available Splunk knowledge objects

There are many different Splunk knowledge objects (SKOs) that can be used within an App. The only required SKO for an App is the addition of views that can be displayed to the end user. We will briefly cover the different types of SKOs that you can include within your App. To avoid any issues with author interpretation of the definitions of these SKOs, we will use the definitions and references from the official Splunk documentation.

Macros

noun

A parameterized portion of a search such as an eval statement or a search term that can be reused in multiple places, including saved and ad hoc searches, and which is used in a manner similar to a search command. Search macros can contain arguments, but they are not required.

Note

This is taken from http://docs.splunk.com/Splexicon:Searchmacro.

Macros are configured through the Advanced Configuration section of the GUI, or via the macros.conf file located within the App. They are advantageous by allowing bits of SPL...

Object permissions

Object permissions are an integral part of securing Apps and their knowledge objects. After all, we don't want the user causing issues in an App you spent hours tweaking, do we? No, that's what I thought. This is where permissions come into play. Splunk permissions are role-based, meaning that a user needs a specific role (either assigned by Splunk or via external authentication and authorization systems) to read or write the knowledge object. Permissions are controlled within the default.meta and local.meta files in your metadata folder in the App, and, as per normal Splunk precedence, the local.meta file will override any setting with a matching stanza in the default.meta file.

The configuration structure within the corresponding file is as follows:

[<object_type>/<object_name>]
access = read : [ <comma-separated list of roles>], write : [ comma-separated list of roles>]

Note

This structure is taken from http://docs.splunk.com/Documentation/Splunk/latest...

Summary

In this chapter, we looked at a few different methods of creating Splunk Apps. There are two basic methods of creating Apps: via the Web and via the CLI. We looked at the structure of the App and what each folder may contain. We also covered what kinds of objects (in a non-exhaustive list) can be included in a Splunk App. We discussed permissions, and how to assign them in two different ways. We then went over how to set up a REST endpoint to control configuration, as well as a setup screen to allow the user to update credentials within the App.

Up next, we will discuss the different aspects of enhancing your App with event types, workflows, and some acceleration techniques.