Hi Pierre-Luc,

I have a pull request in to fix the rotating of the catalina.out logs - I'll 
check what it's status is.

And yes, being able to view VR, CPVM and SSVM logs from mgmt. server would be 
awesome.  Some of our clients have 1000s of VRs so, some real thought needs to 
go into it...



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: Pierre-Luc Dion [mailto:pd...@cloudops.com] 
Sent: 15 April 2016 13:57
To: dev@cloudstack.apache.org
Subject: Re: [discuss] CloudStack logging

Something that could be interesting also is to remove VR and systemVMs logs 
from the cloudstack-management.log and have them into a separate files. I'm 
still not sure of those logs are traps only when there is problems, if it's the 
case it make sense to keep them in  cloudstack-management.log.

Anyhow, it might be interesting to collect VR and systemVMs logs from the 
management servers.

The log structure is also pretty stable so far which make integration with ELK 
fairly easy which is good!

What about the catalina.out? is there any way to reduce is size?

I'll update the JIRA issue with problematic troubleshooting logs that are not 
clear to interpret...

Thanks Paul for taking that one !


PL


On Fri, Apr 15, 2016 at 4:44 AM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:

> Paul,
>
> I think that asking for input is a good approach. Those that have 
> problem with a certain log message or - sequence are the best to say 
> what should be different.
>
> Whether we should make hundreds of PRs or one?.. neither. I would say 
> change anything from a big class to a small package, or get the flow 
> for one API call and change anything in that. That would be cross 
> package and may require classes in the management -, service -, 
> orchestration and resource layers to be revisited for several flows.
>
>
> On Fri, Apr 15, 2016 at 10:06 AM, Paul Angus 
> <paul.an...@shapeblue.com>
> wrote:
>
> > Great, I'll pick up the issue that Wido has already created
> > https://issues.apache.org/jira/browse/CLOUDSTACK-8645
> >
> > Does anyone have an suggestions wrt to structure of pull requests?
> > I'm inclinded to ask the community for copies of logs - particularly 
> > ones that people have found difficult to read so that I or others 
> > can work through them looking for anamolies - it's very messy from a 
> > thoroughness point of view - but it would return the most useful 
> > changes first.  It
> also
> > puts the error msg in a context to make the categorisation more acurate.
> >
> >
> >
> > 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
> >
>
>
>
> --
> Daan
>

Reply via email to