esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: Requesting feedback on JMX REST API...
Date Fri, 20 Nov 2009 17:19:03 GMT
Sounds like a good idea:  what about calling it: ESME JMX HTTP-based API

D.

On Fri, Nov 20, 2009 at 4:36 PM, Ethan Jewett <esjewett@gmail.com> wrote:
> This looks very cool! :-)
>
> I don't have much to add here, but I will reiterate what has become my
> usual request: Can we try to stick to calling these APIs "HTTP APIs"
> not "REST APIs".
>
> I want to avoid getting into another flamewar with the web about how
> the ESME team doesn't adhere to REST orthodoxy. It just isn't worth
> it.
>
> Ethan
>
> On Fri, Nov 20, 2009 at 2:01 AM, Markus Kohler <markus.kohler@gmail.com> wrote:
>> Hi all,
>> Most enterprise monitoring systems understand JMX . IIRC the issue was
>> always that the remote JMX interface was vendor specific. Not sure whether
>> that's still the case.
>> JMX is rather inefficent I think. Most enterprises use products such as
>> Wiley Introscope (defacto SAP standard) or Dynatrace.
>>
>> We should probably look what interfaces they offer. Usually the main issue
>> is to find the right instrumentation points in the code.
>>
>>
>> Regards,
>> Markus
>>
>> On Fri, Nov 20, 2009 at 5:51 AM, Richard Hirsch <hirsch.dick@gmail.com>wrote:
>>
>>> Just had another idea.
>>>
>>> @Andy: Is the pure JMX interface gone or just not active? I think it
>>> would be a interesting idea to be able to turn the real JMX interface
>>> on and off. If you can use the JMX interface (for example, behind the
>>> firewall in an on-premise installation), you turn it on. If you are in
>>> the cloud and can't use traditional JMX or don't have a use a
>>> enterprise monitoring system that understands JMX (for example, in
>>> smaller organizations), you turn it off.
>>>
>>> That way we could have the best of both worlds.
>>>
>>> Or another idea would be to offer a small component that reads the
>>> REST API and creates JMX out of it. If companies want JMX instead of
>>> REST, they could install this component. This solution might have
>>> performance probs though....
>>>
>>> D.
>>>
>>> On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hirsch.dick@gmail.com>
>>> wrote:
>>> > Posted message about SolutionManager and REST on the SDN forum:
>>> > http://forums.sdn.sap.com/thread.jspa?threadID=1536884
>>> >
>>> > D.
>>> >
>>> > On Fri, Nov 20, 2009 at 5:31 AM, 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?
>>> >>
>>> >>>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.
>>> >>
>>> >> 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.
>>> >>
>>> >> 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.
>>> >>
>>> >> 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.
>>> >>
>>> >> 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
View raw message