[wildfly-dev] Design Proposal: Log Viewer

James R. Perkins jperkins at redhat.com
Tue Jun 10 19:33:09 EDT 2014


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.

-- 
James R. Perkins
JBoss by Red Hat



More information about the wildfly-dev mailing list