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> 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
>>>
>
--
James R. Perkins
Red Hat JBoss Middleware