Oracle SNMP Support Reference Guide
The Components of SNMP
The components shown in Figure 1 - 1 are explained in the sections that follow.
The management station refers to a node from which managed elements are monitored using the SNMP protocol. Typically, it is a stand-alone workstation that is on the same network or internetwork as the managed elements. While this book will consistently use the term management station, other terms used for it include management console, management system, or managing node.
At the management station, the management framework uses SNMP to request management information from other nodes. The framework collects, graphs, and possibly acts on that SNMP data, and saves some or all of it in a repository for historical analysis and reporting. Management frameworks include many tools and options. In addition to directly requesting information from managed nodes, frameworks typically use daemons to alert them when a managed node has sent a trap in response to a specific set of conditions. The traps also can be used to trigger management applications.
Because most frameworks use SNMP as a basis for communication, Oracle products that support SNMP can be integrated into virtually every management framework. Examples of such frameworks include:
- Novell Network Management System (NMS)
- Bull Integrated System Management (ISM)
- Castle Rock SNMPc Network Manager
Most of today's management frameworks also provide a selection of graphical objects that management applications may use to build a graphical user interface that serves their particular needs, such as:
- maps illustrating logical or physical network topologies
- icons representing individual network components
- graphing tools such as dials, bar charts, line plots, and so on, for effective monitoring of management information variables
The management applications are the tools integrated with the management framework to accomplish more specialized network or database tasks. These applications contain virtually all of the sophisticated logic associated with network management.
A customized management application can work with one or more frameworks (on different management stations) or run independently. Because Oracle SNMP Support is equally accessible to any type of provider, there are many different ways that applications can utilize it.
A fundamental management application, often shipped by default along with the management framework, is one that is capable of discovering the network topology and collecting some basic identification information about each discovered network entity or service. Such an application, for instance, may discover all hosts in a subnet along with their vendor, location, and status. Using this information, the management application can subsequently build up logical maps of the environment. On some operating systems, Oracle provides such an application for mapping Oracle objects on the network.
The managed node is a platform, such as a UNIX server, on which elements to be monitored reside. In Figure 1 - 1, two managed elements -- an Oracle7 server and Oracle Names -- are located on the managed node.
The master agent is the process on a managed node that accepts queries, also called "polls", from the management framework and communicates with the elements to be managed in order to answer the query. It also can send SNMP traps independently in response to specific conditions. Only one master agent can exist on each managed node. Any node that does not have an agent will not be able to respond to SNMP requests, but this does not prevent other nodes on the network from doing so. In other words, it is not necessary that every node in a network be able to respond to SNMP, although this is normally desirable.
The master agent may be either monolithic or extensible. If it is monolithic, it communicates directly with the elements to be managed. Although such an agent can manage multiple elements on the same node, the set of elements that it can manage is fixed when the agent is created, because the monolithic agent itself is responsible for interfacing to the managed elements.
If, on the other hand, the master agent is extensible, it will use a specific subagent for each element it has to manage. That subagent is then responsible for interfacing to the element. In this scenario, new subagents can register with the master agent at any time, so new managed elements can be added dynamically.
Some operating systems supply only monolithic agents. In this case, Oracle provides a master agent that can effectively treat that monolithic agent as a subagent, enabling new managed elements to be added to the node dynamically.
The subagent is a process that receives queries for a particular managed element from the master agent and sends back the appropriate answers to the master agent. One subagent exists for each managed element residing on the managed node (with the exception that a single subagent can handle multiple Oracle database instances on the same node). In Figure 1 - 1, one subagent is dedicated to the Oracle7 server application and another subagent is dedicated to the Names application. The subagent(s) and master agent communicate using a multiplexing protocol dictated by the master agent. There is no standard protocol for this connection, and, while a few protocols are widely used, none is a designated standard.
Notice that the subagent for the Oracle7 server is a separate process that communicates with the Oracle7 server through SQL*Net (using the IPC protocol). The Oracle Names subagent, on the other hand, is embedded in the application software itself. Both of these approaches are acceptable, as the specific means the subagents use to extract SNMP values are opaque to the master agent and to the framework.
A management information base (MIB) is a text file, written in ASN.1 notation, which describes the variables containing the information that SNMP can access. The variables described in a MIB, which are also called MIB objects, are the items that can be monitored using SNMP. There is one MIB for each element being monitored. Each monolithic or subagent consults its respective MIB in order to learn the variables it can retrieve and their characteristics. The encapsulation of this information in the MIB is what enables master agents to register new subagents dynamically -- everything the master agent needs to know about the subagent is contained in its MIB. The management framework and management applications also consult these MIBs for the same purpose. In Figure 1 - 1, two MIBs exist, one for the Oracle Server and one for Oracle Names. MIBs can be either standard (also called public) or proprietary (also called private or vendor).
The actual values of the variables are not part of the MIB, but are retrieved through an platform-dependent process called "instrumentation". The concept of the MIB is very important because all SNMP communications refer to one or more MIB objects. What is transmitted to the framework is, essentially, MIB variables and their current values.
All MIBs are, in fact, part of one large hierarchical structure, with leaf nodes containing unique identifiers, data types, and access rights for each variable and the paths providing classifications. There is a standard path structure that includes branches for private subtrees. A portion of this structure is shown in Figure 1 - 2.
Figure 1 - 2. The MIB Hierarchy
Each leaf of this tree provides the following information about one MIB variable:
- the access rights associated with the variable
- a textual description of the meaning of the variable
The variable's name is intended to be descriptive, whereas the OID is a number that describes the path taken through the tree to reach that variable. For example, the variable named sysContact, identified by the OID 1.3.6.1.2.1.1.4 (meaning iso.org.dod and so on), is a read-write string variable that contains contact information about the administrator of the underlying system.
All objects contained under the mgmt branch of Figure 1 - 2 (in other words, all objects with OID's beginning 1.3.6.1.2) are considered standard and are tightly regulated by the Internet Engineering Task Force (IETF). For example, the standard RDBMS MIB lives under the mgmt branch and is supported by all relational database servers that claim to be SNMP-enabled. Oracle further adds its own MIB objects under the private branch to increase the manageability of its products. The following MIBs are specific to Oracle Services and are found under the {private.enterprise.oracle} branch:
- the Oracle MultiProtocol Interchange MIB