From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 5EE1D9C728 for ; Tue, 24 Oct 2023 15:44:35 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2DAB08E9E for ; Tue, 24 Oct 2023 15:44:05 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 24 Oct 2023 15:44:04 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 57AB444B9B for ; Tue, 24 Oct 2023 15:44:04 +0200 (CEST) Message-ID: <6a18e5e1-7abd-4e4f-8435-9814cb8fa979@proxmox.com> Date: Tue, 24 Oct 2023 15:44:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox Backup Server development discussion , Dominik Csapak References: <20231011140102.273423-1-g.goller@proxmox.com> <4e0de017-9fbf-4a5e-b735-62b955fe8a8b@proxmox.com> <0fd77836-896a-4017-9300-b74be824f346@proxmox.com> <030d3735-02c2-4a6e-860f-e8b6521e7e0e@proxmox.com> <16069173-747d-4083-8b9b-5ea448732ef2@proxmox.com> Content-Language: en-US From: Gabriel Goller In-Reply-To: <16069173-747d-4083-8b9b-5ea448732ef2@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.294 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [RFC proxmox-backup 0/2] Tasklog rewrite with tracing X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2023 13:44:35 -0000 On 10/23/23 16:33, Thomas Lamprecht wrote: > [..] > - if in worker task: > - log info and higher to worker task log > - mirror error level to syslog too > > - if not in worker task: > - log warnings and higher to syslog > > It's slightly magic, but fit our reality quite well. > > For forcing other logs, or a debug level, to a target too, one then > could provide environment variables, or an API command-socket command > for a dynamic change of max-level to log – especially the latter is > a bit orthogonal to this and should be done later. Yes, sounds good! I should be able to implement this. > semi-related: I didn't check the series in detail, so sorry if already > answered there, but how's the story for logging specific spans? > > As logging levels are normally rather coarse, especially on complex > tasks one can have a log going on, and so it can be helpful to, e.g., > enable debug logging only for some specific "topics", especially if > one is debugging an issue that a user faces, but one cannot (easily) > reproduce themselves. But, I guess that is unrelated from your current > work here, or did you already think about that? > > (the place I'd want something like that the most is pmxcfs, as there > you can currently only decide if you want very sparse information or > every detail times ten for about every file operation happening, very > frustrating) Hmm this is a tricky one... With the current RFC this is only possible by reloading a specific layer (syslog or task_log) using another log-level (and thus we need to pass a reload-handle around, which is not optimal). But, if this is frequent, we could add another layer (conveniently called debug_layer or something) that is only active inside a span with a specific name and prints all levels to syslog. This layer would only be used when debugging and shouldn't impact runtime performance that much (although I will check this). So you would basically wrap your critical code with a span: fn super_long_function_with_critical_stuff() {     let span_guard = tracing::span!(Level::INFO, "debug").entered();     // other code that emits logs     // the `span_guard` will be dropped at the end and the span will end     // we can also end the span manually using `span.exit()` } We then have a special layer, that will check if the log is in a span with name 'debug' and will write to syslog without checking the max log level.