cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Weller <swel...@ena.com>
Subject Re: [discuss] CloudStack logging
Date Thu, 14 Apr 2016 14:18:44 GMT
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.angus@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.angus@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue

-----Original Message-----
From: Wido den Hollander [mailto:wido@widodh.nl]
Sent: 14 April 2016 15:04
To: Paul Angus <paul.angus@shapeblue.com>; dev@cloudstack.apache.org
Subject: Re: [discuss] CloudStack logging


> Op 14 april 2016 om 14:49 schreef Paul Angus <paul.angus@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.angus@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue

Mime
View raw message