Re: [RFC datacenter-manager/proxmox v2 0/4] log: allow finegrained control logging levels

["Lukas Wagner" <l.wagner@proxmox.com>]

On Wed Sep 23, 2026 at 1:57 PM CEST, Thomas Ellmenreich wrote:
> The core of this change is a simple reinterpretation of the logging environment
> variables that we are already using. Instead of parsing them as a single level
> filter [0], they will now be interpreted as env filters [1]. Since the latter
> can still parse the former, this change is backwards compatible and will not
> break with any logging environment variables that have been set.
>

Thanks for these patches, looking very good so far. I only had very
minor complaints -- see the patch replies for these.

Tested-by: Lukas Wagner <l.wagner@proxmox.com>

With the minor comments addressed and the diff otherwise unchanged:

Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>

>
> Different Log Options
> ---------------------
>
> Combining the different options of the EnvFilter as well as our own default
> log level, we have the following cases for logging:
>
> 1. Env contains 'simple':
>     Meaning that the environment variable contains a simple 'info'... This
>     means that that level is taken as the expected one.
>
> 2. Env contains 'simple', and 'module':
>     Means that the env variable contains a simple log level as well as zero or
>     more module specific log levels. As expected the simple level is applied
>     as a default and then for the specified modules the defined levels apply.
>
> 3. Env only contains 'module':
>     If the env only contains a module (or multiple), that is interpreted by
>     tracing as disabling the default logging and only enabling logging for the
>     module/s
>
> 4. Env is empty:
>     No logs are printed at all, everything is hidden.
>
> 5. Env is not set:
>     This is the only time the default comes into play, by being set as the
>     default log level.
>
> Open Questions
> --------------
>
> - I had the idea that instead of having all users of the proxmox-log crate
>   provide their own 'default_log_level' we could define that inside of the
>   proxmox-log crate. By doing so, we could have the default change between
>   DEBUG and INFO depending on if we are in a normal or release build.

I think keeping the default log level inside the application code is
fine, to me this seems to be inherently application-specific, even if we
are going to use the same default for all rust-based product code for
now.

I'm also not sure if we'd want to automatically switch to DEBUG for
debug builds, there are some crates in our dependency graph that are
*very* noisy at the debug level. E.g.:

Oct 02 09:55:10 pdm proxmox-datacenter-api[1451]: reuse idle connection for ("https", xxx.xxx.xxx.xxx:8006)
Oct 02 09:55:10 pdm proxmox-datacenter-api[1451]: reuse idle connection for ("https", xxx.xxx.xxx.xxx:8006)
Oct 02 09:55:10 pdm proxmox-datacenter-api[1451]: pooling idle connection for ("https", xxx.xxx.xxx.xxx:8006)
Oct 02 09:55:10 pdm proxmox-datacenter-api[1451]: reuse idle connection for ("https", xxx.xxx.xxx.xxx:8006)
Oct 02 09:55:10 pdm proxmox-datacenter-api[1451]: reuse idle connection for ("https", xxx.xxx.xxx.xxx:8006)
Oct 02 09:55:10 pdm proxmox-datacenter-api[1451]: reuse idle connection for ("https", xxx.xxx.xxx.xxx:8006)
Oct 02 09:55:10 pdm proxmox-datacenter-api[1451]: pooling idle connection for ("https", xxx.xxx.xxx.xxx:8006)
Oct 02 09:55:10 pdm proxmox-datacenter-api[1451]: reuse idle connection for ("https", xxx.xxx.xxx.xxx:8006)
Oct 02 09:55:10 pdm proxmox-datacenter-api[1451]: connecting to xxx.xxx.xxx.xxx:8007


>
> - Initially, I found case 3. of the different logging cases quite confusing and
>   would have thought that our 'default_log_level' should apply as default in
>   that case. Unfortunately, when setting 'default_log_level' and then applying
>   the EnvFilter string, tracing applies the modules as expected, but then also
>   overrides the default as '', which means off.

Indeed a bit confusing, but since this is (mostly) a
developer/supporter feature, as long at this behavior is documented
somewhere, it should be manageable.

>
> Notes for the Maintainer
> ------------------------
>
> For all tracing backed logging in Proxmox products to support EnvFilters,
> only patches 1 and 2 have to be applied. The 3 Patch only contains tests
> which I mostly used for understanding, but do still test our defaulting
> behaviour.
>
> Patch 4 is just something I noticed and fixed, but is not necessary to
> fix the Bugzilla issue: [2]
>