Admin Manual

 


Attribute precedence within a single props.conf file

NOTE - Splunk version 4.x reached its End of Life on October 1, 2013. Please see the migration information.

Attribute precedence within a single props.conf file

In addition to understanding how attribute precedence works across files, you also sometimes need to consider attribute priority within a single props.conf file.

Precedence within sets of stanzas affecting the same target

When two or more stanzas specify a behavior that affects the same item, items are evaluated by the stanzas' ASCII order. For example, assume you specify in props.conf the following stanzas:

[source::.../bar/baz]
attr = val1

[source::.../bar/*]
attr = val2

The second stanza's value for attr will be used, because its path is higher in the ASCII order and takes precedence.

Overriding default attribute priority in props.conf

There's a way to override the default ASCII priority in props.conf. Use the priority key to specify a higher or lower priority for a given stanza.

For example, suppose we have a source:

    source::az

and the following patterns:

    [source::...a...]
    sourcetype = a

    [source::...z...]
    sourcetype = z

In this case, the default behavior is that the settings provided by the pattern "source::...a..." take precedence over those provided by "source::...z...". Thus, sourcetype will have the value "a".

To override this default ASCII ordering, use the priority key:

    [source::...a...]
    sourcetype = a
    priority = 5

    [source::...z...]
    sourcetype = z
    priority = 10

Assigning a higher priority to the second stanza causes sourcetype to have the value "z".

There's another attribute precedence issue to consider. By default, stanzas that match a string literally ("literal-matching stanzas") take precedence over regex pattern-matching stanzas. This is due to the default values of their priority keys:

  • 0 is the default for pattern-matching stanzas
  • 100 is the default for literal-matching stanzas

So, literal-matching stanzas will always take precedence over pattern-matching stanzas, unless you change that behavior by explicitly setting their priority keys.

You can use the priority key to resolve collisions between patterns of the same type, such as sourcetype patterns or host patterns. The priority key does not, however, affect precedence across spec types. For example, source patterns take priority over host and sourcetype patterns, regardless of priority key values.

Precedence for events with multiple attribute assignments

The props.conf file sets attributes for processing individual events by host, source, or sourcetype (and sometimes event type). So it's possible for one event to have the same attribute set differently for the default fields: host, source or sourcetype. The precedence order is:

  • source
  • host
  • sourcetype

You might want to override the default props.conf settings. For example, assume you are tailing mylogfile.xml, which by default is labeled sourcetype = xml_file. This configuration will re-index the entire file whenever it changes, even if you manually specify another sourcetype, because the property is set by source. To override this, add the explicit configuration by source:

[source::/var/log/mylogfile.xml]
CHECK_METHOD = endpoint_md5

This documentation applies to the following versions of Splunk: 4.1 , 4.1.1 , 4.1.2 , 4.1.3 , 4.1.4 , 4.1.5 , 4.1.6 , 4.1.7 , 4.1.8 , 4.2 , 4.2.1 , 4.2.2 , 4.2.3 , 4.2.4 , 4.2.5 , 4.3 , 4.3.1 , 4.3.2 , 4.3.3 , 4.3.4 , 4.3.5 , 4.3.6 , 4.3.7 , 5.0 , 5.0.1 , 5.0.2 , 5.0.3 , 5.0.4 , 5.0.5 , 5.0.6 , 5.0.7 , 5.0.8 , 5.0.9 , 6.0 , 6.0.1 , 6.0.2 , 6.0.3 , 6.0.4 , 6.0.5 , 6.0.6 , 6.1 , 6.1.1 , 6.1.2 , 6.1.3 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!