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

From: "Dan Kenigsberg" <danken(a)redhat.com&gt; To: "Michal Skrivanek" <michal.skrivanek(a)redhat.com&gt; Cc: devel(a)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/.

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

_______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel