Chris, >From my perspective it's *built-in* monitoring capabilities that are >critically needed, in which case embedding a technology such as JMX seems the >best approach for the instrumentation granularity required by Matterhorn >distributed architecture complexity.
In regards to SNMP, it is _usually_ the realm of appliances and Operating Systems, basically not very "friendly" to the application layer with the MIB's static approach. That said and to emphasis my point about *built-in* monitoring capabilities, many of the appliances I've dealt with and that shipped with SNMP also came with pro active monitoring capacities of their own, that's one of the many aspects that along with things like power redundancy makes them "Enterprise ready". There is a key sentence in the post about JMX vs SNMP that Tobias sent: https://blogs.oracle.com/jmxetc/entry/jmx_vs_snmp " All in all, I would say that choosing to monitor the JVM through SNMP is legitimate when: [...] -You are only interested in JVM data - not application data, and do not see any plans for this to change. [...] " This to me is key when you put it in the perspective of the OSGi specification followed by Matterhorn with the Felix framework and the multiple applications aka bundles running on top of a single JVM. J. On Mar 16, 2012, at 9:28 AM, Christopher Brooks wrote: > Right. Here's the perspective I think is common in ops groups, or at > least is in ours: > > "All in all, I would say that choosing to monitor the JVM through SNMP > is legitimate when: > > .... > > You already have at your disposal SNMP management tools or SNMP > management consoles" > > But I welcome more monitoring regardless, even if we're not likely to > use it due to tool issues. > > Chris > > >> Hi Chris, >> >> it's a valid question, however in my mind you already gave the most >> important hint with respect to that discussion, which is that SNMP is >> really designed for devices rather than applications. Read more on >> JMX vs. SNMP and why JMX makes the most sense for monitoring Java >> applications on [1]. >> >> Tobias >> >> [1] https://blogs.oracle.com/jmxetc/entry/jmx_vs_snmp >> >> On 16.03.2012, at 16:40, Christopher Brooks <[email protected]> >> wrote: >> >>> 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 >> > > > > -- > 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] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
