From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 91CC11FF0AB for ; Wed, 23 Sep 2026 12:28:22 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 35CDF21492; Wed, 23 Sep 2026 12:28:22 +0200 (CEST) From: Thomas Ellmenreich To: pbs-devel@lists.proxmox.com Subject: [RFC proxmox-backup 0/2] backup log: reduce logging during backup Date: Wed, 23 Sep 2026 12:27:57 +0200 Message-ID: <20260923102759.139819-1-t.ellmenreich@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1790159298054 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.405 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) KAM_SHORT 0.001 Use of a URL Shortener for very short URL POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: UGCS6FFC5WYLEAH7YYA2BO6VGMB6AI4L X-Message-ID-Hash: UGCS6FFC5WYLEAH7YYA2BO6VGMB6AI4L X-MailFrom: t.ellmenreich@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Thomas Ellmenreich X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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. 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(-) -- Generated by murpp 0.12.0