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

[Dan Kenigsberg]

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/.

<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.