SMILA/Project Concepts/Monitoring

Description

The SMILA needs functionality to provide

• information about the state and availability of the whole system
• information about the state and availability of single components
• mechanisms to manage components (start, stop, restart, pause, resume, update, etc.)

Standards like snmp and JMX should be supported.

Technical proposal

Overview

This chart shows the Monitoring architecture:

The architecture shown supports communication via JMX and SNMP. SNMP is seeen as an add-on on top of JMX and is not a must have for SMILA. Every Component to be monitored therefore must provide an implementation of a so called Agent. For Java Components, this Agent must support JMX. Additional SNMP functionality can be added using the JMX. There are 2 possibilities

• [snmp4j]: an enterprise class free open source and state-of-the-art SNMP implementation for Java. It supports mapping from JMX MBean instrumentation to SNMP scalars, tables, and notifications. The coding has to be done manually.
• [AdventNet SNMP Adaptor for JMX]: an SNMP to JMX adaptor that provides a Configuration Wizard for configuring the SNMP adaptor for user-defined MBeans and it automatically generates MIBs. Unfortunately this is NOT open source. However, this may be interesting in the eccenca context.

Non Java Components (C++, .Net, etc.) do not support JMX. Depending on what protocol to support, there are again 2 options (the first is the most flexibel one)

• JMX and/or SNMP: to support JMX, a wrapping Java Agent hast to be implemented. It the communication with the non Java Component has to be implemented in the MBean classes, using some kind of communication protocoll (JNI, Corba, etc.). SNMP functionality can be added to this Agent as for a regular Agent (see above).
• SNMP only: depending on the technology, there may exist direct snmp support. For C+\+ there exists the open source library [Agent+\+] that could be used directly in a C+\+

component. So there is no need to implement any wrapping Java Agent.

Here is the architecture in more detail:

Note that in the Agents the SNMP Adaptor may be optional and that for the C+\+ Component, only one Agent would be provided (either Agent+\+ or a wrapping Java Agent).

This architecture leads to lots of components that are directly monitored by JMX/SNMP Management Consoles. Such Consoles may be limited to a certain number of components. To reduce the number of components to access one could provide "Meta"-Agents, an Agent implementation that collects data from multiple components and offers the management console a consolidated state. How such a consolidation is done is specific to the components that should be combined.

Integration with TPTP

Based on the information provided by PoC [[1]] the integration with Performance Measurement using TPTP should be straight foreward. For Java Components TPTP Agents use JMX to communicate with a component, so this information can be provided by the Agent. Non Java components are accessed directly ?

Technologies

• [snmp4j]:
• [AdventNet SNMP Adaptor for JMX]:
• [Agent+\+]
• [OpenDMK] (not yet evaluated, may be interesting)
• [[2]] (good collection of resources)

Further Development Decisions

At the meeting in Kaiserslautern (5/6.3.2008) we decided to extend the existing PoC for the upper functionality (simple monitoring of state or values and managing functions (access methods).

Main goal is the use of JMX. The parts in the concept with SNMP should be seen as functions that can be added later.

• Further Tasks:

Concept for an Extended Version of the existing Performance Counters (SMILA Monitoring Concept with Performance Counters). Concept should cover:

• • Simple interfaces for exporting value to JMX
  • Simple interfaces that allow JMX Functionality (getter/setter) to specific variables
  • JMX Functionality should be encapsulated
  • An API for Starting/Stopping (see above) for SMILA Components

How could the API be used to start/stop an OSGI Bundle? Is it possible?

• Implementation