[wildfly-dev] Design Proposal: Log Viewer

[James R. Perkins]

On 06/10/2014 06:53 PM, Scott Marlow wrote:
> Any concern about the number of users viewing the server logs at the
> same time and the impact that could have on a system under load?  For
> example, if a bunch of users arrive at work around the same time and
> they are all curious about how things went last night.  They all could
> make a request to show the last 1000 lines of the server.log file (which
> could peg the CPU).  You might ask why a large number of users have
> access to view the logs but the problem is still worth considering.
Actually it's not something I've thought of. Though I suppose this could 
be an issue with any operation that returns large results.
>
>
> On 06/10/2014 07:33 PM, James R. Perkins wrote:
>> While there wasn't a huge talk about this at the Brno meeting I know
>> Heiko brought it up as part of the extended metrics. It's on some future
>> product road maps as well too. I figured I might as well bring it up
>> here and get opinions on it.
>>
>> This design proposal covers how capturing log messages. The "viewer"
>> will likely be an operation that returns an object list of log record
>> details. The design of how a GUI view would look/work is beyond the
>> scope of this proposal.
>>
>> There is currently an operation to view a log file. This has several
>> limitations. The file must be defined as a known file handler. There is
>> also no way to filter results, e.g. errors only. If per-deployment
>> logging is used, those log messages are not viewable as the files are
>> not accessible.
>>
>> For the list of requirements I'm going to be lazy and just give the link
>> the wiki page https://community.jboss.org/wiki/LogViewerDesign.
>>
>> Implementation:
>>
>> 1) There will be a new resource on the logging subsystem resource that
>> can be enabled or disabled, currently called log-collector. Probably
>> some attributes, but I'm not sure what will need to be configurable at
>> this point. This will likely act like a handler and be assignable only
>> to loggers and not the async-handler.
>>
>> 2) If a deployment uses per-deployment logging then a separate
>> log-collector will need to be added to the deployments log context
>>
>> 3) Logging profiles will also have their own log-collector.
>>
>> 4) The messages should be written asynchronously and to a file in some
>> kind of formatted structure. The structure will likely be JSON.
>>
>> 5) An operation to query the messages will need to be create. This
>> operation should allow the results to be filtered on various fields as
>> well as limit the data set returned and allow for a starting position.
>>
>> 6) All operations associated with view the log should use RBAC to
>> control the access.
>>
>> 7) Audit logs will eventually need to be viewable and queryable. This
>> might be separate from the logging subsystem as it is now, but it will
>> need to be done.
>>
>>
>> There are things like how long or how many records should we keep that
>> needs to be determined. This could possibly be configurable via
>> attributes on the resource.
>>
>> This is about all I've got at this point. I'd appreciate any feedback.
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
JBoss by Red Hat