2016-12-02 10:31 GMT+01:00 David Lang <da...@lang.hm>: > 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.
FYI: the original intent of the error file was to provide errors in a way that makes it easy to (semi?) automatically handle them via a different procedure (which my re-inject them once the problem has been solved). Rainer _______________________________________________ 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.
