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 entirely.
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 to implement.
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.
Matt Pallissard
Matt Pallissard