Hi Tobias, I think more monitoring is great, and I think JMX is a possible way to go. I would like to argue for abstraction, e.g. to create some code in the kernel that does the monitoring so that we aren't limited to JMX if we don't need to be. I'd like to hear a discussion of why not SNMP instead - lots of vendors might be looking to get tighter integration, and SNMP seems to be the way to go for embedded devices. Further, the toolsets for SNMP are much better known to tech engineers and ops folks than JMX tools, unless the institution runs alot of Java.
Here's a library: http://www.snmp4j.org/ I'm not against JMX of course, but if you're looking for preferences I would consider SNMP. Chris > Hi all, > > those of you who have heard Jaime advocate for improved monitoring > capabilities of Matterhorn have probably been convinced that this is > an area where immediate action is due. And those running Matterhorn > in production will probably agree that even though monitoring can be > done using the REST endpoingt, having better means of accessing > Matterhorn metrics might be a good thing. > > Christoph and I have been looking into the technologies used > throughout the field and have come to the conclusion that there are a > couple of possible approaches, but the one that really stands out is > using the Java Management Extension (JMX) [1]. So what is JMX? This > was found on the Oracle blog [3]: > > "To make it short, JMX is a technology that lets you > implement management interfaces for Java applications. > > A management interface, as defined by JMX, is composed of > named objects - called MBeans (Management Beans). MBeans are > registered with a name (an ObjectName) in an MBeanServer. To manage > (a) resource(s) in your application, you will write an MBean that > defines its management interface, and then register that MBean in > your MBeanServer. The content of the MBeanServer can then be exposed > through various protocols, implemented by protocol connectors, or > protocol adaptors. > > A protocol connector (e.g. the JMX RMI Connector) exposes the > MBeans as they are - so a remote client sees the same model than a > local client. A protocol adaptor (e.g. an SNMP adaptor, or HTML > adaptor) performs (or provides hooks to let you perform) a model > mediation - to adapt the model to what a client of that protocol > (e.g. SNMP Manager, or Web Browser) would expect to see." > > People tcan then start building their monitoring needs ontop of the > JMX architecture, which allows for quite a bit of flexibility with > the number of open and commercial tools out there that support the > JMX standard. > > So our #proposal is to start adding JMX support to Matterhorn and I > would like to get feedback and/or +/- ones on this suggested approach. > > Tobias > > [1] > http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html > [2] http://openjdk.java.net/tools/svc/jconsole/ [3] > https://blogs.oracle.com/jmxetc/entry/what_is_jmx > _______________________________________________ Matterhorn mailing > list [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ -- Christopher Brooks, BSc, MSc ARIES Laboratory, University of Saskatchewan Web: http://www.cs.usask.ca/~cab938 Phone: 1.306.966.1442 Mail: Advanced Research in Intelligent Educational Systems Laboratory Department of Computer Science University of Saskatchewan 176 Thorvaldson Building 110 Science Place Saskatoon, SK S7N 5C9 _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
