Re: New logging system ideas
"Pallissard, Matthew" <[email protected]> Wed, 11 Mar 2020 07:39:45 -0700
| Newsgroups | gmane.network.openldap.devel |
|---|---|
| Message-ID | <20200311143945.7433anthp4i6r7tg@matt-gen-desktop-p01.matt.pallissard.net> |
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. 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
signature.asc
(application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTvIUMPApUGn6YFkXl1uof+t048SQUCXmj4LQAKCRB1uof+t048 SWnDAP47qXTHo4r1zuH3OBG2WKGx+EFbQSBRaRGrLUMmLHfL0gEA/UXABTgqjfCq 6nVMCUoBc48YiCdHOyOU9g1VRr1pvwg= =6jQJ -----END PGP SIGNATURE-----