[ovirt-devel] [vdsm] logging levels and noise in the log

[Antoni Segura Puimedon]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> Cc: devel at ovirt.org
> Sent: Friday, July 11, 2014 1:22:44 PM
> Subject: Re: [ovirt-devel] [vdsm] logging levels and noise in the log
> 
> On Fri, Jul 11, 2014 at 09:13:27AM +0200, Michal Skrivanek wrote:
> > 
> > > 
> > > I have recently introduced a connectivity.log, that tracks changes in
> > > host network devices. Adding parallel logs for other important
> > > admin-understandable changes makes sense.
> > 
> > I wonder if this is the right approach…IMHO it's not, as you have to
> > now take care of the additional file in the context of your code. It's
> > easy to diverge then.
> > Why not follow the syslog-like way with config, splitting/limiting files
> > based on e.g. subpackage prefix, etc…
> 
> I am not sure what you suggest. In my implementation, a piece of the
> code that wants to log a connectivity-related issue, it asks for
> logging.getLogger('connectivity'). The whole idea is that the reader of
> this code is not interested on the subpackage or module emitting the
> error. He just wants to know that it affects connectivity. In that, it
> is similar to Sven and Nir's request - a log file that is more inclining
> to the admin, and less to the developer.
> 
> > 
> > I'm sure it was brought up many times before….why don't we just send
> > it to syslog?:)
> 
> IIRC it was striked down since just because it was complex to configure
> syslog.conf and/or rsyslog.conf properly. Doing the de-multiplexing of
> log messages in /etc/vdsm/logger.conf was much easier.
> 
> I think that nowadays, we could just drop a file onto /etc/rsyslog.d/.

I'd go for this.

> 
> <snip>
> 
> > > 
> > > Vdsm has a setLogLevel; it must have rotton out of disuse. But I'd love
> > > to see an Engine option for "cluster debug level", that is overridable
> > > per-host. Each admin should decide what does they care more about:
> > > debugablility by developers, or the bliss of quiet logs.
> > 
> > per host sounds good for vdsm (btw engine suffers from the same)
> > I wouldn't bother with UI though….I kind of never understood the tools
> > which have "enable debug" checkbox in UI but then you anyway have no idea
> > what is it now creating, what's the impact on the system, where to look
> > for it.
> > I think debug should remain a purely troubleshooting measure, hence
> > requiring you to log to host and do something, look/analyze/copy the big
> > dump of info…and then turn it back.
> > High debug levels typically bring some caveats like less performance…it
> > shouldn't be something I can blindly check and forgot about it in UI.
> 
> I'm thinking about the support engineer. He needs as much logs as the
> user can give him. By moving away of default DEBUG level, we are taking
> one of his most important tools. The least we can do is to make it easy
> on him to re-enable it.

I'd have either a verb for vdsmd/supervdsmd or a signal that can be sent
via vdsClient to a running daemon to modify the logging level.

> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel