How to handle inconsistent Logstash grok filters

I am wondering what works best for my Logstash Grok filters. I have some filters that are for specific journal entries, and will not apply to all entries. Those that are not applicable always generate _grokparsefailure tags. For example, I have one grok filter that works fine for each log entry. Then I have another filter, which is for tracking error messages. The trace filter returns a grokparsefailure for each journal entry that does not have a trace.

I would prefer it to simply pass the rule if there is no match instead of adding the parsefailure tag. I use the parsefailure tag to find things that don't parse correctly, and not things that just don't match a specific filter. Maybe this is just the nomenclature of "failure to parse" that bothers me. For me, this means that something is wrong with the filter (for example, poorly formatted), and not that it does not match.

So the question is, how should I handle this?

  • Make the filter pattern optional using?

  • (ab) use the tag_on_failure parameter, setting it to nothing []

  • make the filter conditional using something like "if traceback in message"

  • something else I do not consider?

Thanks in advance.

EDIT

I took the way to add conditions around the filter:

if [message] =~ /took\s\d+/ { grok { patterns_dir => "/etc/logstash/patterns" match => ["message", "took\s+(?<servicetime>[\d\.]+)"] add_tag => [ "stats", "servicetime" ] } } 

However, he is interested in feedback. What is considered "best practice" here?

+44
filter logstash logstash-grok
Dec 30 '14 at 23:57
source share
4 answers

When possible, I would include a conditional shell like the one you are using. Feel free to post this as an answer!

If your application creates only a few different line formats, you can use several matching patterns with grok filter . By default, the filter will process until the first successful match:

 grok { patterns_dir => "./patterns" match => [ "message", "%{BASE_PATTERN} %{EXTRA_PATTERN}", "message", "%{BASE_PATTERN}", "message", "%{SOME_OTHER_PATTERN}" ] } 

If your logic is less simple (maybe you need to check the same condition more than once), grep filter can be useful for adding a tag. Something like that:

 grep { drop => false #grep normally drops non-matching events match => ["message", "/took\s\d+/"] add_tag => "has_traceback" } ... if "has_traceback" in [tags] { ... } 
+33
Jan 02 '14 at
source share

You can also add tag_on_failure => [] to your stanza, for example:

 grok { match => ["context", "\"tags\":\[%{DATA:apptags}\]"] tag_on_failure => [ ] } 

grok will still fail, but will do so without adding an array of tags.

+17
Aug 25 '14 at 18:01
source share

You can also do it

remove_tag => ["_grokparsefailure"]

whenever you have a match.

+4
Apr 23 '14 at 23:05
source share

This is the most effective way to do this. Ignore filter

 filter { grok { match => [ "message", "something"] } if "_grokparsefailure" in [tags] { drop { } } } 
+2
Apr 18 '17 at 22:23
source share



All Articles