These are the commands that are really getting the answers you’re looking for such as stats, chart, timechart. Use non-streaming, transforming commands until last. Use non-streaming commands as late in the query as possible For example, I combine all eval statements into one, comma-delimited, eval statement.Įval var1=”value1”, var2=”value2”, var3=”value3”Ĥ. Try and keep calculations using commands such as eval, lookups, foreach until after you have a succinct data set that’s been culled by the above steps. Perform calculations on the smallest amount of data Where possible, I’ve made it a habit to use the fields command right after the first pipe of my spl.Ī sample job that I created showed the following improvements when simply limiting the number of fields early within the query:ģ. While this cuts down on the number of events (vertical), there can also be substantial benefits to limiting the number of fields that are retrieved (horizontal).īy utilizing the ‘fields’ streaming command early within your spl, you not only lower the sheer amount of data that is being pulled from the indexers, but also the amount that has to be transferred to the search head, and processed by the search head. Minimize the amount data coming back from the indexersĪnother items that is also mentioned in many articles is the goal to filter your data early in order to help lower the number of events returned. In general, I exclusively make use of the stats command to avoid the use of the following commands: dedup, table, join, append.Ģ. The technique used above can also be used to address the use of the ‘append’ command as well. | stats count(eval(sourcetype=”splunkd”)) as metric_count count(eval(sourcetype=”audittrail”)) as audit_count by host (index=_internal sourcetype=splunkd component=Metrics) OR [search index=_audit sourcetype=audittrail Index=_internal sourcetype=splunkd component=Metrics What’s the solution? The above problems can be mitigated by combining your subsearch with your primary search and accomplishing the ‘join’ with the use of a stats command. This can go unnoticed, pay attention to the error messages that are returned with the use of these commands. This leads to a truncation of results, which leads to incorrect answers. By default, they have a timeout of 60s and a limitation of 50000 events (see subsearch_maxtime and subsearch_maxout in nf). With every use of these commands, the number of times that you need to access the indexers increases (and increases all of the communication and overhead that may be involved). Both commands make use of a subsearch (the stuff between the square brackets).Why is this the case? A few problems include: While the ‘join’ and ‘append’ commands are widely used and familiar to most of us, they are not necessarily the most efficient commands. Namely – avoid subsearches via the use of ‘join’ and ‘append’. Minimize the number of trips to the indexers The following tips are listed in order that they are used within the search. In this article, I’d like to share a few consistent tips that I’ve learned to improve the performance of queries. There are countless blogs, articles, and Splunk ‘answers’ regarding the optimization of Splunk queries (and here’s another one).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |