all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Gabriel Goller <g.goller@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
	Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [RFC proxmox-backup 0/2] Tasklog rewrite with tracing
Date: Mon, 23 Oct 2023 11:09:18 +0200	[thread overview]
Message-ID: <0fd77836-896a-4017-9300-b74be824f346@proxmox.com> (raw)
In-Reply-To: <4e0de017-9fbf-4a5e-b735-62b955fe8a8b@proxmox.com>

On 10/18/23 15:12, Dominik Csapak wrote:

> hi, a high level comments on this series:
>
> you implemented a 'tasklog' = true filter, which is nice, but not 
> filter for the syslog
> in general we'd want to land things either in the task log (preferred) 
> or in the syslog,
> not in both (e.g. for some tasks this pollutes the syslog unnecessarily)
>
Ok, this should be easy, we just check in the `syslog_layer` if the 
`task_log` attribute
is None in the Metadata. Like this we only log to task_log OR syslog.
> so i'd like to see also a syslog = false (or syslog = true)  and maybe 
> some
> functionality to enable/disable that for whole block (if that's even 
> possible?)
As mentioned in the other patch, currently we can't inspect metadata 
values when enabling/
disabling a layer :/ .
What do you mean exactly by 'disabling in a whole block'?

We could enable/disable the filelog layer in specific rust modules (not 
so useful for us)
or e.g, create a span on thread/task creation and then let all the logs 
in that span go to
the task_log? The problem with that is that we would have to create an 
specific attribute
to log to syslog while we are in a worker_task context (e.g. 
`info!(syslog = true, "to syslog")`)
and it's not so clear anymore where we write (i.e. I'd have to look at 
the context to know
if a `log::info!()` call writes to task_log or syslog).

IMO having a explicit `tasklog` attribute on every event is good (The 
name is obviously debatable,
we could choose something shorter, or create a macro `task_info!` to 
make it easier to use).




  reply	other threads:[~2023-10-23  9:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-11 14:01 Gabriel Goller
2023-10-11 14:01 ` [pbs-devel] [RFC proxmox-backup 1/2] log: removed task_log! macro and moved to tracing Gabriel Goller
2023-10-11 14:01 ` [pbs-devel] [RFC proxmox 2/2] proxmox-log: added tracing infra Gabriel Goller
2023-10-13 12:36   ` Gabriel Goller
2023-10-18 13:26   ` Dominik Csapak
2023-10-23  8:56     ` Gabriel Goller
2023-10-23  9:11       ` Gabriel Goller
2023-10-18 13:12 ` [pbs-devel] [RFC proxmox-backup 0/2] Tasklog rewrite with tracing Dominik Csapak
2023-10-23  9:09   ` Gabriel Goller [this message]
2023-10-23  9:29     ` Dominik Csapak
2023-10-23 11:43       ` Gabriel Goller
2023-10-23 14:33       ` Thomas Lamprecht
2023-10-24 13:44         ` Gabriel Goller
2023-10-25 13:55           ` Gabriel Goller

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=0fd77836-896a-4017-9300-b74be824f346@proxmox.com \
    --to=g.goller@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pbs-devel@lists.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