Give knowledge objects of the same type unique names

When you create knowledge objects that are processed at search time, it is best if all knowledge objects of a single type have unique names. This helps you avoid name collision issues that can prevent your configurations from being applied at search time.

For example, to avoid name collision problems, you should not have two inline field extraction configurations that have the same <class> value in your Splunk implementation. However, you can have an inline field extraction, a transform field extraction, and a lookup that share the same name, because they belong to different knowledge object types.

You can avoid these problems with knowledge object naming conventions. See Develop naming conventions for knowledge objects.

Configurations sharing a host, source, or source type

When two or more configurations of a particular knowledge object type share the same props.conf stanza, they share the host, source, or source type identified for the stanza. If each of these configurations has the same name, then the last configuration listed in the stanza overrides the others.

For example, say you have two lookup configurations named LOOKUP-table in a props.conf stanza that is associated with the sendmail source type:

[sendmail]
LOOKUP-table = logs_per_day host OUTPUTNEW average_logs AS logs_per_day
LOOKUP-table = location host OUTPUTNEW building AS location

In this case, the last LOOKUP-table configuration in that stanza overrides the one that precedes it. The Splunk software adds the location field to your matching events, but does not add the logs_per_day field to any of them.

When you name your lookup LOOKUP-table, you are saying this is the lookup that achieves some purpose or action described by "table." In this example, these lookups achieve different goals. One lookup determines something about logs per day, and the other lookup has something to do with location. Rename them.

[sendemail]
LOOKUP-table = logs_per_day host OUTPUTNEW average_logs AS logs_per_day
LOOKUP-location = location host OUTPUTNEW building AS location

Now you have two different configurations that do not collide.

Configurations belonging to different hosts, sources or source types

You can also run into name collision issues when the configurations involved do not share a specific host, source, or source type.

For example, if you have lookups with different hosts, sources, or source types that share the same name, you can end up with a situation where only one of them seems to work at any given time. If you know what you are doing you might set this up on purpose, but in most cases it is inconvenient.

Here are two lookup configurations named LOOKUP-splk_host. They are in separate props.conf stanzas.

[host::machine_name]
LOOKUP-splk_host = splk_global_lookup search_name OUTPUTNEW global_code

[sendmail]
LOOKUP-splk_host = splk_searcher_lookup search_name OUTPUTNEW search_code

Any events that overlap between these two lookups are only affected by one of them.

• Events that match the host get the host lookup.
• Events that match the source type get the source type lookup.
• Events that match both get the host lookup.

For more information about this, see Configuration file precedence in the Admin Manual

Configurations belonging to different apps

When you have configurations that belong to the same knowledge object type and share the same name, but belong to different apps, you can also run into naming collisions. In this case, the configurations are applied in reverse lexicographical order of the app directories.

For example, say you have two field alias configurations.

The first configuration is inetc/apps/splk_global_lookup_host/local/props.conf:

[host::*]
FIELDALIAS-sshd = sshd1_code AS global_sshd1_code

The second configuration is in etc/apps/splk_searcher_lookup_host/local/props.conf:

[host::*]
FIELDALIAS-sshd = sshd1_code AS search_sshd1_code

In this case, the search_sshd1_code alias would be applied to events that match both configurations, because the app directory splk_searcher_lookup_host comes up first in the reverse lexicographical order. To avoid this, you might change the name of the first field alias configuration to FIELDALIAS-global_sshd.

Lexicographical order

Lexicographical order sorts items based on the values used to encode the items in computer memory. In Splunk software, this is almost always UTF-8 encoding, which is a superset of ASCII.

• Numbers are sorted before letters. Numbers are sorted based on the first digit. For example, the numbers 10, 9, 70, 100 are sorted lexicographically as 10, 100, 70, 9.
• Uppercase letters are sorted before lowercase letters.
• Symbols are not standard. Some symbols are sorted before numeric values. Other symbols are sorted before or after letters.