All Apps and Add-ons

How to write good SPL syntax

New Member

Dear sir,

I'm Taiwanese , my English is poor,
i have a question,
My boss gave me a subject:"How to write good SPL syntax ?"
I'm new , I can't answer his question,
so...Seniors, what do you think is good SPL syntax?
for ex:Clear and smooth?
i think i need answer this question when i see my boss next time ,

pls help me :(:(

0 Karma
1 Solution

Builder

In my humble opinion good SPL syntax can be thought of the following high-level practices:

  • Efficient
    This means you put as much as you can before the first pipe character (this is a pipe character: | )
    Whenever possible, you are using index, source, sourcetype, and host in your SPL queries.
    You are as specific as you can be. Meaning that even if you don't know all the host names (for example), but you know you are looking for web servers, then host=*web* is better than host=*

  • Readable
    When an SPL query is readable, it becomes easier to understand, troubleshoot, and give to a coworker.
    When you format your SPL queries, remember to format them in the editor, by pressing Control + Shift + F. This goes a long ways toward readability.
    There are some additional ways to format your query for readability, that you will see from time to time here in Splunk Answers. For example: When using a case statement, you might see people provide additional white space that the Control + Shift + F command doesn't. This starts to get into more than the basics, but be aware of it and adopt it when it makes sense.
    Example:

    | eval Description=case(
    depth<=70, "Low",
    depth>70 AND depth<=300, "Mid",
    depth>300, "Deep"
    )

The example above is easier to read than the following:

| eval Description=case(depth<=70, "Low", depth>70 AND depth<=300, "Mid",  depth>300, "Deep") 

As your queries get bigger, readability becomes a larger issue.

  • Comment While this goes toward readability, some see it as optional. I'm of the opinion that comments inline with your SPL can be a good thing. Commenting all your code (SPL, CSS, HTML, etc.) can also be useful in your simple XML dashboards too. When you get to a line that took you a long time to figure out, a quick explanation in a comment may help. Good detail and examples are here: https://docs.splunk.com/Documentation/Splunk/latest/Search/Addcommentstosearches

There are a lot of examples out on the web where people have opinions about certain commands or say to learn to do this instead of that, but those all come after the fundamentals I mentioned above.

What I've written is a good start to having good SPL syntax. It's not everything, and you'll learn more as you go. If you pay attention to these things, it will provide a great foundation for future syntax lessons.

###

If this reply helps you, an upvote would be appreciated.

View solution in original post

Builder

In my humble opinion good SPL syntax can be thought of the following high-level practices:

  • Efficient
    This means you put as much as you can before the first pipe character (this is a pipe character: | )
    Whenever possible, you are using index, source, sourcetype, and host in your SPL queries.
    You are as specific as you can be. Meaning that even if you don't know all the host names (for example), but you know you are looking for web servers, then host=*web* is better than host=*

  • Readable
    When an SPL query is readable, it becomes easier to understand, troubleshoot, and give to a coworker.
    When you format your SPL queries, remember to format them in the editor, by pressing Control + Shift + F. This goes a long ways toward readability.
    There are some additional ways to format your query for readability, that you will see from time to time here in Splunk Answers. For example: When using a case statement, you might see people provide additional white space that the Control + Shift + F command doesn't. This starts to get into more than the basics, but be aware of it and adopt it when it makes sense.
    Example:

    | eval Description=case(
    depth<=70, "Low",
    depth>70 AND depth<=300, "Mid",
    depth>300, "Deep"
    )

The example above is easier to read than the following:

| eval Description=case(depth<=70, "Low", depth>70 AND depth<=300, "Mid",  depth>300, "Deep") 

As your queries get bigger, readability becomes a larger issue.

  • Comment While this goes toward readability, some see it as optional. I'm of the opinion that comments inline with your SPL can be a good thing. Commenting all your code (SPL, CSS, HTML, etc.) can also be useful in your simple XML dashboards too. When you get to a line that took you a long time to figure out, a quick explanation in a comment may help. Good detail and examples are here: https://docs.splunk.com/Documentation/Splunk/latest/Search/Addcommentstosearches

There are a lot of examples out on the web where people have opinions about certain commands or say to learn to do this instead of that, but those all come after the fundamentals I mentioned above.

What I've written is a good start to having good SPL syntax. It's not everything, and you'll learn more as you go. If you pay attention to these things, it will provide a great foundation for future syntax lessons.

###

If this reply helps you, an upvote would be appreciated.

View solution in original post

Ultra Champion

I think good SPL is small search range.
e.g. * is bad thing.
OR, AND should be used.
@hank11344677937 How about this?

0 Karma

Ultra Champion

thanks, @hank11344677937
I want to know what the boss reply. please.

0 Karma

New Member

i have a meeting with him at next monday ,
i'll update , thanks a lot

0 Karma