Re: RFC: debugs() improvements

On 2014-02-13 10:36, Alex Rousskov wrote:
> On 02/11/2014 04:49 AM, Kinkie wrote:
>
>> During recent discussion on IRC it was found out that there are not
>> that many big patches queued for landing to trunk; it may be a good
>> moment to rework more aggressively at least part of the debugs()
>> statements.
>
>> I would like us to get a consensus on this,
>
> If you are asking about specific API/design changes rather than just
> the
> fact that now is a good time to do them, then I suggest that we attack
> the problem simultaneously from several different angles:
>
> 1. "Admin messages" or "default logging" (admins need this):
> 1a. What kind of info should be logged to syslog by default.

- None? Busy systems get enough garbage in syslog to require specialized
log tracking tools by the admin. Adding to that volume by default is
probably a bad idea.

- perhapse DBG_CRITICAL if we actually want to fix the wet-ware bug some
admin have of only checking syslog for errors.

> 1b. What kind of info should be logged to cache.log by default.

see debug_options config directive.

Or are you suggesting a different model for message filtering is
required?

> 1c. How to allow admins to selectively control syslog and
> cache.log messages when Squid defaults do not work well.

See squid -l and -d command line options.

> 1d. How to make admin message text uniform and stable,
> to allow for better automation and documentation.
> 1e. How to document admin messages.

Wiki and in the message itself. This is already in the guidelines and
TODO task list. People are just not doing the wiki part for new
CRITICAL/IMPORTANT messages.

So the real 1d-e question is how to improve the requirements to make
better documentation coverage happen?

>
> 2. "Debugging" (support folks and developers need this):
> 2a. How to improve selective control of debugging volume and scope.

see 1d.

> 2b. How to enable/disable debugging based on rare condition(s).
> 2c. How to fully debug specific transactions or events.

This is good but can/should be a stand-alone project I think. It does
not need to affect every debugs() line in Squid, whereas the other items
here may require such.

> 2d. How to decrease noise and increase usefulness of debugging logs.

Yes. Agreement on a definition for the use of debug levels 2-8 would be
a great start.

>
> 3. Writing debugging code (developers need this):
> 3a. How to make it easier to write good debugging statements.
> 3b. How to verify that a debugs() call complies with the new rules.
> 3c. How to keep default logging overheads low while addressing #1.
> 3d. How to lower performance overheads of debugging while addressing
> #2.
>
>
> There is significant overlap within each section and even between the
> three sections, of course. That is one of the reasons why I think a
> comprehensive solution is needed here as opposed to small incremental
> changes. Another reason to push for a comprehensive solution is the
> amount of widespread code changes most significant improvements ought
> to
> trigger.
>
> I am sure all of us have specific suggestions/ideas for at least some
> of
> the above areas, but I wanted to propose the above skeleton framework
> to
> better structure the initial debate. Once we settle on the overall
> goals/scope/structure of this project, we should probably document our
> agreement on the wiki and start accumulating specific suggestions/ideas
> there.
>

I get the opposite conclusion out of your framework. The sheer size of a
"comprehensive" project involving debug texts is effectively a full
re-write of the Squid codebase in itself (almost every other line
touched). Looking at it sideways this is effectively a fork unless it is
done directly in trunk. I don't think we really want or need to fork
Squid over this.

We know that there are some specific actions that can be taken (ie
removing HERE macro) which will greatly improve debug verbosity in both
log and sources. Now seems a good time (the best?) to take those steps
in trunk with minimal annoyance from touching so much code.

>
>> and define some subtrees
>> where work is being done and which should thus not be touched now
>> because they're being worked on (e.g. the parser-ng work)
>
> The only large pending Factory patch that I am aware of is ftp-gw. I am
> pretty sure that by the time debug-ng design is agreed upon and
> implemented, the native FTP code will be submitted for review and,
> hopefully, committed -- we just need to finish reshuffling the
> files/class as agreed previously on squid-dev...

parser-ng will be fine. Code shuffling in that project is relatively
small and debugs() conflicts are not an issue for brand new or dropped
code.

The connection-manager branch is affected a large amount. However, at
present I can cope with conflicts there fairly easily provided they are
limited to polishing existing debugs() lines. Or if Alex and I can agree
on finalizing the changes soonish, it may become a non-issue.

Amos
Received on Wed Feb 12 2014 - 23:40:51 MST