incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy the destroyer <andythedestro...@gmail.com>
Subject Re: Requesting feedback on JMX REST API...
Date Fri, 20 Nov 2009 19:49:34 GMT
Thanks for the feedback! Responses below.
Andy

On Thu, Nov 19, 2009 at 8:31 PM, Richard Hirsch <hirsch.dick@gmail.com>wrote:

> Looks great.
>
> >>There is no security on the api. This obviously should not stay like this
> and should only be accessable with an administrator >>account.
>
> You are probably correct about the necessity of authorization added to
> the interface but this might just be necessary for those interfaces
> that write / change settings, What about using the lift authorization
> mechanism here to distinguish it from the ESME user base?
>
>
I haven't played with lift authorization yet. I am not sure how it works. I
know to adhere to being RESTful we should use WWW-Authenticate. I don't know
if lift supports this I will look into it. I so far left security as an
after thought while I nail down the api.


> >It is worth thinking about switching to a property api like Configgy which
> uses mutable data structures for properties.
>


> This is a good idea. First we must determine which properties might be

 useful to be to change on the fly. I once started a list of such

properties in the wiki. I'll finish it and publish the link.
>

Cool.



>  I really like the fact that JMX data is available via REST. I started
> looking and found there is a a related JSR 262, Web Services Connector
> for JMX Agents where the author examined rest-based access
> (
> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
> ).
>  The author has some interesting ideas (for example, creating an Ajax
> based application to follow the JMX changes), I also found a very old
> Google Code project that looked at this topic
> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the author
> mentions using Cacti (Cacti is a complete network graphing solution:
> http://www.cacti.net/) to graph the material. Maybe we could try and
> use Cacti as well to graph our data.
>

Yes, I also saw that project. We should be able to try Cacti. I can see if I
still remember all the horrible PHP coding I did for years. ( Cacti is in
PHP )


> So you could probably create a very cool administration application
> for ESME (written in whatever language you want) that allows you to
> monitor everything in ESME. What I'd like to see is a very basic admin
> app (maybe separate from ESME). Creating more complicated admin apps
> would then be a business opportunity for someone.
>
> What we have to look at as well is how to deal with those enterprises
> that already have monitoring environments in place (for example,
> SolMan).  I don't know if such applications can deal with REST. I'll
> do some research here.
>

It could be used to integrate a third party monitoring system with ESME in a
cloud env.



>  So, in my opinion, it looks v. cool. Send me a patch and I'll commit

 it.  Once we get the foundation up and running, we should talk about

what other measures we want to monitor.
>

I should have some time this weekend to work in the suggestions from this
email thread and I will send a patch when I finish.

Thanks again for the input.
-A


>
> Thanks.
>
> D.
>
> On Fri, Nov 20, 2009 at 3:55 AM, Andy the destroyer
> <andythedestroyer@gmail.com> wrote:
> > FYI & RFC
> >
> > I have finished a REST api for generic jmx MBeans. It allows for listing
> > mbeans, getting mbeaninfo, reading and setting attributes and invoking
> > operations with parameters that can be represented as Strings ( i.e.
> String,
> > Long etc. serialized classes don't count).
> >
> > Before I send to code to Richard I would like some feedback to see if I
> am
> > missing something or should do something different.
> >
> > Here is the api and sample returns. Bad requests or errors will return
> > BadResponse.
> >
> > GET /jmx/mbeans - returns a list of mbean names
> > GET /jmx/mbean/[mbean name]/info - returns MBeanInfo for specified mbean
> > GET /jmx/mbean/[mbean name]/attributes - returns attribute name and
> string
> > values
> >
> > POST /jmx/mbean/[mbean name]/invoke/[operation name]
> > <Params>
> >  <Param>pone</Param>
> >  <Param signature="java.lang.Long">123</Param>
> > </Params>
> >
> > POST /jmx/mbean/[mbean name/set - sets a single attribute
> > <Attribute name="attr" value="val" />
> >
> > POST /jmx/mbean/[mbean name]/set - sets multiple attributes
> > <AttributeList>
> >  <Attribute name="att1" value="val1" />
> >  <Attrubute name="att2" value="val2" />
> > </AttributeList>
> >
> > == SAMPLES ==
> >
> > GET /jmx/mbeans
> >
> > <esme_api operation="mbeans" success="true">
> > <MBeans>
> > <MBean name="java.lang:type=Memory"/>
> > <MBean name="java.lang:type=GarbageCollector,name=Copy"/>
> > <MBean name="java.lang:type=MemoryPool,name=Code Cache"/>
> > <MBean name="java.lang:type=Runtime"/>
> > <MBean name="java.lang:type=ClassLoading"/>
> > <MBean name="java.lang:type=MemoryPool,name=Perm Gen [shared-rw]"/>
> > <MBean name="java.lang:type=Threading"/>
> > <MBean name="java.util.logging:type=Logging"/>
> > <MBean name="java.lang:type=MemoryPool,name=Perm Gen [shared-ro]"/>
> > <MBean name="java.lang:type=Compilation"/>
> > <MBean name="java.lang:type=MemoryPool,name=Eden Space"/>
> > <MBean name="org.apache.esme.stats:type=Stats"/>
> > <MBean name="StatsAgent:name=htmlAdaptor,port=9092"/>
> > <MBean name="com.sun.management:type=HotSpotDiagnostic"/>
> > <MBean name="java.lang:type=GarbageCollector,name=MarkSweepCompact"/>
> > <MBean name="java.lang:type=MemoryPool,name=Survivor Space"/>
> > <MBean name="java.lang:type=MemoryPool,name=Tenured Gen"/>
> > <MBean name="java.lang:type=MemoryPool,name=Perm Gen"/>
> > <MBean name="java.lang:type=OperatingSystem"/>
> > <MBean name="JMImplementation:type=MBeanServerDelegate"/>
> > <MBean name="java.lang:type=MemoryManager,name=CodeCacheManager"/>
> > </MBeans>
> > </esme_api>
> >
> > GET /jmx/mbean/org.apache.esme.stats:type=Stats/attributes
> > <esme_api operation="mbean" success="true">
> > <MBeanAttributes name="org.apache.esme.stats:type=Stats">
> > <MBeanAttribute value="1" name="counter_userCount"/>
> > <MBeanAttribute value="1" name="counter_liftSessions"/>
> > <MBeanAttribute value="1.0" name="gauge_users"/>
> > <MBeanAttribute value="1.0" name="gauge_listener"/>
> > </MBeanAttributes>
> > </esme_api>
> >
> > GET /jmx/mbean/org.apache.esme.stats:type=Stats/info
> > <esme_api operation="mbean" success="true">
> > <MBeanInfo name="org.apache.esme.stats:type=Stats">
> > <MBeanAttributes>
> > <MBeanAttributeInfo isIs="false" type="java.lang.Long"
> description="counter"
> > isReadable="true" name="counter_userCount" isWritable="false"/>
> > <MBeanAttributeInfo isIs="false" type="java.lang.Long"
> description="counter"
> > isReadable="true" name="counter_liftSessions" isWritable="false"/>
> > <MBeanAttributeInfo isIs="false" type="java.lang.Long"
> description="gauge"
> > isReadable="true" name="gauge_users" isWritable="false"/>
> > <MBeanAttributeInfo isIs="false" type="java.lang.Long"
> description="gauge"
> > isReadable="true" name="gauge_listener" isWritable="false"/>
> > </MBeanAttributes>
> > <MBeanOperations>
> > <MBeanOperationInfo impact="ACTION" description="Remove all Counters,
> > Timers, Gauges and restart gathering timestamp."
> > returnType="java.lang.String" name="clear">
> > <Signature>
> > </Signature>
> > </MBeanOperationInfo>
> > </MBeanOperations>
> > <MBeanNotifications/>
> > </MBeanInfo>
> > </esme_api>
> >
> > =================
> >
> > There is no security on the api. This obviously should not stay like this
> > and should only be accessable with an administrator account.
> >
> > I tested it with the Stats MBean and the java.util.Logging MBean and it
> is
> > working. I can access stats, reset them and change logging levels.
> >
> > It would be nice to be able to change runtime properties though JMX
> however
> > most of the Lift and ESME code uses vals and immutable data structures
> that
> > are set when the app is originally loaded. The lift Props object used by
> > esme is totally immutable after it is constructed. It is worth thinking
> > about switching to a property api like Configgy which uses mutable data
> > structures for properties.
> >
> > We could change in real time things like resent & links period, refresh
> > intervals, analyzer settings like long query time, db connection pool
> sizes
> > etc.
> >
> > I didn't enable sending serialized objects through the REST api because
> it
> > seems like more trouble than it's worth. Besides that sort of JMX
> > functionality is only useful between servers and this api is really just
> for
> > the cloud environment like stax which doesn't allow you to bind to ports.
> >
> > I welcome any comments or suggestions of Stats or JMX features to add
> before
> > I send the code to Richard. Should invalid requests return specific error
> > messages or just BadResponse?
> >
> > Thanks,
> > Andy
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message