The answers to questions 2 and 3 are clearly "yes", and between what you
already know about Heka and my reply to the first message in this thread
you should have some ideas re: how to handle monitoring Heka. That
leaves us with question 1: "Should a logline that is too big for your
sandbox stop Heka?"
The only person who really knows the answer to that is you, but my guess
is that the answer is "yes". Sandboxes are, by definition, resource
constrained; if they try to use more than the allowed resources, they
will be shut down. If a decoder is shut down, then the input that uses
that decoder will also shut down, since presumably you don't want to
keep accepting data if you're no longer parsing said data.
In this case, would you want Heka to keep running, even though it's no
longer accepting your input? We default to "no", under the assumption
that it's better for the user to know something has gone wrong than for
Heka to keep running while silently failing.
If Heka is doing other things that are more important, however, you can
add `can_exit = true` to your input's configuration, see
http://hekad.readthedocs.org/en/v0.10.0/config/inputs/index.html#common-input-parameters.
This will tell Heka that it should keep running even if the input has
stopped.
Maybe not the answer you were hoping for, but hopefully it's useful anyway.
-r
On 02/01/2016 02:39 AM, Kai Storbeck wrote:
Interesting. Today I investigated a hekad that didn't want to start up.
I found out it was a large postgresql logline that was larger than the
sandbox' default output_limit. Processing the line ended up doubling
that. An increase to 128k sufficed.
This error raised several questions:
should a logline that is too big for my sandbox stop heka?
should our developers write better postgres queries (yes!), and
should I be monitoring heka to keep running?
_______________________________________________
Heka mailing list
Heka@mozilla.org
https://mail.mozilla.org/listinfo/heka
