[wildfly-dev] Design Proposal: Log Viewer

[James R. Perkins]

On 06/11/2014 06:24 AM, Stan Silvert wrote:
> 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.
Though I haven't used it logstash (http://logstash.net/) looks quite 
nice. I'm not sure we need to fully mimic it, but it seems like we want 
a lot of the functionality from it.
>
> 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 problem is it's pretty limited. It doesn't support log files that 
may have been created via per-deployment logging where the deployment 
includes it's own logging configuration. It has to make assumptions that 
the line terminator is either LF or CRLF. The file has to be located in 
the jboss.server.log.dir directory as well. If you don't store your log 
files in that directory, you can't read them.
>>    The file must be defined as a known file handler.
> IMHO, solving this would indeed be a good enhancement.
This part is already done. Only files defined as a file-handler, 
periodic-rotating-file-handler or size-rotating-file-handler can be 
used. The problem is if you need extra functionality and you use a 
custom-handler you can't read the log file.
>> 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.
This part is a tough one. I do agree filter can be done on the client 
side, but that could result in large result sets being returned just to 
get a few messages.
>> 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.
The question is how? We can maybe make some guesses if they use a JBoss 
Log Manager configuration. Though it's more common they use log4j with 
some specific handlers they have created. I can't think of a good way to 
determine which files should be allowed or not.

Also opening up the allowed files to be outside the jboss.server.log.dir 
opens up security concerns. I mean I could just create a file handler 
with a path of say ${user.home}/.ssh/id_rsa and read the private key of 
whatever server it's running on :)
>
> 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.
>>
> _______________________________________________
> 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