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 >
