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 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_DBsplunk_developers_guidecolddb homePath = $SPLUNK_DBsplunk_developers_guidedb thawedPath = $SPLUNK_DBsplunk_developers_guide haweddb
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 that you are configuring your index within your App, ensure that you are within the context of your App. To be in context of an App only requires you to navigate to your App in the Web interface. Once there, click on the Settings menu and then on the Indexes manager:
Locate the New button, and click on it to go to the setup page. Once there, you will fill in any required fields (the index name being the only required field) and update any others to match your environment. This is shown in the following screenshot:
Once you've created the index, you can start adding data to it. A full restart of Splunk is not needed for the index to be active.
Source types are important within an App because they allow quicker searching, since they are an indexed field. If the scope of your Splunk App is a certain technology (TA) or customer use case (such as the application management of some custom application) and you have to analyze, provide KPIs, and so on, then source types will be a great focus to work on with your App.
If you are developing your App for a specific technology, then naming source types to match your App is a good idea, as this will help reduce any conflicts with existing source types when your App is installed on an end user's environment. This also allows you to break down the incoming data into specific groupings, contained within your App, and gives a finer level of control to the App developer. In general—this is a guidance, not a requirement—the proper format for naming source types related to a technology is vendor:product:feature:format. For example, let's say the vendor that we are developing for is Cisco. We are using their Access Control Server (ACS) with TACACS logging enabled. The proper source type for this data input would be cisco:acs:tacacs. Source types should always be lowercase in order to keep things consistent.