8:24 a.m.
On 6/10/2014 7:33 PM, James R. Perkins wrote:
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.
The problem I see here is that we are designing something
based on what
we think a log viewer might want.
Personally, I've yet to see a log viewer that works better than a text
editor. I sure hope we don't get bogged down writing our own viewer.
IMHO, what James has given us already is pretty close to what we need.
If you look at the latest CLI GUI you will find that it now includes the
ability to download logs and, if desired, load them into your own log
viewer. Works pretty well.
https://community.jboss.org/wiki/AGUIForTheCommandLineInterface#log-download
Beyond having that same functionality in the web console, what else does
a user need?
The file must be defined as a known file handler.
IMHO,
solving this would indeed be a good enhancement.
There is
also no way to filter results, e.g. errors only.
IMHO, solving this is NOT a good
enhancement. Filtering should be left
to the user's log viewer on the client side.
If per-deployment
logging is used, those log messages are not viewable as the files are
not accessible.
IMHO, solving this would be a good enhancement. Give the app
developer
a way to have his log downloaded from a management operation.
IMHO, everything below adds lots of complexity and potentially slows
down the server. Simple downloading of logs is what the user really wants.
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.