https://bugs.openldap.org/show_bug.cgi?id=10267
Issue ID: 10267 Summary: stats loglevel reduction Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: chris.paul@rexconsulting.net Target Milestone: ---
In high volume situations, stats logging of all transactions is not worth the cost of disk space and disk iops. However, turning logging off altogether (loglevel 0) results in no visibility for errors.
It would be very useful to be able to log errors only.
https://bugs.openldap.org/show_bug.cgi?id=10267
--- Comment #1 from Ondřej Kuzník ondra@mistotebe.net --- Hi Chris, logging only errors, you only get the RESULT message logged so you have no information about what was being requested? And at the beginning of a request, you have no idea whether it will result in an error (you're suggesting it won't usually, so we have to decide *not* to log it).
I'm not sure how you want to get anything useful out of this?
https://bugs.openldap.org/show_bug.cgi?id=10267
--- Comment #2 from Howard Chu hyc@openldap.org --- loglevel `none` already does errors-only.
https://bugs.openldap.org/show_bug.cgi?id=10267
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- On Mon, Oct 07, 2024 at 02:25:38PM +0000, openldap-its@openldap.org wrote:
loglevel `none` already does errors-only.
I took it to mean operations that send a non-success result message rather than messaged tagged LDAP_DEBUG_ANY. Otherwise yeah.
https://bugs.openldap.org/show_bug.cgi?id=10267
--- Comment #4 from chris.paul@rexconsulting.net chris.paul@rexconsulting.net --- Yes I mean operations that send a non-success result message, and I also am aware that this would be useless without other information (PeerAddress, AuthzDN).
I'm thinking of DOS situations, where a sudden and continuous burst of load has made performance suffer. Ironically, the amount of logging being done during such a burst of load, causes significantly more load, which brings the server from its knees to on its belly.
I realize that there's no easy fix to this. I realize that if the team is willing to consider solutions, that it won't come soon.
It almost seems that logging should be binary, condensed to as small of a blob as possible for shipping off server for decompression and analysis. Doing log analysis on a running server, especially in a DOS situation, it not feasible.
I'm seeing TB per day of logging in one environment, when on. The "solution" at the moment is to turn off logging, and then use cn=connections,cn=monitor to identify the culprit and reduce the load so that we can turn monitoring back on.
https://bugs.openldap.org/show_bug.cgi?id=10267
--- Comment #5 from chris.paul@rexconsulting.net chris.paul@rexconsulting.net --- I maybe should add something. For anyone thinking that the so-called "DOS" condition I mention is internet based, that this is not the case. This DOS/high load situation is on an internal network and is unintentional.
https://bugs.openldap.org/show_bug.cgi?id=10267
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review |
-
openldap-its＠openldap.org