Re: [wildfly-dev] Design Proposal: Log Viewer

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.

> > 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev