Documentation > Splunk > Developing Dashboards, Views, and Apps for Splunk Web > How Modules Work

Developing Dashboards, Views, and Apps for Splunk Web

 


Start Here
Command Line Interface
SOAP API
Bundles
Modules
Skins
Workflow Integration
Search Language
Built-In Processors

How Modules Work

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

Contents

How Modules Work

Modules add new pipelines and processors to splunkd. A module is a small directory of files that contains a configuration file, config.xml . It may contain other files, usually a processor executable. As with bundles, the intent of modules is to have discrete units that can be moved in or out as needed, to simplify customization and configuration.


Modules must be placed into a Splunk installation as subdirectories of the $SPLUNK_HOME/etc/modules/ directory.


Startup

When splunkd starts, it walks the modules directory (in chronological order, from oldest to newest) and reads the config.xml file in each subdirectory. If the file contains a valid pipeline configuration, splunkd launches the pipeline. Modules can share processors and other runnable code - a pipeline defined in one subdirectory can include a processor that lives in another module.


The default Splunk Server filesystem contains these subdirectories under $SPLUNK_HOME/etc/modules:


distributedSearch : pipeline for distributed search, maintained through the GUI or CLI


input : for accessing data outside Splunk and reading it into the Splunk Server


internal : internal Splunk functions (as opposed to add-on input methods or other functionality)


output : for sending data out by various methods


Pipelines will be loaded from any subdirectory of $SPLUNK_HOME/etc/modules. You should choose meaningful locations for your modules for easier maintenance. For example, you could put new input type modules under input, or create a new directory in etc/modules for all your custom modules.


There's only one required, canonical filename within each module subdirectory.


config.xml : defines a new pipeline or modifies Splunk's universal pipeline.


Your custom module can change the configuration of processors in the universal pipeline, such as inserting new processors ahead of, behind, or in place of those defined in the universal pipeline. You can also replace the universal pipeline with your own custom processing order, using a combination of built-in Splunk processors and your own.


Typical Uses

These are just a few of the possible uses for modules.


Custom input modules : For example, to read from a proprietary database source.


Extended processing : To look up data in a local database, or perform transformations that can't be done through properties.


Universal pipeline customization : To modify the default pipeline through which all data is routed, or to create a slightly modified version of the pipeline with a different configuration of its processors.
Retrieved from "http://docs.splunk.com/Documentation/Splunk/2.2.6/Developer/HowModulesWork"

This documentation applies to the following versions of Splunk: 2.1 , 2.2 , 2.2.1 , 2.2.3 , 2.2.6 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!