2:49 p.m.
This sounds awfully similar to my Hawkular "audit" component I've been
prototyping :)
https://github.com/jmazzitelli/hawkular-audit
In short, its just sitting on the bus listening for audit events (these audit events can
come over JMS or through REST, such as I demoed a few weeks ago with curl on the command
line submitting an audit event) and when received, those audit events are simply stored to
a backend datastore for later retrieval by whatever we want (GUI front end, reporting
tool, etc).
----- Original Message -----
I like the concept that subsystems can provided notifications to a
central
system. I have to imagine that's going to result in more and better
warnings than if an external systems is responsible for monitoring all
subsystems and creating warnings. But it only covers use cases where the
subsystem has all the data it needs. There's still a place for a higher
order of analysis.
That central system should also provide an API for external systems rather
than just report warnings through the WF GUI.
~john
----- Original Message -----
> Interesting mail on wildfly-dev
>
> > Anfang der weitergeleiteten Nachricht:
> >
> > Datum: 5. Februar 2015 10:00:21 MEZ
> > Von: Darran Lofthouse <darran.lofthouse(a)jboss.com>
> > An: "wildfly-dev(a)lists.jboss.org"
<wildfly-dev(a)lists.jboss.org>
> > Betreff: [wildfly-dev] Administrator Encouragement
> >
> > Last week a few of us started talking about the possibility of adding a
> > capability to WildFly that for want of a better name I was calling
> > "Administrator Encouragement".
> >
> > I am not looking for this to be a design thread, that can come later but
> > the general principal was that subsystems could register warnings with
> > some kind of central service that admin tools could then retrieve later
> > to advise administrators that some configuration could be required to
> > improve their installation. Warnings would potentially have a severity
> > level and tooling would potentially have the option to guide the user to
> > the correct place to resolve the issue.
> >
> > Anyway the purpose of this thread is that I wanted to try and gather
> > together the kinds of warnings that we could be outputting, below is a
> > list of some I have thought of already but would be interested in
> > hearing any additional ideas.
> >
> > - SSL is not configured.
> > - SSL certificates are due to expire.
> > - Plain text password detected in the configuration.
> > - Some form of file based storage in use but growing beyond intended
> > size.
> > - Default node name has not been changed.
> > - Patches available but not applied, subsequent releases available.
> >
> > Anyway these are just a few ideas and interested in hearing any more.
> >
> > Regards,
> > Darran Lofthouse.
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
> Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
> Handelsregister: Amtsgericht München HRB 153243
> Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie
> Peters
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev