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 hand-written Apps. 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 your 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 perform some additional...

Point of order

As we continue to progress through this book, we will create an App from the ground up. The App's name will be SDG (from a filesystem perspective) and the App "label" will be "Developer's Guide for Splunk." It will be available in its entirety on Splunk base 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 for 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.

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:

• Identify the use case:

  • We are building this App as a learning experience for the reader. By providing an App at the end of this book, with all the examples from the book contained within the...

Methods of creating applications

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

Tip

Protip

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 all 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 is to log...

Basic structures

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.

The appserver folder

The appserver folder contains configurations and other files that relate to 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.

The bin folder

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.

The default folder

The default folder contains all the "App publishers" configurations and views. When packaging...

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 because 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

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

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 interpretations" 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 searched 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.

It can be found at: 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 very useful for building dashboard...

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 the picture. Splunk permissions are role-based, which means 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. 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

The reference for this structure is http://docs.splunk.com/Documentation...

Summary

In this chapter, we looked at 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.