[pbs-devel] [PATCH proxmox-backup 2/2] traffic-control: add debug log when we found a matching rule

[Thomas Lamprecht]

On 04.02.22 11:09, Dominik Csapak wrote:
> On 2/4/22 11:05, Thomas Lamprecht wrote:
>> On 04.02.22 10:12, Dominik Csapak wrote:
>>> Signed-off-by: Dominik Csapak <d.csapak at proxmox.com>
>>> ---
>>> optional, at least one user in the forum has a problem with traffic
>>> control, this could help debug that in the future...
>>
>> Above needs to be in the commit message and actually linking to the relevant
>> forum thread.
>>
>> in general sure, but I dislike the direction of the approach, as its again
>> moving in the same direction as e.g., pmxcfs, a single boolean flag for all
>> or nothing, which in practice will soon mean that's rather useless as its
>> spamming so much stuff that relevant things get drowned even for experienced
>> users.
>>
>> More fine grained approach it both, the verbosity and the topic axis would
>> be much nicer, especially the latter as then a user could only enable
>> traffic-control related logs.
>>
>> But just mentioning as this is a major pain point in pmxcfs that I get "hurt"
>> by frequently..
> 
> makes total sense. did you already imagine any way to enable this?

I haven't thought out any specifics for our rust env yet, fwiw log provides a target
and the module-path in the Record metadata, either or both could be used for employing
some filtering.

FWIW, we already depend transitively on the `tracing` crate, which could be also
leveraged for a use case like this. Maintaining that is some work, IME having, somewhat
thought out, tracing integrated in a system can make debugging and the like multiple
orders of magnitude easier and faster.

> could we simply have some 'sections' (like tc,connections,etc.)
> and enable them like this:

I would imagine that sections could be seen as what I called topics, so yes,
something like that.

> PROXMOX_DEBUG=tc=debug,conn=info,foo=none
> 
> or should we avoid the environment variable at all, and put it in
> the node config?
> 

would be an option, but IMO not too relevant where the current level comes from, I'd
figure that once we decide on a basic direction of how/what the setting source should
be rather on the easy side.