Fundamentals Question: Best practice of command structure

[antoniolamonica]

I'm currently going over our alerts, cleaning them up and optimizing them. 

However, I recall there being a "best practice" when it comes to writing SPL.
Obviously, there may be caveats to it, but what is the usual best practice when structuring your SPL commands?

Is this correct or no?

search, index, source, sourcetype
| where, filter, regex
| rex, replace, eval
| stats, chart, timechart
| sort, sortby
| table, fields, transpose
| dedup, head
| eventstats, streamstats
| map, lookup

[richgalloway]

IMO, "correct" SPL is whatever produces the desired results.

Some guidelines:

• filter events as early as possible
• use non-streaming commands as late as possible
• use fields instead of table until the end
• avoid expensive commands like join, transaction, and append
• avoid leading wildcards in the search command

I'm sure others will have more guidelines.

[PickleRick]

There is no single best practice to writing SPL. Every use case is different and in order to write an effective SPL you must:

1) Know what you want to achieve

2) Know what you have

3) Know how to "splunkify" your problem

And in order to write a good and effective SPL it's good to know what each command does and how/where it works (especially considering the type of the command) and what limitations it has.

Writing effective SPL is a bit of an art and it's not unusual that you go back to your search after a year or two and you discover that you simply didn't know a command or two back when you originally wrote your code and it can be rewritten much prettier and more effectively.

There are some general rules which are _usually_ true in typical cases like "filter out as much as you can before doing anything serious with your data", "use as little data as you need", "don't overuse wildcards, especially at the beginning of a search term", and "use distributable streaming commands as early as you can" but as with everything - there can be exceptions to those rules simply because your particular use case might call for them. It's just good to know what are the pros and cons of breaking those rules.