[wildfly-dev] Design Proposal: Log Viewer

[Brian Stansberry]

On 6/11/14, 11:08 AM, Scott Marlow wrote:
> On 06/11/2014 11:43 AM, Stuart Douglas wrote:
>> I don't think we should be worrying about that. Management operations
>> happen under a global lock, and it is already possible to perform
>> operations that return a lot of content (e.g. reading the whole resource
>> tree).
>
> If we already have a single mutually exclusive, global lock in use for
> operations like "viewing logs", I'm less worried.
>

The mutually exclusive management lock would not typically be used for 
something like this, which is a read.

It could be misused for that, but IMO it's a misuse.

>>
>> There would need to be a *lot* of admins and a very under powered server
>> to make this a problem, and even then the solution is 'don't do that'.
>
> I've seen this "lot of admins" situation before with log viewing, which
> is why I brought it up.
>
>>
>> Stuart
>>
>> Scott Marlow wrote:
>>> On 06/11/2014 11:01 AM, James R. Perkins wrote:
>>>> 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.
>>>
>>> Would be good to have feedback on how many users are likely to
>>> concurrently view logs.  I suspect the count will be higher than we
>>> might expect (depending on which users have access for a particular
>>> deployment).
>>>
>>> One possible solution could be a
>>> http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Semaphore.html
>>>
>>> that is configured for the maximum number of users allowed to view logs
>>> concurrently.  For example, if the number of Semaphore permits is
>>> configured for five and eighty users are trying to view logs at the same
>>> time, logs will be returned for five users at a time (until all users
>>> have received their logs or a timeout occurs).
>>>
>>> There are probably other ways to deal with this as well.
>>>
>>>>>
>>>>> 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
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat