tag:blogger.com,1999:blog-2706354115794218976.post7316815267543000462..comments2010-08-20T12:38:10.538+01:00Comments on Ramble On: Data Aggregation via JMX and the GridSteve Colwillhttp://www.blogger.com/profile/16672227763380053864noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-2706354115794218976.post-65794080651413986182008-12-01T10:30:00.000+00:002008-12-01T10:30:00.000+00:00WilliamNot quite sure what point you are making. A...William<BR/><BR/>Not quite sure what point you are making. Are there other valid approaches/architectures to solve the problem? Sure.<BR/><BR/>If you replace the word "database" with "space" in your description, I'm not sure you are saying anything very different to what I'm proposing. Aggregation of data surely requires some consolidation somewhere. I'm suggesting using a space as a point of consolidation for higher-level aggregated reporting into JMX-enabled consoles.<BR/><BR/>Of course, depending on the resolution/latency of you basic measurements you should also consider some level of aggregation at the original source. The space plays a role in defining a rendezvous point within the grid for higher level aggregations.<BR/><BR/>You'll note a say "a space" rather than "the space". I didn't mean to imply in the original post that you'd necessarily use the main application space as the destination for monitoring data.<BR/><BR/>cheers<BR/><BR/>SteveSteve Colwillhttps://www.blogger.com/profile/16672227763380053864noreply@blogger.comtag:blogger.com,1999:blog-2706354115794218976.post-65069151326931538142008-11-28T21:13:00.000+00:002008-11-28T21:13:00.000+00:00Hi Steve,We are able to aggregate statistics acros...Hi Steve,<BR/><BR/>We are able to aggregate statistics across threads, processes, and hosts are we do not use JMX or JavaSpaces or a data grid. <BR/><BR/>Most importantly we can aggregate (merge|collate|combine) from multiple contexts which do not necessarily have to represent the complete population of nodes in the grid/cluster/cloud. <BR/><BR/>This does not need to be done in the middleware itself (certainly not from a trigger other than a click) but from a users management model because each of our monitoring agents maintains a database that inherently supports merging (aggregation) with other agent databases pulled into the management console monitoring the model.<BR/><BR/>I find this approach much better because it also affords us the ability to merge models in offline mode which is very useful when dealing with disconnected agents (no central management server required).<BR/><BR/>By the way we do also support the publication of our metering data to JMX even JMX frameworks that are grid enabled.<BR/><BR/>Kind regards,<BR/><BR/>WilliamUnknownhttps://www.blogger.com/profile/00414063535114178838noreply@blogger.com