Re: [wildfly-dev] Reading Logs from Web Console

Just to add too in a domain it would be nice to have a central spot to view logs instead of having to ssh into various servers. On 08/14/2013 12:56 PM, Jason Greene wrote: > Mainly convenience. You deploy something it fails, you want to look at the log but don't feel like sshing into the server. As to performance the cost would be on request, and not more expensive then looking at the log file via ssh. > > On Aug 14, 2013, at 2:24 PM, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > >> What are the use cases for online reading of the server logs? If there >> are problems occurring on the application server (e.g. perhaps the cpu >> is pegged), reading logs online, could make the system even less >> responsive. >> >> If we just want to read the server logs as part of a health check, not >> requiring the server console to be working would be better. >> >> Should the reading of the logs instead be an external capability? >> Perhaps using the logs from the JBoss/WildFly Diagnostic Reporter output >> (archive) or some other archived copy of logs. >> >> Another compromise, add the WildFly Diagnostic Reporter (or at least the >> log collection part) to the management console (output archive is >> downloaded for local viewing). >> >> On 08/14/2013 01:03 PM, James R. Perkins wrote: >>> I had posted this to another list, but this is a more appropriate place >>> for it. I think there needs to be a general discussion around this as >>> it's been mentioned, at least to me, a few times here and there and I >>> know Heiko raised the issue some time a go now. >>> >>> The original JIRA, WFLY-280[1], is to display the last 10 error messages >>> only. To be honest I wouldn't find that very useful. To me if I'm >>> looking for logs I want to see all logs, but that's not always so easy. >>> Like the syslog-handler which doesn't log to a file so there is no way >>> to read those messages back. >>> >>> The current plan for the last 10 error messages is we store messages in >>> a queue that can be accessed via an operation. This works fine until the >>> error message you're interested in is 11 or you want to see warning >>> messages. >>> >>> Another option I had come up with is reading back the contents of the >>> file, for example the server.log. This could be problematic too in that >>> there is no way to filter information like only see error messages or >>> only see warning messages. To solve this I have considered creating a >>> JSON formatter so the results could be queried, but I don't think it >>> should be a default which would mean it's not reliable for the console >>> to assume it's getting back JSON. >>> >>> I've also thought about, haven't tested this and it may not work at all, >>> creating a handler that uses websockets to send messages. I'm not sure >>> how well this would work and it's possible it may not even work for >>> bootstrap logging. >>> >>> With regards to audit logging, we're probably going to have to do >>> something totally different from what we'll do in the logging subsystem >>> since it doesn't use standard logging. >>> >>> I guess the bottom line is what does the console want to see? Do you >>> want to see all raw text log messages? Do you want all messages but in a >>> format like JSON that you can query/filter? Do you really want only the >>> last 10 error messages only? All or none of these might be possible, but >>> I really need to understand the needs before I can explore more in depth >>> what the best option would be. >>> >>> [1]: https://issues.jboss.org/browse/WFLY-280 >>> >>> -- >>> James R. Perkins >>> Red Hat JBoss Middleware >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat >