Hi, Ok, I can see you dont like the concept. I'll abandon it and use JMX beans in each bundle where appropriate, which for anyone deploying in a cluster to be monitored will require local monitoring scripts like OmniTI's Jezebel, Munins JMX plugin or Splunks JMX plugin.
BTW the idea for the approach (central monitoring simple counters and values delivered over http rather than JMX) comes from the Resmon protocol used bu OmniTI as the native protocol for Reconnoiter. If you are interested you can read goals of that system[1] or the a rant[2], which is a bit at the extreem end of the spectrum, and its probably valid to say not relevant for Sling. BTW2: I dont want to reinvent Reconnoiter or exclusively bind to it, bit I would have like to feed it and its competitors efficiently with minimal impact or OS level configuration on each deployed instance. Best Regards Ian 1 http://labs.omniti.com/labs/reconnoiter/wiki/Goals 2 http://lethargy.org/~jesus/writes/reconnoiter-and-another-platform On 1 March 2013 18:51, Felix Meschberger <fmesc...@adobe.com> wrote: > Hi > > I really appreciate this discussion. But I would like to get to a point where > we create a proper future-proof (as much as possible) architecture which > properly integrates with the current situation: > > * JMX is the system of choice for systems management > * The Web Console is the respective system of choice > for web based interactive tooling > * Don't reinvent wheels > > I would really like to highlight the last point: I would prefer to reuse > existing functionality and libraries as much as possible instead of > reinventing our own stuff using yet another channel. > > Regards > Felix > > Am 22.02.2013 um 23:59 schrieb Ian Boston: > >> Hi, >> Whilst writing the MBeans in the event bundle I started thinking about >> monitoring inside Sling. IMHO there are not enough to really know what >> a instance under load is doing. Much though I like JMX it comes with >> implementation and runtime overhead which I don't much like. >> >> Runtime: >> * Running with JMX enabled doesn't add any overhead, but once a client >> is connected there is some (some reports upto 3% of resources). >> * You have to remember to enable it, and most of the time JVMs are not >> enabled. By the time you really need it, its often too late. >> * JMX is not restful. >> >> Implementation >> * MBeans are not that hard to implement with the OSGi Whiteboard, but >> they have to be implemented. >> >> Alternatives. >> In Jackarabbit there is/was a statistics class [1], which IIUC uses >> counters and time series stored in a map. The service can then be >> queries to extract the values by wrapping in an MBean or Servlet. >> >> I think the approach could be generalised and extended so that >> anything in the container could use the service to record metrics. The >> api might look something like >> >> public interface Statistics { >> >> /** >> * Increment a counter by 1 >> */ >> void increment(String counterName); >> >> /** >> * Record a double value in a timeseries. >> */ >> void record(String timeSeriesName, double value); >> >> /** >> * Record a long value in a timeseries. >> */ >> void record(String timeSeriesName, long value); >> >> } >> >> and (so that any reference can be optional on a service >> implementation, the final is a hint to hotspot to inline) >> >> public final class StatisticsUtils { >> >> private StatisticsUtils() { >> } >> >> public static void increment(Statistics statistics, String counterName) { >> if ( statistics != null ) { >> statistics.increment(counterName); >> } >> } >> >> ... etc for the other methods .. >> } >> >> >> >> >> The service would need to deal with all the implementation details >> (including concurrency and speed). The service implementation would >> also come with a servlet endpoint (under /system/*) and/or single JMX >> MBean. >> >> Anything that wanted to record stats would then bind to the service >> and use it. I think this would avoid the issues mentioned above with >> wide scale MBean usage. >> >> WDYT? >> >> (apologies for the noise if this already exists, and if so, please >> treat it as a question: where and how do we record stats?) >> >> Ian >> >> >> >> >> 1 http://wiki.apache.org/jackrabbit/Statistics > > > -- > Felix Meschberger | Principal Scientist | Adobe > > > > > > >
