LogStash silently stops sending all events to the output when an input message fails to match a grok pattern


See the attached files for a repro case.

There are three lines printed by generate_lines.sh. The second one does not match the grok pattern specified in logstash_bug.conf. The expected behavior is that every second, all three lines would be printed to STDOUT, and the second one would have the '_grokparsefailure' tag attached.

Instead, only the first event is printed to STDOUT, and LogStash never prints the third line or any others. Nor does it log anything to STDERR.

One bug is that the expected behavior does not match what's happening, but a more serious issue is that events are not processed in isolation. An error in a filter shouldn't prevent an event from being sent to the output, nor should it affect other events from being processed.


Philippe Weber
July 10, 2012, 8:43 AM

grok filter was hanging trying to match the second input due to BASE10NUM.
Now (in upcoming1.1.1) a thread watchdog is in place to help identify and report this issue, I did it in LOGSTASH-519.

As a workaround for your use case it seems sufficient to use POSINT (or maybe NONNEGINT if 0 needs to be catch)

Jordan Sissel
August 21, 2012, 7:31 AM

Confirmed in 1.1.1 this causes a watchdog timeout in grok due to a poor edge case in the regexp engine.

Jordan Sissel
August 21, 2012, 7:34 AM

Using atomic groups (?> ... ) seems to resolve this.

Jordan Sissel
August 21, 2012, 7:35 AM

I'll need to do more testing tomake sure this atomic group case actually works well

Philippe Weber
December 17, 2012, 8:14 AM

Working in current version,
current config gives an expected grokfailure, no more watchdog.
See for possible pattern to catch both the dash or a number


Logstash Developers




Fix versions

Affects versions