Really agree with this one. With a toolchain like ELK, it isn't as bad
because you can filter out the things you don't want, but generally
speaking, the log levels need to be reevaluated. I would also add that many
log statements would benefit from additional context, but that is a whole
different story.
Another example:
INFO [com.cloud.agent.transport.Request] (StatsCollector-3:ctx-de473a88)
not building log message for '[{}]', _cmds.length == 1
It even says "not building log message".
On Thu, Apr 14, 2016 at 10:18 AM, Simon Weller <swel...@ena.com> wrote:
> I'm all for this as well.
>
> Training our systems folks on how to work through the logs is a pain.
> Focusing in on the most important items is more useful and also makes it
> easier to automate log fetching and categorization.
>
> - Si
>
> ________________________________________
> From: Paul Angus <paul.an...@shapeblue.com>
> Sent: Thursday, April 14, 2016 9:06 AM
> To: Wido den Hollander; dev@cloudstack.apache.org
> Subject: RE: [discuss] CloudStack logging
>
> Grabbing a couple of examples - these should be debug - I can't 'do'
> anything with this information.
>
> INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-4119d5bc) Begin cleanup expired async-jobs
> INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-4119d5bc) End cleanup expired async-jobs
> INFO [c.c.h.v.r.VmwareResource] (DirectAgentCronJob-2:ctx-3209f65c) Scan
> hung worker VM to recycle
> INFO [c.c.h.v.r.VmwareResource] (DirectAgentCronJob-113:ctx-56d9f9f2)
> Scan hung worker VM to recycle
>
> Whereas this should be WARN. I wouldn't want to lose this by switching off
> DEBUG
>
> DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-91226be7)
> Detected management node left, id:2, nodeIP:10.2.0.6
> DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-0bccd078)
> Detected management node left, id:2, nodeIP:10.2.0.6
>
>
>
> Kind regards,
>
> Paul Angus
>
> Regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
> -----Original Message-----
> From: Wido den Hollander [mailto:w...@widodh.nl]
> Sent: 14 April 2016 15:04
> To: Paul Angus <paul.an...@shapeblue.com>; dev@cloudstack.apache.org
> Subject: Re: [discuss] CloudStack logging
>
>
> > Op 14 april 2016 om 14:49 schreef Paul Angus <paul.an...@shapeblue.com>:
> >
> >
> > Hi All
> >
> > I think that we can all agree that CloudStack logs are very difficult
> > to read, especially for operational staff.
> >
> > I believe that the primary reason for this is that a large amount of
> > what should be INFO level events are categorised as DEBUG. The
> > logging therefore must be set at DEBUG for the logs to capture these
> > events. By defaulting the logging to DEBUG we include a lot of detail
> > which is counter-productive when using the logs to diagnose operational
> issues.
> >
>
> Yes!
>
> > I think the situation can be greatly improved by reviewing the
> > categorisation of logged events and where necessary re-categorise then
> > such that INFO, WARN and ERROR logging would be sufficient for an
> 'operational' admin.
> >
> > I think a phased approach where the default logging level remains at
> > DEBUG while re-categorisation occurs would mean that nothing
> > materially changes until we are happy with the categorisations. Then
> > we can default the logging level to INFO.
> >
>
> I created a issue for this a while ago:
> https://issues.apache.org/jira/browse/CLOUDSTACK-8645
>
> Short: Yes. Just change this where needed.
>
> Wido
>
> >
> >
> > Thoughts everyone?
> >
> >
> >
> >
> > Kind regards,
> >
> > Paul Angus
> >
> >
> > Regards,
> >
> > Paul Angus
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
>
