cool On 6 May 2010 17:01, David Blevins <[email protected]> wrote:
> > On Mar 4, 2010, at 12:41 PM, David Blevins wrote: > > > Started looking into how we might finally get some Monitoring support > into the code. Basic stats and the like viewable via JMX or something > similar. > > > > Still very much in the research phase of all that. If anyone has done > any work in that area, I'm interested in some tips. Or if anyone has been > on the "user" side of consuming stats and has some "loves" and "hates" to > share, that's also great info -- hopefully our impl would stick close to the > loves and steer clear of the hates. > > > > And of course, if there are specific stats that anyone would like, > definitely feel encouraged to speak up. No reason we can't put those higher > in the priority list. > > Been back at this one the last two weeks. Have some pretty neat code in so > far. > > I started with a copy of Martin Traverso's (an Apache guy) tiny jmxutil > code which scans objects for @Managed annotated methods and creates a > ModelMBean based on those methods. The more I started writing actual stats > though, the less I liked the ModelMBean approach as it can only handle > methods which then requires a lot of pointless getters just for the JMX > tooling. ModelMBeans are also pretty rigid in that one object == one mbean, > so it isn't possible to "roll up" attributes in to one basic MBean if those > attributes are methods of different java objects. > > I'm not a fan of having internal code structure exposed to users when in > most cases it doesn't benefit them and simply subjects them to more brittle > finer views: do users care that in my Pool object I have a "stats" object > and in that object there are other "stats" objects and do they really need > an individual MBean for each and every one of these fine grained objects? > No, of course not. What makes my life easy as a developer, doesn't always > make their lives easy as a user. > > Anyway, so I wrote my own little annotation based JMX exporter. You pass > in an object that has fields and/or methods annotated with @Managed. It > will inspect all those fields/methods and if any of them are types that also > are marked @Managed, it will walk down those types and collect its > fields/methods. So it's a basic recursive tree walk, starting with the root > object, that rolls up everything it finds as one flat list of JMX > attributes. It also allows these fields/methods to be private in scope, so > it isn't necessary to "dirty" your design to get complete stats. > > The result is something exposes a nice clean view like this one: > > > https://issues.apache.org/jira/secure/attachment/12443866/jmx-monitoring.png > > That's the view of our stateless pool stats via JConsole. > > Still have a few "wires" to hookup, but it's looking good. Next part will > be getting stats for each method invocation on a bean. > > Comments welcome! :) > > > -David > > > >
