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

On 08/14/2013 12:01 PM, James R. Perkins wrote: > > On 08/14/2013 11:45 AM, Brian Stansberry wrote: >> On 8/14/13 12:55 PM, James R. Perkins wrote: >>> That's my thinking too. The only complaint I've had about that solution >>> is that it can't be filtered since it's just raw text. I had a working >>> example operation that just took a file name and the number of bytes to >>> read. To me this is the best solution, but it wouldn't have access to >>> anything in a syslog or the console. Though that's okay IMO since they >>> likely have other viewers for those. >>> >>> I'll resurrect that example. It shouldn't take all that long. One thing >>> to note is it will only allow files to be read that are in the >>> jboss.server.log.dir (and possibly only files that end in *.log?). >>> >> That's only true if the viewer operation is not associated with a >> management resource that maps to the log file (i.e. the appender >> resource). >> >> I think it's a mistake to create any kind of viewer that can serve an >> arbitrary file. >> >> For cases of serving previous versions of the file (i.e. ones before the >> current with any kind of rolling appender) the API can expose a param >> that allows the desired file to be chosen but only from a set of files >> that the management resource knows it created. > The only reason I thought of limiting it to the jboss.server.log.dir > was there is no real way to know what handlers are file handlers. For > example a custom-handler could be a file handler, but there is no real > way to know that. Those files should be allowed to viewed, IMO, as well. >

> On the other hand I do agree there is an issue with being able to read > arbitrary files. A good example would be if the logs are placed in > /var/log/ we don't want to allow access to any of the log files not > created by WildFly. > > I guess what we could do, at least to start, is just add a read-log > operation only to file handlers. Then we could just get the file name > from the resource. Further down maybe we could add an attribute to the > custom-handler to enable the operation. Just thought of one possible issue here is how would the web console know which handlers have the operation.

>> >>> So in general I agree here, I think this is the best, the least >>> invasive >>> approach and the lowest performance hit. >>> >>> On 08/14/2013 10:36 AM, Jason Greene wrote: >>>> IMO the best solution is a management operation that simply >>>> displays portions of the log file. The dependency on the log file >>>> is IMO not a problem because we support multiple appenders. >>>> >>>> On Aug 14, 2013, at 12:03 PM, James R. Perkins >>>> <jperkins(a)redhat.com&gt; 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 >>>> -- >>>> Jason T. Greene >>>> WildFly Lead / JBoss EAP Platform Architect >>>> JBoss, a division of Red Hat >>>> >> >