|
|
All SNMP management applications communicate with one or more SNMP agents to deliver their functionality. Both the management application and the agent always conform to the SNMP, MIB, and SMI specifications. Although the management applications are diverse in nature, they all share a minimal common characteristics.
All the SNMP agents typically behave in a standard way - processing requests from the manager applications and sending traps. SNMP agents on a network only differ in the various versions of the SNMP they support, and the MIB or the managed objects they maintain. The SNMP management applications communicate with the agents to retrieve and collect the necessary information.
The following are the various factors that need to be considered while developing a management application.
Architecture of the Management Application
SNMP API can be used with two-tier as well as three-tier management applications. In the two-tier architecture, the management applications directly communicate with the agents. In the three-tier architecture, the management applications communicate with the agents through a manager-server. For building highly scalable management applications, three-tier architecture is the best option.
WebNMS SNMP API provides a wide choice of options in selecting the type of architecture the management application needs. The Choosing the Application Architecture section discusses the various types of network management applications and applets that can be developed using WebNMS SNMP API.
In today's distributed environment, applications should have a wide choice of deployment options. Deployment of standalone applications is preferred for most environments, while applet deployment might be needed for Web-based management of network entities.
Management applications developed using WebNMS SNMP API can be deployed in different formats, such as applications, applets, and servers. Support for applets in WebNMS SNMP API is provided by means of SNMP Applet Server (SAS). SAS enables communication between applets on Java browsers, which do not permit socket access to any host other than the applet host.
The Deployment Instructions chapter explains the various deployment options available with the WebNMS SNMP API.
Accessing the Data from the MIBs Supported by the Agent
The management applications typically request management data or properties from one or more SNMP-enabled nodes. The application needs to know the names and types of objects in the managed device. This is available in the Management Information Base (MIB) modules, which are usually provided with the managed devices.
The data supported by the agent are available in the form of MIB files and the manager applications make use of the information available in the MIB files while querying the agent. For example, RFC1213-MIB, also known as MIB-II, is a MIB module that is supported by all SNMP agents on TCP/IP-enabled devices. Apart from supporting MIB-II, each device has its own MIB, such as a printer MIB, a modem MIB, or a switch MIB. These MIBs can be used to access the associated data with it.
Management applications should be able to
Load and unload MIB modules
Access the information on managed objects using MIB
Resolve the textual labels to numerical OIDs
Determine the type of data of the MIB object
Simple management applications normally make a request by manually loading the MIB file, entering the OID, data type, and data value of the each variable binding. Advanced applications require loading multiple MIBs, storing the MIBs, logging the management requests, and so on.
WebNMS SNMP API provides rich support for handling and manipulating MIBs. The MIB support package of WebNMS SNMP API is designed to allow Java programs to take full advantage of the information contained in the MIB files. The Using MIBs in Applications chapter discusses more on MIB-related aspects while developing the SNMP management applications.
Collecting Data from the Agent
The SNMP management applications communicate with the agents to retrieve the data. Applications normally retrieve the data by synchronous/asynchronous communication or by polling at regular intervals.
The applications, while communicating through the synchronous mode, wait for the response of the previous request before sending a new request. In the case of asynchronous mode, the manager application can keep sending requests to the agent without waiting for the response. The responses are retrieved using the callback mechanism.
Though using asynchronous mode appears to lead to improved performance, it can be used when the manager application knows the OID of the object it has to query. The synchronous operation is relevant while retrieving something like a tabular data, in which the instance of the OID to be queried next is got from the response of the previous request.
WebNMS SNMP API has a comprehensive hierarchy of Java packages that allows a flexible selection of the desired level of library support. The developer can access the detailed SNMP information or choose higher-level Java Beans for simpler programming.
In the case of low-level APIs, the user has to handle all the resources including the low-level resources, such as session, api, pdu, and miboperations. The disadvantage of this is the complexity of the code to be written for developing a management application.
While using high-level API, the developers need not handle the low-level resources and they can use the API methods of the beans package for all operations.
API Overview explains the architecture of the different modules available as part of the WebNMS SNMP API distribution and their functions and features.
The data retrieving functions of the manager applications can be classified as follows:
Communicating with SNMP agent
Table handling
Polling
Management applications normally retrieve the properties of the devices using SNMP GET, GETNEXT, or GETBULK request to the OIDs. The request may be simply to check whether the node is alive or to periodically retrieve the values of specific managed objects.
The sections Data Retrieval Operations and Data Altering Operations discuss how the applications communicate with the agent to access the data and the various ways of accessing the data using the SNMP protocol.
Most of the MIBs are designed to handle large data in the form of tables. Management applications should be able to retrieve tables in a quick and efficient way. Intuitive table handling GUIs should become part of the management applications.
Table Handling in Applications explains the various table-related operations that can be performed using WebNMS SNMP API.
The retrieval of data for specific managed objects at periodic interval of time is called polling. Polling is normally used to monitor data that may change over time. Repeated polling of data is required when the object is a critical resource or when it is required to monitor the performance.
Polling can be performed for one or more nodes. Polling is started by selecting the specific node, the OID to be polled, the timeout-retry values, and the polling interval. The polling interval is normally given in seconds or in minutes. The polling interval can be determined by the size and the number of messages sent to each polling cycle, time taken by the agent to respond, and so on. The application can be used to regularly poll the agent, watch for threshold crossings, and take appropriate action based on the results.
Data Collection and Reporting discusses the polling features that are available in WebNMS SNMP API.
After the necessary data is collected from the agent, the management application has the option of displaying the result in the form of UI or non-UI. In case of displaying the results in the form of UI, the users have to build their own UI components.
WebNMS SNMP API comes with built-in UI components, such as LineGraph, BarGraph, TrapViewer, SnmpTablePanel, and MibBrowser to display the data received from the device.
For displaying the results in non-UI format, the developers can choose high-level non-UI beans or directly use the low-level API.
The advantage of using the high-level API is that the bean components perform the most common functions, such as splitting the PDU in the case of large requests/responses, removing the error OIDs from multi-varbind requests, returning the results for proper varbinds, retrieving table data, receiving traps at specified ports, and so on.
Receiving Unsolicited Messages from the Agent
Traps are unsolicited messages sent from an SNMP agent to one or more SNMP management applications. The generation of a trap by an agent indicates that some predefined event has occurred. When the agent detects the occurrence, trap messages are generated and sent to specific trap destinations.
Management applications running in these trap destinations receive the traps. Trigger actions can be configured on receiving the trap. This could be a change in color, an alarm sound, a blinking LED, an email alert, or a pager alert.
Applications should also allow the trap data to be logged to determine what kind of event caused the agent to generate the trap. This is done by examining the data stored in the variable bindings of each trap message. The varbinds may contain the identity and values of MIB variables that provide information on the specific event.
Many trap messages do not contain any variable bindings. This is because there may be no data associated with the event that triggered the generation of the trap, or the trap message itself conveys the necessary information.
Receiving Unsolicited Messages discusses the trap-handling features that are available in WebNMS SNMP API.
Version of SNMP to Be Supported
The management applications should be able to support all the SNMP versions, so that it can communicate with diverse set of devices/systems. SNMPv1 and v2c versions are predominantly used for monitoring and performance management. SNMPv3 with its enhanced security features can be used for configuration, accounting, and fault management.
WebNMS SNMP API supports all three versions of SNMP. Applications have the flexibility of selecting any desired versions.
|
|