Developing Dashboards, Views, and Apps for Splunk Web

 


Add & Override Properties

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

Add & Override Properties

These parameters add or reconfigure processing properties inside the Splunk Server. Properties are exposed by C++ code within individual processors.


Filename

Format

[<spec>]
attribute1 = val1
attribute2 = val2
...

Spec

<sourcetype> : the sourcetype of an event


host::<host> : where <host> is the host for an event


reportinghost::<host> : where <host> is the reporting host for an event


source::<source> : where <source> is the source for an event


Attributes

If the same <spec> is found in two bundle directories, the following precedence rules apply.


Overriding is performed attribute by attribute.


Linemerging

SHOULD_LINEMERGE = <bool> (True) : When set to true splunk can combine several input lines into a single event, based on the following configuration attributes.


These are used only when SHOULD_LINEMERGE = True


AUTO_LINEMERGE = <bool> (True) : Directs splunk to use automatic learning methods to determine where to break a stream of lines into events.


MAX_EVENTS = <integer> (256) : Specifies the maximum number of input lines that will be added to any event. Splunk will break after the specified number of lines are read.


The following two conditions are checked in the order below. If the first matches, the second is not tested.


MUST_BREAK_AFTER = <regular expression> (Empty) : When set, and the regular expression matches the current line, splunk is guaranteed to create a new event for the next input line. Splunk may still break before the current line if another rule matches.


MUST_NOT_BREAK_AFTER = <regular expression> (Empty) : When set and the current line matches the regular expression, splunk will not break on any subsequent lines until the MUST_BREAK_AFTER expression matches.


The following four conditions are checked in the order below. If one matches, then the remainder are not tested.


BREAK_ONLY_BEFORE = <regular expression> (Empty) : When set, splunk will create a new event if and only if it encounters a new line that matches the regular expression.


BREAK_ONLY_BEFORE_DATE = <bool> False : When set, splunk will create a new event if and only if it encounters a new line with a date.


BREAK_BEFORE_DATE = <bool> (True) : When set to true, splunk will create a new event when it encounters a new line with a timestamp. It will also emit an event containing all lines since the last new event was created. Note that splunk will still create a new event unless there is a rule that says not to break or the automatic learning method determines that splunk should not break.


MUST_BREAK_BEFORE = <regular expression> (^\s*$) : Note Deprecated. When set, splunk will create a new event when it encounters a new line that matches the regular expression. This is similar to BREAK_BEFORE_DATE.


Timestamp extraction configuration

DATETIME_CONFIG = <filename relative to SPLUNK_HOME> (/etc/datetime.xml) : Specifies the file to configure the timestamp extractor. This configuration may also be set to "NONE" to prevent the timestamp extractor from running or "CURRENT" to assign the current system time to each event.


MAX_TIMESTAMP_LOOKAHEAD = <integer> (150) : Specifies how far into an event splunk should look for a timestamp.


Typing configuration

TYPING_CONFIG = <filename relative to SPLUNK_HOME> : (/etc/event-types/current/default.xml)


Specifies the file to configure the event typer. This configuration may also be set to "NONE" to prevent the event typer from running.


AUTO_TAG = <bool> (False) : Specifies whether to automatically tag new event types with important keywords from events of that event type.


Regex configuration

REGEXES<class> = <"regex name","regex name",...> : {see regexes.conf.spec}


Regular expressions can be defined in regexes.conf files. Splunk configures classes of regular expressions for each event.


For each class, splunk takes the configuration from the highest precedence configuration block. This means that if a particular class is specified for a source, it will override the same class if it is specified for a sourcetype. Similarly, if a particular class is specified in the local bundle for a sourcetype, it will override that class for the default bundle for that sourcetype.


Class names ("-annotation") must be unique within a Splunk instance, so the new Regex configuration does not override an existing configuration. Always add a class name rather than use "REGEXES" alone to avoid replacing Splunk default behavior.


The following is an example REGEXES class in the default bundle for all sourcetypes:


REGEXES-annotation = filetype,loglevel,os,browser,language,ip,email,url

This configuration uses the "test-pipeline" regex (defined in regexes.conf) for sourcetype "access_log":


[access_log]
REGEXES-test = test-pipeline

Source Type configuration

sourcetype = <string> (Empty) : If set for a [source::...] block, it will cause that source to be assigned the specified sourcetype.


Examples

If host matches nyc* then set Eastern Time Zone. See man tzet for format help.


[host::nyc.*]
TZ = EST-5EDT01:00:00,M4.1.0/02:00:00,M10.5.0/02:00:00

If the sourcetype is apache_error, linemerge source data into multi-line events.


[apache_error]
SHOULD_LINEMERGE = True

If the source matches, turn on auto-tagging. The tags will be based on useful-looking words in events during typing process.


[source::.*datatotag.*]
AUTO_TAG = 1

Use the shipped syslog-regex in regex-props.conf to extract meta events.


[source::.*sysloglikesource.*]
REGEXES = syslog-regex

Use the regex access-ip in overlay-regex-props.conf to extract meta-events.


[source::.*access.*]
REGEXES = access-ip

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!