On Fri, 2 Dec 2016, Bob Gregory wrote:
I'm not sure that's true in the general case.
Of the errors I've had with our elk stack, upward of 95% have been caused
by type errors (json field should be an int but is an object); some small
handful have failed because a message was truncated somewhere asking the
line; a smaller number have failed because somebody hand-crafted json and
forgot about a trailing comma or quote.
Overwhelmingly, the data aren't corrupted: they were invalid at source in a
way that would still allow them to be read as plain Unicode strings.
Obviously I accept that given enough data, I'll see more interesting
failure modes that need more thought, but reading from the errorfile and
pushing to a separate error index would work very well in our environment.
I get _really_ nervous about even low probability failure modes in my failure
paths. Murphy likes me too much :-)
doing it your way, you still have the failedlog messages from your failure path
that you will need to monitor, so you have reduced the scope of the problem, but
still have the same basic problem.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
