On 14/11/13 16:40, Juliana Leal wrote:
> To fix the JBoss crash issue (JBoss crashes when run with AspectJ java
> agent -https://issues.jboss.org/browse/WFLY-895) I commented out the
> logging in jmxetric, and re-exported the .jar. After this, JBoss ran
> with jmxetric as java agent without a hitch. In addition to this, once
> these changes were made (the logging having been commented out) the
> missing subtree in jconsole issue was also fixed (jboss.as
> <http://jboss.as> MBean subtree missing when profiling agent used -
> https://issues.jboss.org/browse/WFLY-840), and the jboss.as
> <http://jboss.as> subtree became visible again.
>
> I also added a rate calculation functionality to JMXetric (as only
> gauge/count were available.
> Summing up what I did: I added two attributes to MBeanAttribute: int
> interval and long time. The interval attribute will be in the xml and
> is read in and added to each Attribute/Composite in XML configuration
> service. Basically, anything other than 0 will be considered a rate. I
> did this because I intend to implement a method that will calculate
> the rates according to the interval given. Currently the rate is
> calculated based only on milliseconds; I'd like to further work on
> this so that the rate can be also calculated based on seconds or minutes.
>
> I created a simple class MBeanRate (in MBeanSampler) which contains a
> timestamp and a value attribute. I then modified the MBeanHolder so
> that it keeps a hash map of these MBeanRate objects, the key being the
> attribute's canonical name. So whenever an attribute is read, it will
> check if it exists in the hash map; if this attribute is new, it's
> simply added in: If not, a comparison is made with the past value/time
> and current values/times, and the calculated value is published and
> the read time is inserted in the time attribute in MBeanSampler (and
> the hashmap is updated). As the value is given as an object, I took
> the necessary precautions to read in String, Int, Long, Double and
> Float value objects (note: with String I simply return the String, no
> calculations performed and System.out a warning message), as well as
> other issues that may come up, such as two same ratings, division by
> zero, etc. These methods are contained in a new class named
> ObjectUtils. I created some JUnit tests as well for problematic rates
> (example: String values, repeated metric values - so there isn't a
> division by zero, or zero polling interval).
>
> These changes are in my jmxetric/logbranch in Github
> (https://github.com/JLouback/jmxetric). Do let me know if anything is
> still unclear or incorrectly implemented.
Thanks for these contributions to Ganglia, we will test them out and
hopefully incorporate them in the next jmxetric and gmetric4j releases
Is anybody else able to provide feedback on this? In particular:
- should we go for some other logging mechanism or just leave it
commented out for now? (see the JBoss bug report for details)
- the conversion of JMX counters to rates: this can also be achieved
with slope="positive" (so that rrdtool uses the counter mode), however,
I believe that depends on specific rollover behavior. Juliana's
solution, calculating rates within the jmxetric agent may be more
reliable for arbitrary counters. Can anybody comment on that?
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Ganglia-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-general
