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 <[email protected]> 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 <[email protected]> > 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 <[email protected]>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 <[email protected]> >>> 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 <[email protected]> >>> 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 >>> >> <[email protected]> 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 >>> >>> >>> >> >>> > >>> >> >
