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

[Michal Skrivanek]

On Jul 11, 2014, at 13:29 , Antoni Segura Puimedon <asegurap at redhat.com> wrote:

> 
> 
> ----- 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 not opposed to splitting stuff, only to diverge to different files right away. I'd prefer all info flows the same way, then do de-multiplexing, to different files or the same, whatever is required.
As sometimes this admin guy's logs are good enough, but sometimes you need the context so it's better to have it in the same place (i.e. exactly the same in a different/root log file)
It's fine you did it once, it's not fine if everyone does that and we end up with 30 distributed files per group and per problem…without a central location how to redirect things or without a holistic detailed view for real debugging.
anyway, it's a very minor point, nevermind...

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

I think we'd benefit from some simple set of wrappers/scripts to make it comfortable
Comfortable for support engineers too. I just still want them to at least log on the damn box, that's the least you can do…:)
(seriously, I'm concerned about too much of an ignorance if it's too simple. Enabling debug (as well as running logcollector) is a dangerous thing to do)

Thanks,
michal

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