Splunk Dashboard - Quality check

[monawwer]

Do we have anything (i.e. Add-on or functionality) to check the code quality of our Splunk dashboards, reports and alerts ?

[gcusello]

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

[PickleRick]

What do you mean by "code quality"? And how would you like to measure that?