On 2020-03-11T07:39:45, Pallissard, Matthew wrote:
On 2020-03-06T17:02:14, Howard Chu wrote:
> Howard Chu wrote:
> > Just some initial thoughts on what a new logging daemon should do for us:
> > The primary goal - we want to use a binary message format with as few format
conversions as possible between log
> > sender and log processor.
> One other concern - what do we do about debug output to stderr? If we keep that,
> then we still have message formatting overhead inside slapd itself, and we're
> potentially managing two redundant sets of message formats.
And now that I'm thinking it through a little bit, you wouldn't necessarily have
to maintain two sets of message formats.
A grossly over simplified idea would be to implement a log parsing library, link slapd and
the log processor to it. If stdout/stderr debugging is enabled skip all of the stuff that
happens in between the log server and reading the log file, parse and print.
And if you're really worried about performance overhead you could get clever at
compile time and make this opt-in or out. Management overhead is a different story
I'm not sure if you're toying with the idea of removing
output to stdout/stderr but I figure I'll share my 2cents anyway.
We make *heavy* use of openldap in containers and having the output go to stdout and
stderr is *super* helpful when debugging issues in vanilla docker or kubernetes.
Not only does stdout allow you to use native tools such as `journalctl` or `kubectl` out
of the box, log aggregation is a completely solved problem in this workflow and is trivial
That being said, persisting logs to disk in a binary format has its merits. Personally,
I don't think plain text logs scale all that well.