Re: [Xen-devel] [libvirt] [PATCH] libxl: open libxl log stream with libvirtd log_level

[Marek Marczykowski-GÃrecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Nov 11, 2015 at 04:04:22PM +0000, Daniel P. Berrange wrote:
> On Wed, Nov 11, 2015 at 04:57:59PM +0100, Marek Marczykowski-GÃrecki wrote:
> > On Tue, Sep 15, 2015 at 11:21:00AM -0600, Jim Fehlig wrote:
> > > Daniel P. Berrange wrote:
> > > > On Tue, Sep 15, 2015 at 10:57:50AM -0600, Jim Fehlig wrote:
> > > >   
> > > >> Daniel P. Berrange wrote:
> > > >>     
> > > >>> On Tue, Sep 15, 2015 at 09:26:23AM -0600, Jim Fehlig wrote:
> > > >>>   
> > > >>>       
> > > >>>> Instead of a hardcoded DEBUG log level, use the overall
> > > >>>> daemon log level specified in libvirtd.conf when opening
> > > >>>> a log stream with libxl. libxl is very verbose when DEBUG
> > > >>>> log level is set, resulting in huge log files that can
> > > >>>> potentially fill a disk. Control of libxl verbosity should
> > > >>>> be placed in the administrator's hands.
> > > >>>>
> > > >>>> Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>
> > > >>>> ---
> > > >>>>  src/libxl/libxl_conf.c | 18 +++++++++++++++++-
> > > >>>>  1 file changed, 17 insertions(+), 1 deletion(-)
> > > >>>>     
> > > >>>>         
> > > >>> ACK, this makes sense as default behaviour. As a future enhancement
> > > >>> you might also consider supporting a config setting in 
> > > >>> /etc/libvirt/libxl.conf
> > > >>> to explicitly control the libxl library logging behaviour 
> > > >>> independantly.
> > > >>>   
> > > >>>       
> > > >> I had actually thought of adding it there first, but then took this
> > > >> approach assuming it would be more receptive upstream :-). Personally,
> > > >> I'm on the fence. I like the idea of a single knob to control log level
> > > >> throughout the daemon, making it a bit easier on admins. On the other
> > > >> hand, individual knobs are more friendly to those pouring through logs.
> > > >> I can add a knob in libxl.conf if preferred.
> > > >>     
> > > >
> > > > After thinking about it some more, I could actually see value in
> > > > create a dedicated virLogSource() instance, solely for libxl
> > > > library messages. If we then created a virLogSourceGetPriority()
> > > > method, you could query that to see if to turn on logging for
> > > > the libxl library. That would ultimately allow you to turn on
> > > > debug for just the libxl library if desired, eg
> > > >
> > > >  static virLogSource virLogLibXL = {
> > > >      .name = "libxl.libxl_library",
> > > >      ....
> > > >  }
> > > >
> > > > LIBVIRT_LOG_FILTERS="1:libxl_library"
> > > >   
> > > 
> > > Ah, good idea. I'll look into it.
> > 
> > Is it done anywhere? If not, how can I help?
> > 
> > This the above change (setting libxl log level to libvirtd global one),
> > makes almost impossible to get libxl debug, because the rest of libvirtd
> > trashes the logs (hundreds virEvent* and virObject* messages, at
> > "info"(!) level).
> 
> Presumably that's because you are using LIBVIRT_DEBUG=1 or setting
> log_debug=1 in /etc/libvirt/libvirtd.log. That is generally discouraged
> because it turns on all logging, which is essentially unusably verbose.
> 
> It is also better to use more specific log settings, eg when I debug
> the QEMU driver I usually use
> 
>   log_filters="1:qemu 1:security 3:event 3:object 1:util"
>   log_outputs="1:file:/var/log/libvirt/libvirtd.log"
> 
> This generates log messages from every source file in qemu and
> security directories, and also log messages from every file
> in the util/ directory *except* for event & object files.
> So it is much more managable to read.

Ok, I'll try with "3:event 3:object", thanks!

> The log filter strings just do a wildcard match against the
> VIR_LOG_INIT("...."); lines in each source file, so you can
> make things more or less specific as you desire.
> 
> Regards,
> Daniel

-- 
Best Regards,
Marek Marczykowski-GÃrecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: pgpU0brcyFFjK.pgp
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel