Admin Manual

 


How Splunk Works

Sharing add-ons on SplunkBase

This documentation does not apply to the most recent version of Splunk. Click here for the latest version.

Sharing add-ons on SplunkBase

You can share your add-ons with others through the SplunkBase Add-on page.


An add-on is something to extend or enhance Splunk. Some examples of things you can add or download include (but are not limited to):


Creating Add-ons

An add-on can contain any code or configuration that enhances or extends Splunk, or integrates Splunk with another application. It can contain almost anything you can think of. However, a lot of add-ons package up contents of .conf files within a Splunk server's $SPLUNKHOME/etc/bundles directory and are intended to just be unpacked into this directory by someone else downloading your add-on.


For example, an add-on for Apache might consist of the directory $SPLUNKHOME/etc/bundles/Apache and all the configuration files within the Apache directory.


However, if your add-on contains configuration meant to drop into another application to make it work with Splunk, you're going to have files that will need to get moved somewhere else outside of $SPLUNKHOME/etc/bundles. For example, if you have an extension to a 3rd party monitoring application that puts a "Search Splunk" item into contextual menus, that's going to need to get moved out of Splunk into the 3rd party application.


Naming Your Add-on

Add-on naming is fairly important. If twenty people all create add-ons of various types for Apache and all name them Apache, inexperienced users dropping each of these Apache add-ons on top of each other in $SPLUNKHOME/etc/bundles will successively wipe files out.


Try to make your add-ons names as distinct as possible. Use underscores (_) instead of spaces. So, your Apache add-on that creates referrer reports could be named Apache_referrer_reports. Feel free to use your name or screen name as part of the add-on. This will make it much easier to look through the $SPLUNKHOME/etc/bundles directory and see which one does which. Do the same with items that you name inside your add-on, such as event types.


addon.conf (Required)

The only file that you absolutely must have in your add-on directory is addon.conf. This is the file in which you will define information about your add-on.


It begins with a line that consists only of the add-on name, in square brackets, like this:


[name]

This name entry must match the name of your add-on (eg the name of the directory containing the files).


Following are the stanzas defined below.


Stanza Type Required? Description
author String Yes The author of this add-on.
version String Yes The version number of this add-on.
minsplunkversion Version Yes The oldest version of Splunk the user must have installed in order to utilize this add-on. Wildcards can be used in order to denote All in one portion of the versioning.
maxsplunkversion version No The newest version of Splunk the user can have installed in order to utilize this add-on. Wildcards can be used in order to denote all in one portion of the versioning, or for all versions of Splunk.
contactemail String No The email address of the add-on's creator.
website String No The bundle creator's Web site, or the page specifically for this add-on.
description String No Short description of this add-on, less than 512 characters long. May be displayed in the UI.

Example addon.conf:


[imap]
author = John Doe
version = 1.0
minsplunkversion = 3.*
contactemail = support@splunk.com
website = http://splunk.com/
description = Polls IMAP accounts, indexing messages

Other things you can upload include:


Best practices for making add-ons containing Splunk configuration

If you're making an add-on that consists entirely of Splunk configuration files and scripts referenced by those files, the best approach is to start by setting up your configuration just as you would do if you were just working on configuring your own server. In many cases you may already have done this configuration and may just be reading this to figure out how to share what you've already done.


If you need to learn how to do something within an add-on, just read the appropriate admin manual topic. Creating event types to share as an add-on is no different than creating them for yourself until you get to the point of copying them out of your local installation.


Edits you've done via the Splunk CLI and Splunk Web will have been put into the .conf files in $SPLUNK_HOME/etc/bundles/local directory. Edits you made directly to .conf files will be in whatever subdirectory of $SPLUNK_HOME/etc/bundles you made them in, of course. Copy the stanzas you want to package up for your SplunkBase contribution over into a fresh configuration file in a separate directory that will become your add-on.


Submit your add-on

To submit a add-on from the Add-on page:


  1. Make your bundle directory into a tarball or zip file. Please note: use relative file paths rather than absolute when creating your tarballs or zip files, or people will have difficulty installing your add-on.
  1. Click the Upload an Add-on button, which takes you to the Submit an Add-on page.
  1. (There are hints and complete direction on the Add-on page).
  1. Enter the name of your bundle in the Add-on Name text box.
  1. Enter a description of what it does in the Description text box.
  1. Select the Types that apply to your add-on (e.g. Inputs and Custom Processing).
  1. Select a category or create a new one if the existing categories are not sufficient. An accurate category helps others to find your add-on. (e.g. Mail -> Mail Protocols -> POP3).
  1. Browse to the bundle file location from the Create New Add-on Upload page.
  1. Click upload.
  1. You will be provided with a link to use to edit or further describe the add-on.

This documentation applies to the following versions of Splunk: 3.0 , 3.0.1 , 3.0.2 , 3.1 , 3.1.1 , 3.1.2 , 3.1.3 , 3.1.4 View the Article History for its revisions.


You must be logged into splunk.com in order to post comments. Log in now.

Was this documentation topic helpful?

If you'd like to hear back from us, please provide your email address:

We'd love to hear what you think about this topic or the documentation as a whole. Feedback you enter here will be delivered to the documentation team.

Feedback submitted, thanks!