[SSSD] Discussion of debug log levels

Dmitri Pal dpal at redhat.com
Fri Jun 17 14:40:06 UTC 2011


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/






More information about the sssd-devel mailing list