We recently focus on providing lots of tracing messages in new code that
helps us follow the code, however this makes the debug logs quite big
and we usually focus only on a specific area or task while debugging. A
year ago we discussed what we can do to improve our debugging
capabilities but it never got into action since we hit the long standing
requirement to revisit all debug messages and their levels.
1) Originally, we had only numeric debug levels. The problem here was
that those numbers were assigned relatively randomly per developer decision.
2) My first task when I joined the team was to change the levels from
numeric to a bit mask. This seemed good at first as it allows to select
specific messages that we want to see but it was never polished into a
usable feature for two main reasons -- it required us to revisit all
existing messages and it turned out it actually doesn't make much sense
to disable any lower level since if you want to see tracing message you
always want to see error etc. So in the end the bit mask is used in the
same way as numeric representation (if used at all) it is just harder to
read.
My needs when debugging some issue are very simple -- be able to see as
small log as possible but having all errors and tracing messages. The
problem usually lies in a small area of code and I don't need to see
other parts of code that hinders these messages.
As a developer I would like the change into new format be seamless so it
does not require manual changes into current code. And I would also like
to have smaller number of choices.
What I propose is this: have a numeric debug level and a bit mask
representing an sssd component.
*Debug level*
0 = Fatal failures, important messages. Always enabled. For cases that
prevents SSSD from starting and for very important messages.
1 = Errors, for any error that we can recover from.
2 = Warnings, for unexpected situations were we can actually continue
with the operation. (E.g. when processing bunch of objects in a for
cycle and continue on error).
3 = Data, for user input, configuration.
4 = Trace, for tracing code flow.
5 = Verbose, for things that are very rarely required and would just put
lots of things into logs (e.g. verbose information about sudo rules).
*Component*
An SSSD module as separated from the rest as possible. For example: all,
failover, sudo, id, subdomains, ldb, ... lots of possibilities.
SSSD needs to be started or configured with two options
--debug-leve=number, --component=bitmask (default all). Messages with
level <= numeric and component & mask are printed.
Ideally components can be separated also on makefile level into static
libraries that we will link with. This would help with unit testing
those parts since we wouldn't have to maintain source file list in unit
test definitions but link with a library instead. It would also speed up
compilation. This library could have -DSSS_COMPONENT_NAME=$name and we
wouldn't even have to put it in DEBUG macro.
Thoughts?
_______________________________________________
sssd-devel mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
