Re: RFC: debugs() improvements

On 02/12/2014 04:40 PM, Amos Jeffries wrote:
> 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.

I do not have a strong opinion on this one, but note that we do log
stuff there now, so a change would be required of "none" is the consensus.

> - 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.

debug_options config directive does not define what kind of info should
be logged to cache.log by default. It is a policy/design question that
no squid.conf directive can answer. The directive only controls what
existing level-2+ messages are logged, not what should be logged by default.

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

For 1b, I am suggesting that we try to agree what should be logged to
cache.log by default. Currently, we often log too much and sometimes do
not log enough. It would be good to agree on some general
rules/principles for that. This default is unrelated to message filtering.

>> 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.

Those do not give enough control when Squid spams an admin with
pointless messages about malformed traffic, but the admin does not want
to disable all syslog/cache.log reporting to get rid of that spam.

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

Please note that 1d is different from 1e.

>> 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.

Where is it on the wiki? My quick search did not hit anything relevant
at http://wiki.squid-cache.org/Squid3CodingGuidelines

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

I do not think so. 1d is about the shape/style/rules for message text.
1e is for finding a way to explain what a brief log message really means
and a way for an admin to find that explanation. If all of that is
documented/solved somewhere, great, but I do not think it is.

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

1d seems mostly unrelated to 2a. 1d is about message looks/content for
default messages. 2a is about mechanisms enabling and disabling groups
of debugging messages.

>> 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.

These two items may affect debugs() parameters and implementation.

>> 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.

Or a dead-end if levels are not the right solution to the problem. It is
easy to solve most of this items in isolation, but I think we need a
comprehensive approach because isolated solutions will not work well
together.

>> 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.

I disagree. To minimize changes, we can focus on (a) worst offenders and
(b) new code. We may not get 100% of what we want (if we even can agree
on what that is!) but we may be able to improve the situation
significantly soon and gradually thereafter.

For example, fixing messages that are frequently logged by default will
not affect "almost every other line" at all, and some of the features
can be introduced without changing the old debugs() statements.

> 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.

Removing HERE would have no effect on what is logged and very little
effect on the code itself (except for merge conflicts).

> Now seems a good time (the best?) to take those steps
> in trunk with minimal annoyance from touching so much code.

I [still] do not see enough value in removing HERE for the sake of
removing HERE alone, and there are certainly bad side-effects from doing
that. This is one of the reasons a comprehensive approach would work
better IMO -- it may add value to things like removing HERE because
other changes can be done at the same time, minimizing the total
conflict pain.

Cheers,

Alex.
Received on Thu Feb 13 2014 - 07:46:46 MST