How to skip grok filter match if one of the grok is matched

[RameshNagargoje]

Hi, I am having 1000 of grok in one filter. I want to skip to check if one of the grok is matched.

Here is my config

if[type] == 'kmsg'
{

grok
{
    match => { logs => ".*Unable to handle kernel paging request at virtual address.*" }
    add_field  => {"tagName"=>"SYS_SW"}
    add_field  => {"module" => "syssw"}
    add_tag => ["SUCCESS"]
}

grok     
{
    match => { logs => ".*fence timeout." }
    add_field  => {"tagName"=>"FENCE_TIMEOUT"}
    add_field  => {"module" => "null"}
    add_tag => ["SUCCESS"]
} 
grok     
{
    match => { logs => ".*Host read timeout." }
    add_field  => {"tagName"=>"HOST_READ_TIMEOUT"}
    add_field  => {"module" => "graph"}
    add_tag => ["SUCCESS"]
} 

}

[Christian_Dahlqvist]

A single grok filter can have a list of patterns to process, so you do not need one grok filter per pattern. By default the filter will stop processing patterns once a match is found. You could therefore rationalise your example to something like this:

grok {
    match => { logs => [".*fence timeout.", ".*Unable to handle kernel paging request at virtual address.*"] }
    add_field  => {"tagName"=>"SYS_SW"
                   "module" => "syssw"}
    add_tag => ["SUCCESS"]
} 

I also see that your patterns are not anchored at the start of the entry. You can gain a lot of performance by doing this, as outlined in this blog post.

If you can have a separate grok or dissect filter to capture any common prefix, e.g. timestamps and severity in one field and the rest in another, you can run anchored patterns against the latter, which most likely will greatly improve performance.

[RameshNagargoje]

thanks for reply @Christian_Dahlqvist input is edited please check.
tag name and module name for every regex is different.

[Christian_Dahlqvist]

In that case you can naturally not condense them as I suggested. Processing that many grok expressions will probably result in a very large config with a large number of conditionals to only process if a match has not already been found. I would expect this to be both CPU intensive and slow unless you can anchor the majority of those patterns and process them first (before any that are not anchored).