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
[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 in
[host::*] FIELDALIAS-sshd = sshd1_code AS global_sshd1_code
The second configuration is in
[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 in the reverse lexicographical order. To avoid this, you might change the name of the first field alias configuration to
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.
The sequence of search-time operations
Develop naming conventions for knowledge objects
This documentation applies to the following versions of Splunk® Enterprise: 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.0.15, 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.1.14, 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, 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12