[wildfly-dev] Reading Logs from Web Console

Wed Aug 14 15:12:37 EDT 2013

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 at redhat.com> 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 at 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
>>>>
>>
>

-- 
James R. Perkins
Red Hat JBoss Middleware