Re: [RFC] connections logging

On 06/24/2014 12:55 AM, Amos Jeffries wrote:
> On 24/06/2014 4:41 p.m., Kinkie wrote:
>> On Tue, Jun 24, 2014 at 2:26 AM, Alex Rousskov wrote:
>>> On 06/20/2014 03:04 AM, Amos Jeffries wrote:
>>>> The driver behind this is to help resolve a growing amount of user
>>>> queries regarding "happy eyeballs" idle connections and broken TLS
>>>> connections. We are also adding other potentially never-used connections
>>>> ourselves with the standby pools.

>>> A couple of days ago, I came across another use case for logging
>>> connections unrelated to Happy Eyeballs. It sounds like this is going to
>>> be a generally useful feature. My use case is still being clarified, but
>>> here are the already known non-obvious requirements:

>> I have an use case, as well: timing logging.
>> It would be useful to have a chance to log the timing of certain key
>> moments in a request's processing path. Things like accept, end of
>> slow acl matching, end of dns resolution(s), connected to uplink, and
>> so on. This could help administrators identify congestion issues in
>> their infrastructure.

> And that use case gives us a good potential name for it. event.log ?

I was also going to say that if we want to log more than just
connection-specific events, then we should expand the proposal to
accommodate "arbitrary" events. Needless to say, the initial
implementation may only support one or two event kinds, but the design
should allow for other future event kinds.

Other known use cases include logging initial HIT or MISS detection: I
had to patch Squid recently to enable that event logging (for legacy
reasons the admin could not use ToS marks).

This kind of circles back to the "debugging" discussion we are avoiding
on another thread -- in both cases, we need an internal API to signal
useful events and the corresponding configuration knobs to control their
logging. The line between "developer-useful (i.e., debugging)" events
and "admin-useful" events is blurry, but we do not have to define it if
we just focus on logging admin-useful stuff. I would not be surprised if
this eventually morphs into a "better debugging" interface as well.

Cheers,

Alex.
Received on Tue Jun 24 2014 - 16:18:01 MDT