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.
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)
Confirmed in 1.1.1 this causes a watchdog timeout in grok due to a poor edge case in the regexp engine.
Using atomic groups (?> ... ) seems to resolve this.
I'll need to do more testing tomake sure this atomic group case actually works well
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