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

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