Skip to main content

I have a certain logsource that has multiple different line formats, Instead of making multiple full match log lines, I tried to do the following:

 

grok {
match => {
"Message" => [
"Action Group:%{DATA:action_group}\\\\r",
"Authorization result:%{DATA:authorization_result}\\\\r",
]
}
on_error => "_grok_message_failed"
break_on_match => false
keep_empty_capturesedit => true
}

 

When running this in my grokdebugger, it shows both action_group and authorization_result as the vorrect values, but with a statedump in chronicle, it only shows action_group. Is break_on_match not working in chronicle?

I tested this to confirm, and you are correct. The grok filter in the parser syntax does not support the break_on_match flag. 


It is worth looking at the documentation for the Chronicle SIEM parser syntax here. As it states in that doc, The parser syntax is similar to Logstash, but not identical. The general assumption should be, if it is not listed in that doc then it will not work. 

Hi @Dimarsky, any chance this will make it to a next release? I can work around it by doing this:

grok {
match => {"Message" => ["Action Group:%{DATA:action_group}\\\\r"]}
on_error => "_grok_message_failed"
}
grok {
match => {"Message" => "Authorization result:%{DATA:authorization_result}\\\\r"}
on_error => "_grok_message_failed"
}

But I think form a readability perspective a break_on_match flag would make sense.

Hi @Dimarsky, any chance this will make it to a next release? I can work around it by doing this:

grok {
match => {"Message" => ["Action Group:%{DATA:action_group}\\\\r"]}
on_error => "_grok_message_failed"
}
grok {
match => {"Message" => "Authorization result:%{DATA:authorization_result}\\\\r"}
on_error => "_grok_message_failed"
}

But I think form a readability perspective a break_on_match flag would make sense.


I don't see any feature requests for break_on_match functionality getting added. I would suggested submitting a support ticket asking for this functionality along with an explanation of how it will help readability and brevity of custom parsers as well as parser extensions. 


With respect to your work around, yes that will work, but two things I'd comment on. 



  1. I am fairly sure we use the lower case message for incoming logs in our parsers rather than the capitalized version 

  2. You would probably want to customize the on error strings to better handle which of the groks has failed. 

That is correct, I am parsing a different message than the incoming one 🙂 I am parsing the json that is in message, but that one contains a field called "Message" . I have already started renaming my error flags after trying to find out why it was showing _grok_message_failed: false whilst I was very sure it was failing.

Reply


Terms & ConditionsCookie settings
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.