Monday Oct 19, 2009

SNMP != JMX

This is a general comparison of SNMP with JMX as monitoring and management technologies.  It will be most useful for those used to one world and confronted by the other or those new to the management world.  For specific information on MIBs or JMX you must seek elsewhere.

SNMP and JMX are both technologies for facillitating the mangement and monitoring of hardware and software systems. They both facillitate the reading and writing of data (snmp: get/set packets, jmx: getter/setter methods). They both allow messages to be sent to other management components (snmp: traps, jmx: notifications). JMX, because of it's object oriented nature (see below) more naturally accomodates the notion of invoking methods remotely to trigger management actions.

JMX is the standard API for managing applications in Java it's part of the J2SE platform (J2SE 5.0 and later). JMX is defined by JSR 3. The definition of Connector mechanisms which allow remote access are defined elsewhere eg. JMX Remote is JSR 160. SNMP is defined by a bunch of RFCs.

Some comparison points

  • SNMP: (+) classes, libraries and tool kits exist for C and Java.
  • JMX: (-) Limited support for native C products.
  • SNMP: (+/-) Fixed access protocol (SNMPv1,v2,v3)
  • JMX: (+/-) Various transports can be used (JMX Connectors)
  • SNMP: (-) Fixed relational model for representing data (table based).
  • JMX: (+) The data is represented as Java Objects, refined by a set of interfaces and typically implemented according to some design patterns.
  • JMX: defines some additional helper services (eg. managing relationships between JMX objects).
  • SNMP: doesn't define this kind of service.
  • SNMP: (-) you have to be an SNMP expert to deal with SNMP.
  • JMX: (+) you don't have to be a Java or JMX expert to deal with JMX.
  • SNMP: (-) pushes the complexity to management applications (relational model (indexes, inter table indexing, inter MIB indexing etc...), protocol limitations (PDU size, data size, etc...), model complexity (decribing complex things with only simple types), specific modeling language (SMI)
  • JMX: (+) makes it possible to keep the complexity at the agent level. (possibility to invoke methods, JMX is Java)
  • SNMP: (+) already defines many standard MIBs
  • JMX: There are few standard models for JMX, for example the J2EE? one defined by JSR 77 and the J2SE? one defined by JSR 163/174.
  • SNMP: (+) Authorization and Access control is defined in SNMPv3.
  • JMX: Some aspects of Access control are defined in JMX (see the next point).
  • SNMP: (-) Configuration of security in SNMP is either inexistant (v1,v2) or complex (v3), and cannot usually be mapped to existing infrastructures.
  • JMX: (-/+) Configuration of security for JMX is not totally addressed, but you can usually map it to existing infrastructures (e.g. use native operating system RBAC model).  Configuration of access control is addressed (or at least one way to do it is via Java Permissions), but configuration of authorization is not, except in so far as you can use the JMXMP support for SASL to build on existing configuration you might have elsewhere.

It's important also to set the historical and market context:

  • SNMP: Originates from the hardware management world (eg. routers, switches, computers).
  • JMX: Originates as an attempt to provide a native Java based management technology for Java products.
  • SNMP: has good market presence for hardware components but is generally not so popular for managing more complex software deployments. There appears to be a phenomenon that alot of customers ask for it as a check-box item, even though it's utility is questionable: for example in DS deployments the native LDAP interface tends to be preferred. Even server products where SNMP is already in placetend to agree that SNMP is pretty ugly.
  • JMX: has good uptake in the market. For Java server products it appears to be the natural choice of management technology.

Conclusion

SNMP is best adapted for management/monitoring tasks for hardware or infrastructure type products. It is largely a check-box item with customers purchasing deployments of middleware products.

See Also



About

user12587121

Search

Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today