On 06/17/2011 01:59 PM, Stephen Gallagher wrote:
We've put this off for far too long, but I think we need to
decide on a
formal specification of what the various log levels mean in SSSD (and
then open a ticket to go through them all clean them up).
We didn't do this in the past because we had expected that this would be
handled when we eventually integrated with the ELAPI (Event-Logging API)
project. Unfortunately, that project stalled upstream and its future is
unknown.
So I think we need to document the exact purpose of each log level and
publish this information so that consumers of the SSSD can have a good
understanding of what level they should set (or leave running in
production).
I'll give my first suggestions, and then I'll listen to criticism :)
First, I think we need to break the debug levels up into three ranges,
roughly corresponding to error messages, informational messages and
developer messages.
So I propose that error messages should be 0-3
0: Fatal failures. Anything that would prevent SSSD from starting up or
causes it to cease running. (Example: sssd.conf fails to parse)
1: Critical failures. An error that doesn't kill the SSSD, but one that
indicates that at least one major feature is not going to work properly
(Example: Kerberos keytab does not have a valid principal for
SASL/GSSAPI LDAP)
Should we always log these ^^^ to syslog or decide per-case?
2: Serious failures. An error announcing that a particular request
or
operation has failed. (Example: DP returns PAM_SYSTEM_ERR)
3. Minor failures. These are the errors that would percolate down to
cause the operation failure of 2. (Example: The above PAM_SYSTEM_ERR was
due to the krb5_child returning an unexpected error)
Ack
Informational messages should be 4-6
4. Configuration settings (E.g. the dp_option loading)
5. Function data (E.g. LDAP search request data, Dynamic DNS message)
6. Tracing messages for functions (Example: received DBUS method call
"ping")
I agree with DBus calls like reloadConfig or resetOffline being about
this level, but I think "pings" might be one level up.
That would move 7 to 8 and fill the ??? as well :-)
Developer messages should be 7-9
7. Contents of function-internal variables that may be interesting
8. ???
9. Extremely low-level tracing information (Example: adding/removing
D-BUS watches)
Can/should we change the level existing debug messages? Something
related that I always wanted to do was move everything that is NOT
tracing information away from log level 9.
The reason being that we often use level 9 for more useful info that
gets mixed up with D-Bus watches, LDB tevent traces etc.