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-----