Hi @monawwer, when you speak of quality, I suppose you're speaking about the optimization of search code to have faster searches. About this there are some best practices that you can find in Splun...
See more...
Hi @monawwer, when you speak of quality, I suppose you're speaking about the optimization of search code to have faster searches. About this there are some best practices that you can find in Splunk documentation , e.g.: https://docs.splunk.com/Documentation/SplunkCloud/latest/Search/Quicktipsforoptimization https://lantern.splunk.com/Splunk_Platform/Product_Tips/Searching_and_Reporting/Optimizing_search https://docs.splunk.com/Documentation/Splunk/9.1.0/Search/Writebettersearches https://docs.splunk.com/Documentation/Splunk/9.1.0/Search/Built-inoptimization https://www.tutorialspoint.com/splunk/splunk_search_optimization.htm https://www.javatpoint.com/splunk-search-optimization https://www.youtube.com/watch?v=aSDZ_znuzvM About code, there aren't specific rules because the code is guided by Splunk itself so you cannot think up strange constructs. in conclusion, as you can read in the community there some best practices to apply e.g.: Time is the most efficient filter in Splunk The most effective thing you can do is to narrow by time Specify one or more index values at the beginning of your search string In this way the search is limited only to the index instead all the indexes The more you tell the search engine, the better chance for good result When applicable, searching for "access denied" is always better than searching for "denied" To make searches more efficient, include as many terms as possible You want to find events with "error" and "sshd" 90% of the events include "error", but only 5% "sshd", include both values in the search Inclusion is generally better than exclusion Searching for "access denied" is faster than NOT "access granted" Apply powerful filtering commands as early in your search as possible Filtering to one thousand events and then ten events is faster than filtering to one million events and then narrowing to ten move earch terms as left as possible, For example, remove duplicates events, then sort Avoid using wildcards at the beginning or middle of a string Wildcards at beginning of strings scan alla events within timeframe Wildcards in middle of string may return inconsisten results So use fail* (not *fail or *fail* or f*il) When possible, use OR instead of wildcards For example, us (user=admin OR user=administrator) instead of user=admin* use join or transaction commands only when there sin't any other solution, use only the fields you need, if possible use Post Process Searches to reduce searches executions in the dashboards, use acceleration methods (e.g. summary indexes, DataModels, etc...) etc... Ciao. Giuseppe