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.

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

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

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

I am not sure I fully understand the design proposal. Is it correct to say that it basically consists of two things? a) format for structured log data b) an additional logging service to that adopts unstructured (default) log messages to a)

/Heiko On 11 Jun 2014, at 01:33, James R. Perkins <jperkins(a)redhat.com&gt; 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. > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 11 Jun 2014, at 00:33, James R. Perkins <jperkins(a)redhat.com&gt; 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. Something similar to what you say for the logging subsystem could probably be done to configure and write out formatted data, so there might be an opportunity for some code sharing. However, audit logging has extra security concerns. This should only be possible to view for AUDITOR or SUPERUSER. Another, possibly more important, issue is that while we do have a file handler for audit logging, I expect that anybody who takes security seriously will configure audit logging to use the syslog handler. Then writing a copy of the audit log to a local file becomes a security risk. I see you mention the metrics stuff Heiko talked about in your introduction, so if the intent is to use that to write the audit log records, that might be better (although I am not familiar with how security will be handled there)

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

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