Naming convention best practices for a Splunk deployment
A naming convention is a system of using standard terms to classify categories of data so you can organize data in a way that makes sense to you.
Lexicographical order is alpha-numeric name sorting. Splunk uses lexicographical order to determine priority when processing knowledge object configurations. Many users new to Splunk are unaware of this, and incorrectly attribute faulty lexicographical ordering to buggy behavior. Once you understand how Splunk lexicographical order works, you can use it to your advantage to enhance performance.
When you design a naming convention for your apps and indexes, consider lexicographical order to optimize search efficiency and accuracy.
- Search expert
- Knowledge manager
For more about these roles, see Roles best practices.
How lexicographical order works
The Splunk configuration (.conf) files define the logic that controls what Splunk does and in what order. Splunk determines configuration priorities based on factors such as the current user and current app (scope) and alpha-numeric name sorting (lexicographical naming). This enables you to blend configurations from different files of the same configuration type, tune your data's source type, and increase the performance of indexing and searching.
Lexicographical order is as easy as "1, 10, 3" and "A, B, c". Splunk prioritizes numbers first, then capital letters, then lowercase letters:
Guidelines for leveraging lexicographical order in naming conventions
Keep these guidelines in mind when applying lexicographical order to a naming convention for your knowledge objects.
Before working with configuration files, see these topics in the Admin Manual to get familiar with the nuances of configuration file structure, configuration file directories, configuration file precedence, and when to restart Splunk Enterprise after a configuration file change for a direct
.conf edit to apply.
To help keep it all straight, Splunk provides btool, a command-line utility, to troubleshoot issues with
.conf file interactions and precedence. See Use btool to troubleshoot configurations in the Troubleshooting Manual.
Apply lexicographical order to internal app naming
One of the best ways to use lexicographical order is in your internal app's naming conventions. For example, a naming convention such as
<companyname>_<purpose>_<(app|add-on)> enables you to easily differentiate your apps and configs from those downloaded from Splunkbase.
Lexicographical order effects the order in which apps are loaded, so you can control priority order with your naming convention. For example, if you want one group of objects to be evaluated before another, make sure the naming convention you apply sorts first according to the lexicographical hierarchy shown above.
Set up a global app to establish default behavior
You can use lexicographical order to set up a global app that will load before other apps. This enables you to set a general default behavior. The global app can contain basic settings. Apps that load after the global app can override (or fine tune) these settings as necessary.
For example, say you work for a company called 'Acme' and you created a global app named
Acme_zglobal_ta. In that app, you have included global configurations, such as non-default port assignments and disabling the Splunk web server. On your search heads, you have deployed
Acme_searchhead_ta, which enables the web server.
Acme_zglobal_ta loads first, which establishes that no Splunk instances will run the web server.
Acme_searchhead_ta loads second and overrides that default behavior just for your search heads.
So the web server will run only on your search heads.
Use unique names
You might run into issues if multiple knowledge objects of the same type share the same name, even if they belong to different apps. Objects get applied in reverse lexicographical order of the app directories. To understand more about how this works, see Give knowledge objects of the same type unique names in the Knowledge Manager Manual.
To avoid these issues, give each knowledge object a unique name.
Keep naming conventions for knowledge objects simple
Keep it simple if you apply a naming convention to knowledge objects. Use a system others can easily understand and apply. A complex syntax is harder for other users to understand, and could discourage them from using it.
Naming conventions for indexes
Another best practice is to apply a naming convention to event indexes you create to manage user access, varying retention policies, or repositories for specific types of data or data from specific sources. A good naming convention contains descriptors to help identify the index, categories to classify the index, and a summary. This enables you to use wildcards in configuration files, such as
authorization.conf, to manage access. Create a naming convention that is simple so it's more likely to stay accurate over time. For example,
- Include your company name to help differentiate indexes you create from indexes provided by Splunk or other solutions. For example,
- The purpose descriptor indicates what the index was created to do. It should be generic enough to apply to any data source whose data is routed to that index. For example,
firewall. Keep names generic. Specific values, like product names, team names, organizations, people, and so on, are subject to change. For example, use
firewallinstead of a specific brand of firewall, such as
- Sensitivity is a category that indicates the degree to which data in that index should be protected or restricted to certain user groups, for example,
nonprod. This enables you to leverage wildcards when assigning permissions to certain indexes to users in certain roles.
- If you have created a summary index to skim a large data set for a smaller subset of data to search, you can create an identifier for it in your naming scheme. See Use summary indexing for increased reporting efficiency in the Knowledge Manager Manual for more about summary indexing.
Using the example above, you might create the following naming scheme for indexes that serve different types of data:
- acme_web_pci: an index for the Acme web server for information that is subject to PCI regulations
- acme_firewall_prod: an index for the Acme firewalls in production
- acme_av_nonprod: an index for the non-production anti-virus server at Acme
- acme_all_prod_summary: a summary index of correlations produced from all of Acme's production indexes
The next example uses wildcards In the
authorization.conf file to demonstrate how you can use your naming convention to manage access to specific indexes for specific user roles using the following options in the
srchIndexesAllowed attribute, where * is the name of any index that matches the naming criteria.
- Acme_*: For user roles that are allowed to access all data in all Acme indexes
- Acme_*_nonprod: For user roles that should never have access to production data
- Acme_*_pci: For user roles permitted to view PCI data
Naming conventions for source types
Source types do well by following the naming conventions outlined in Source types for add-ons in the Splunk Add-ons Manual.
Try out the examples above using configurations and apps in your sandbox. Make up some scenarios of your own. Use
btool with the
--debug flag to explore how they be loaded.
Logging best practices for a Splunk deployment
Newsletter best practices for a Splunk deployment
This documentation applies to the following versions of Splunk® Success Framework: ssf