Re: [SSSD] Discussion of debug log levels
On 06/17/2011 10:20 AM, Simo Sorce wrote:
On Fri, 2011-06-17 at 07:59 -0400, 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)
> 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)
>
> 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")
>
> 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)
Looks fine to me, but should we also discuss a separate Logging facility
that spits only logs that are of interest for admins/auditors ?
I am thinking of the difference between access/errors logs in
apache/dirsrv/etc ...
Simo.
This is fine. It really a pity that we can't use ELAPI.
We are going to build one more custom solution that we would be private
to our project.
I know that fate of ELAPI is unknown and that I do not have time work on it.
But looking at the problems and goals being discussed here I really wish
we could have it.
Especially the issue of multiple destinations.
Please hide this all behind a macro. There is still a chance that ELAPI
would be implemented one day.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/