3:21 p.m.
On Jul 11, 2014, at 13:29 , Antoni Segura Puimedon <asegurap(a)redhat.com> wrote:
----- Original Message -----
> From: "Dan Kenigsberg" <danken(a)redhat.com>
> To: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
> 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 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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel