Get data from APIs and other remote data interfaces through scripted inputs
Splunk Enterprise can accept events from scripts that you provide. Scripted input is useful in conjunction with some Windows and *nix command-line tools, such as
top, and so on. You can use scripted input to get data from application program interfaces (APIs) and other remote data interfaces and message queues. You can then use commands like
iostat on that data to generate metrics and status data.
Note: This topic describes how to add scripted inputs that you've already written to your set of inputs. To learn how to develop scripted inputs, see Build scripted inputs in the Developing Views and Apps for Splunk Web manual.
You can configure scripted inputs from the Settings menu or by editing inputs.conf.
Note: On Windows platforms, you can enable text-based scripts, such those in perl and python, with an intermediary Windows batch (
.bat) or PowerShell (
Caution: Scripts launched through scripted input inherit the Splunk Enterprise environment. Be sure to clear environment variables that can affect your script's operation. The only environment variable that's likely to cause problems is the library path (most commonly known as
LD_LIBRARY_PATH on Linux, Solaris, and FreeBSD).
Splunk Enterprise logs any messages sent to the
stderr I/O channel by scripted inputs to
Add a scripted input in Splunk Web
To add a scripted input in Splunk Web, follow the "Scripts" recipe in this manual.
Add a scripted input via inputs.conf
You add a scripted input in
inputs.conf by adding a
Here is the syntax for the
[script://$SCRIPT] <attrbute1> = <val1> <attrbute2> = <val2> ...
Note the following:
$SCRIPTis the fully-qualified path to the location of the script.
- As a best practice, put your script in the
bin/directory nearest the
inputs.confwhere your script is specified. For example, if you are configuring
$SPLUNK_HOME/etc/system/local/inputs.conf, place your script in
$SPLUNK_HOME/etc/system/bin/. If you're working on an application in
$SPLUNK_HOME/etc/apps/$APPLICATION/, put your script in
All attributes are optional. Here is the list of available attributes:
|| * Indicates how often to execute the specified command. Specify either an integer value representing seconds or a valid cron schedule.
|| * Sets the index where events from this input will be stored.
|| * Sets the sourcetype key/field for events from this input.
||Splunk Enterprise picks a source type based on various aspects of the data. There is no hard-coded default.|
|| * Sets the source key/field for events from this input.
||The input file path|
If you want the script to run continuously, write the script to never exit and set it on a short interval. This helps to ensure that if there is a problem the script gets restarted. Splunk Enterprise keeps track of scripts it has spawned and will shut them down upon exit.
Using a wrapper script
It is good practice to write a wrapper script for scripted inputs that use commands with arguments. In some cases, the command can contain special characters that Splunk Enterprise escapes when validating text entered in Splunk Web. This causes updates to a previously configured input to fail to save.
- Note: Characters that Splunk Enterprise escapes when validating text are those that should not be in paths, such as equals (
=) and semi-colon (
For example, the following scripted input is not correctly saved when edited in Splunk Web because Splunk Enterprise escapes the equals (=) sign in the parameter to the
[script://$SPLUNK_HOME/etc/apps/myApp/bin/myUtil.py file=my_datacsv] disabled = false
To avoid this problem, write a wrapper script that contains the scripted input. (Inputs updated by editing the conf file directly are not subject to this input validation.) For information on writing wrapper scripts, see Scripted inputs overview in the Developing Views and Apps for Splunk Web manual.
Example using inputs.conf
This example shows the use of the UNIX
top command as a data input source:
1. Create a new application directory. This example uses
$ mkdir $SPLUNK_HOME/etc/apps/scripts
2. All scripts should be run out of a
bin/ directory inside your application directory:
$ mkdir $SPLUNK_HOME/etc/apps/scripts/bin
3. This example uses a small shell script
$ #!/bin/sh top -bn 1 # linux only - different OSes have different parameters
4. Make sure the script is executable:
chmod +x $SPLUNK_HOME/etc/apps/scripts/bin/top.sh
5. Test that the script works by running it via the shell:
The script should send one
6. Add the script entry to
[script:///opt/splunk/etc/apps/scripts/bin/top.sh] interval = 5 # run every 5 seconds sourcetype = top # set sourcetype to top source = script://./bin/top.sh # set source to name of script
Note: You might need to modify props.conf:
- By default Splunk Enterprise breaks the single
topentry into multiple events.
- The easiest way to fix this problem is to tell the server to break only before something that does not exist in the output.
For example, adding the following to
$SPLUNK_HOME/etc/apps/scripts/default/props.conf forces all lines into a single event:
[top] BREAK_ONLY_BEFORE = <stuff>
Since there is no timestamp in the top output we need to tell Splunk Enterprise to use the current time. This is done in
props.conf by setting:
DATETIME_CONFIG = CURRENT
Set interval attribute to cron schedule
In the above example, you can also set the
interval attribute to a "cron" schedule by specifying strings like the following:
0 * * * *: Means run once an hour, at the top of the hour.
*/15 9-17 * * 1-5: Means run every 15 minutes from 9 am until 5 pm, on Monday to Friday.
15,35,55 0-6,20-23 1 */2 *: Means run at 15, 35, and 55 minutes after the hour, between midnight and 7 am and again between 8pm and midnight, on the first of every even month (February, April, June and so on).
For more information about setting cron schedules, read "CRONTAB(5) on the Crontab website.
Monitor changes to your file system
Find more things to monitor with crawl
This documentation applies to the following versions of Splunk® Enterprise: 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.2.15