[Hawkular-dev] Fwd: [wildfly-dev] Administrator Encouragement

[John Mazzitelli]

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 at jboss.com>
> > > An: "wildfly-dev at lists.jboss.org" <wildfly-dev at 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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>