Sometime logstash crashes and dies due to faultily written boolean statements. [foo] > 5 works well until we hit an event where [foo] doesn't exist. Usually, the user means to write something like [foo] and [foo] > 5, but not always. Perhaps they need special logic for the nil case. These bugs can be sneaky however, as seen in #1637 .
The pipeline can also die if a filter or output has a bug in it. This is especially common in uses of the ruby filter, which often make the same field being present assumptions.
For some users the right thing to do here is to crash logstash so an operator is forced to diagnose and fix the issue. For others, they generally just want it to log an error and keep on running. Logstash crashing is more an issue for these people.
After going back and forth on who was right WRT these issue @jsvd and converged on thinking that the current (crash by default) behavior is the right for a default, it being the more conservative option.
We should however add a flag enabling the latter behavior for people who just want it to run, and if they miss a few events, not to worry about it. One small concern with the log and drop method is that it could easily fill up Logstash logs on disk, but that problem is to some extent outside of the scope of LS, and more a logrotate thing.
Sometime logstash crashes and dies due to faultily written boolean statements.
[foo] > 5works well until we hit an event where[foo]doesn't exist. Usually, the user means to write something like[foo] and [foo] > 5, but not always. Perhaps they need special logic for thenilcase. These bugs can be sneaky however, as seen in #1637 .The pipeline can also die if a filter or output has a bug in it. This is especially common in uses of the ruby filter, which often make the same field being present assumptions.
For some users the right thing to do here is to crash logstash so an operator is forced to diagnose and fix the issue. For others, they generally just want it to log an error and keep on running. Logstash crashing is more an issue for these people.
After going back and forth on who was right WRT these issue @jsvd and converged on thinking that the current (crash by default) behavior is the right for a default, it being the more conservative option.
We should however add a flag enabling the latter behavior for people who just want it to run, and if they miss a few events, not to worry about it. One small concern with the log and drop method is that it could easily fill up Logstash logs on disk, but that problem is to some extent outside of the scope of LS, and more a logrotate thing.