all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Christian Ebner <c.ebner@proxmox.com>
To: Thomas Ellmenreich <t.ellmenreich@proxmox.com>,
	pbs-devel@lists.proxmox.com
Subject: Re: [RFC proxmox-backup 0/2] backup log: reduce logging during backup
Date: Thu, 24 Sep 2026 18:00:01 +0200	[thread overview]
Message-ID: <583eb8c1-f071-4a1a-945d-0ba0cba3f8c1@proxmox.com> (raw)
In-Reply-To: <20260923102759.139819-1-t.ellmenreich@proxmox.com>

Thanks for tackling this log standing issue!

On 9/23/26 12:28 PM, Thomas Ellmenreich wrote:
> There are a few different forum posts discussing the excessive default logging
> of the proxmox-backup-client and its server counterpart: [0], [1]. A lot of the
> heavy lifting has been done by Gabriel Goller as mentioned here [0] this just
> addresses the final client side setting.
> 
> The final implementation just uses proxmox_log::enabled! to determine the log
> settings and set the debug flag accordingly. By doing so, in all normal cases,
> where INFO is the default verbosity level the following logs should NOT be
> displayed anymore:
> 
> - 'download chunk "...' [0]
> - 'GET /chunk' [0]
> - 'successfully added chunk' [1]
> 
> Originally, I was planning on implementing this in a way more complex way, but
> then ended up choosing this one for now. The current method is used in a few
> other places around the codebase and this series would definitely work
> perfectly as is.

The current implementation does however only cover the logging for 
backup writers? Backup readers and other tasks would still potentially 
produce large logs. So this does not fully fix the issue as raised in 
the bug-tracker.
E.g. for pull sync jobs logging is enabled on the remote source side via 
the final boolean flag [0]. And other readers might set this as well.

The main issue is that server-side and client-side logs are intertwined 
as described here [1] and [2].

Given that, I think it could make sense to use a lower effort approach 
as layered out by your patches for the time being, deprecate the client 
side flag with the next major release and drop it fully on the 
subsequent major release. At that point a properly decoupled logging 
with tracing subscribers can be put in place.

What's other developers opinion on this?

[0] 
https://git.proxmox.com/?p=proxmox-backup.git;a=blob;f=src/server/sync.rs;h=11f30d318b2d64c7dd988cbd0ccfd8fc6998b36a;hb=HEAD#l500
[1] 
https://git.proxmox.com/?p=proxmox-backup.git;a=blob;f=src/api2/backup/environment.rs;h=be70d74f828e33b0020d4b7b5825cf98af77901d;hb=HEAD#l907
[2] 
https://git.proxmox.com/?p=proxmox-backup.git;a=blob;f=src/api2/reader/environment.rs;h=e98a001b83ab80122e2f6f939237d5416c0fcd17;hb=HEAD#l59

> That said, I have considered two other options:
> 
> Proper Implementation
> ---------------------
> 
> The current implementation sets the debug flag on the client, which then passes
> it to the server. The server then has a mechanism, separate from tracing, to
> decide if to issue 'debug' or 'info' logs.
> 
> My initial idea was to replace the existing debug flag on all API endpoints
> with an EnvFilter [3] string, which would then be used to change the local
> filtering behaviour to match the one on the client. [*]
> 
> Aside from the question if we really want the client to control server logging
> (also in the current impl), this implementation would be quite complex and
> would require a version of this series: [2] to be applied first.
> 
> [*]: This would be done by layering a scoped subscriber over the global one. The
>       new subscriber would only affect logs in the current function while the
>       guard has not been dropped.
> 
> Deleting the serverside
> -----------------------
> 
> To be quite frank, I find that deleting this functionality altogether might be
> the best option. A person that would look at the logs on serverside also has
> the access to change the serverside loglevel. Additionally, the aforementioned
> Series [3] would then allow very fine grained control of the log settings.
> 
> As a note, with the current setup, one can set the server side log level to
> TRACE, but if the client doesn't enable the debug flag, none of these logs will
> be printed. So by deleting the flag, the custom log filtering mechanism on
> serverside can also be deleted.
> 
> [0]: https://forum.proxmox.com/threads/how-to-stop-syncjob-flooting-syslog.118894/#post-546081
> [1]: https://forum.proxmox.com/threads/enhancement-suggestion-log-levels.130080/
> [2]: https://lore.proxmox.com/pdm-devel/20260921095210.229315-2-t.ellmenreich@proxmox.com/T/#t
> [3]: https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html
> 
> 
> proxmox-backup:
> 
> Thomas Ellmenreich (2):
>    backup writer: add constructor for BackupWriterOptions
>    fix #4646: backup writer: base debug flag on log level
> 
>   examples/upload-speed.rs               | 15 +++++++--------
>   pbs-client/src/backup_writer.rs        | 21 +++++++++++++++++++++
>   proxmox-backup-client/src/benchmark.rs | 15 +++++++--------
>   proxmox-backup-client/src/main.rs      | 15 +++++++--------
>   src/server/push.rs                     | 17 ++++++++---------
>   5 files changed, 50 insertions(+), 33 deletions(-)
> 
> 
> Summary over all repositories:
>    5 files changed, 50 insertions(+), 33 deletions(-)
> 





      parent reply	other threads:[~2026-09-24 16:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23 10:27 [RFC proxmox-backup 0/2] backup log: reduce logging during backup Thomas Ellmenreich
2026-09-23 10:27 ` [PATCH proxmox-backup 1/2] backup writer: add constructor for BackupWriterOptions Thomas Ellmenreich
2026-09-24 16:06   ` Christian Ebner
2026-09-23 10:27 ` [PATCH proxmox-backup 2/2] fix #4646: backup writer: base debug flag on log level Thomas Ellmenreich
2026-09-24 16:00 ` Christian Ebner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=583eb8c1-f071-4a1a-945d-0ba0cba3f8c1@proxmox.com \
    --to=c.ebner@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    --cc=t.ellmenreich@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal