4:57 p.m.
On 06/11/2014 12:26 AM, Heiko Braun wrote:
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)
For A, yes. It will just use a formatter that will likely be set on a
file handler.
For B, kind of. Essentially a service that will read and optionally
filter log messages and return a collection of results. From the console
standpoint it would just be an operation you would execute to get
results to display. Of course since this is mainly for the web console
any input you have to make it easier for you guys would be great :)
/Heiko
On 11 Jun 2014, at 01:33, James R. Perkins <jperkins(a)redhat.com> 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
--
James R. Perkins
JBoss by Red Hat