[wildfly-dev] Reading Logs from Web Console

[Brian Stansberry]

On 8/14/13 2:12 PM, James R. Perkins wrote:
>
> 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.
>>

The AS would then have to provide an SPI via which the handler could 
expose whatever is necessary. Is that SPI likely to be implemented?

This is a nice-to-have IMHO.

>> 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.

Any custom handler could have a read-only attribute that describes 
whether the viewer ops are supported. The description of the viewer ops 
clearly states that they will fail if executed if not supported.

This could be done other ways that are more complex and fussy and best 
avoided.

>>>
>>>> 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
>>>>>
>>>
>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat