----- Original Message ----- > From: "Dan Kenigsberg" <dan...@redhat.com> > To: "Michal Skrivanek" <michal.skriva...@redhat.com> > Cc: devel@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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel