|
|
|
|
|
|
This chapter describes the Tuxedo MIB for SNMP. It includes the following sections:
MIB Object Identifiers
An SNMP management framework manages a collection of objects in a hierarchy of information known as a Management Information Base (MIB). Each object in the MIB has an object identifier (OID), which the manager uses to request the object's value from the agent.
To use the BEA SNMP Agent Integrator polling feature described in the BEA SNMP Agent Administrator's Guide, OIDs are used to identify the managed objects whose values are retrieved by the BEA SNMP Agent Integrator when it checks for the occurrence of events in the managed resource.
An OID is a sequence of integers that uniquely identifies a managed object by defining a path to that object through a tree-like structure called the OID tree or registration tree. When an SNMP agent needs to access a specific managed object, it traverses the OID tree to find the object. The MIB object identifier hierarchy and format is shown in Figure 1-1.
Figure 1-1 MIB Object Identifier Hierarchy and Format
In this hierarchy, each BEA private MIB object that the BEA SNMP Agent software manages has a unique object identifier. The BEA Tuxedo object uses a prefix of .1.3.6.1.4.1.140 to identify it as an object in the BEA private MIB.
For a complete listing of objects in the BEA private MIB in ASN.1 notation, read the file bea.asn1 in the installed BEA SNMP Agent software.
ASN.1 File
An ASN.1 file is a standard SNMP file that defines the objects that make up an SNMP- compliant MIB. Each object in the file is defined in compliance with the SNMP standard. The BEA SNMP Agent provides the ASN.1 file bea.asn1 for defining the Tuxedo MIB (with WebLogic Enterprise extensions) for SNMP.
Note: The Tuxedo and WLE MIB definitions are written in concise MIB format in accordance with RFC 1212, as required by the SNMP standard.
Relative and Absolute Object Identifiers
Absolute OIDs specify a path to an attribute from the root of the OID tree. Absolute OID names always begin with a dot and must specify every node of the OID tree from the top-most node to the specific managed object. For example:
.1.3.6.1.2.1.1.1
Relative OIDs specify a path to the attribute relative to some node in the OID tree. For example, 2.1.1.7 specifies the sysContact object in the system group, relative to the Internet node in the OID tree.
In addition to using the "dot-dot" notation, a series of integers separated by dots to describe OIDs, you can also express OIDs by using textual symbols instead of numbers to represent nodes in the path to the object, or by using a combination of both integers and textual symbols. A symbolic OID uses mnemonic keywords to specify the managed object. For example:
mgmt.mib-2.system.sysDescr
The following numeric OID uses integers to specify the same managed object:
2.1.1.1
Note that this example is a relative OID.
An OID can combine both symbolic and numeric representations of individual nodes of the OID tree; for example:
mgmt.mib-2.1.sysDescr
Note: When using OIDs to specify objects whose values are checked using BEA SNMP Agent Integrator polling rules, only the numeric form of the OID can be used. For details, see Chapter 8 of the BEA SNMP Agent Administrator's Guide.
Updating MIB Objects
Some objects in the BEA SNMP MIB for Tuxedo systems can be set (updated) only under certain states of the Tuxedo system. If you get an error while trying to set read-write objects in this MIB, please refer to the ULOG file.
Supported MIB Objects
To access MIB objects that are managed by agents or subagents, the scope of the OID tree for which each agent or subagent is responsible must be defined to the BEA SNMP Agent Integrator. For monolithic SNMP agents, and SMUX or DPI master agents, this is done by specifying an OID in one or more NON_SMUX_PEER entries in the beamgr.conf configuration file, as described in Chapter 5 of the BEA SNMP Agent Administrator's Guide. The BEA SNMP Agent Integrator then knows to access the managed objects in that branch of the OID tree through the specified agent.
The BEA SNMP Agent Integrator directly accesses MIB objects in the SMUX MIB, the MIB II system and snmp groups, and the beaIntAgtTable MIB object in the BEA SNMP Agent MIB. The beaIntAgtTable MIB objects define the polling capability of the BEA SNMP Agent Integrator.
The bea.asn1 file contains definitions for Tuxedo and WLE objects that are SNMP compliant. The BEA SNMP Agent supports the following MIBs:
Tuxedo managed object names within the MIBs for SNMP are usually prefixed with the letters tux. WLE managed object names are usually prefixed with wle. For example, the Tuxedo Core MIB contains a group termed Machine. Within this group are managed objects such as the following:
tuxTmachinePmid
Represents a physical machine identifier
tuxTmachineLmid
Represents the logical machine identifier
Most Tuxedo objects also apply to WLE applications.
Managing Tuxedo and WLE Applications Using the Tuxedo MIB for SNMP
The Tuxedo and WLE systems identify application items in a hierarchy of information known as Tuxedo Management Information Bases . These databases contain definitions that describe the components found in the Tuxedo or WLE application. Included with the BEA SNMP Agent is an SNMP version of the Tuxedo MIBs. The Tuxedo MIB for SNMP also includes MIB objects that represent attributes of Tuxedo and WLE resources.
To monitor or modify values of managed objects through your systems management platform, you need to know which MIB objects represent the features of Tuxedo or WLE resources that are relevant to your management goals. You also need to know the data types, default values, and access permissions for these MIB objects.
Querying Non-Existent MIB Objects
If you attempt to retrieve the value of a MIB object, and that object does not exist, either no value is returned, or one of the following values is returned:
Using the Tuxedo MIB for SNMP, the BEA SNMP Agent Integrator can be configured to perform local polling and generate SNMP trap events, or execute a system command when certain conditions are met. The same effect can be achieved by defining a RULE_ACTION entry in the beamgr.conf file. This configuration file is described in Chapter 8, "Configuration Files," in the BEA SNMP Agent Administrator's Guide.
Structure of the MIB Definitions
The following keywords are used to define MIB managed objects:
Syntax
Defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI purposely restricts the ASN.1 constructs that can be used. These restrictions are made expressly for simplicity.
Access
Defines whether the object value can only be retrieved but not modified (read-only) or whether it can also be modified (read-write).
Note: For tabular objects, in some cases a read-write object can only be set during creation of a new row. Where this is true, it is noted in the Description section for that MIB object.
Description
Contains a textual definition of that object type that provides all semantic definitions necessary for interpretation. This clause typically contains information of the sort that would be communicated in any ASN.1 commentary annotations associated with the object.
Note: Each row in a table is an instance of the Entry object under that table. The Description section for the Entry object under a table (such as tuxTmachineTable) contains information on the columnar values that are minimally necessary for creation of a row-how a new row is created, whether the values pertain only to the local machine, and other pertinent information about the table objects.
MIB Event Trap Definitions Format
In addition to defining MIBs, the bea.asn1 file also defines traps. These traps are defined in accordance with RFC 1215, Trap definitions. Tuxedo Traps MIB,specifies the list of traps generated by the BEA SNMP Agent. The following keywords are used to define a trap:
Enterprise
An object identifier that specifies the management enterprise under whose registration authority this trap is defined. All the traps generated by the BEA SNMP Agent have an enterprise field set to the Tuxedo object identifier. The Tuxedo object identifier is .1.3.6.1.4.1.140.300. This value is passed in the enterprise field of the trap packet (Protocol Data Unit - PDU).
Variables
Defines the ordered sequence of MIB objects that are contained in each instance of the trap type. Each variable is placed, in order, inside the variable-bindings field of the SNMP trap packet (PDU).
Description
Contains a textual definition of the trap type.
Trap ID
Specifies the enterprise-specific trap ID for the trap definition. This is passed in the specific trap ID field of the trap packet (PDU).
Note: The value of the generic trap ID field in traps is always set to 6, indicating an enterprise-specific trap.
Differences Between the Tuxedo MIB and the Tuxedo MIB for SNMP
If you are familiar with the Tuxedo MIB, the primary differences to note when using the Tuxedo MIB for SNMP are a difference in terms and a few additional MIB items in the SNMP-based MIB.
The Tuxedo MIB identifies an abstract structure for Tuxedo resources. In a Tuxedo framework, a MIB is the classification of information in a Tuxedo application. However, instead of referring to groups and managed objects, as is common in SNMP terminology, the Tuxedo MIB defines application resources as classes and attributes. Classes are the administrative class definitions that make up the Tuxedo MIB. Each class has a set of attributes that identify individual items in the class. Examples of Tuxedo classes are:
T_MACHINE
The class definition for a machine
T_SERVICE
The class definition for Tuxedo services
Attributes for these classes are identified by the prefix TA_ followed by the attribute name. A few examples for the T_MACHINE class are:
TA_PMID
Represents a physical machine name
TA_LMID
Represents the logical machine name
For more information about the standard Tuxedo MIB, refer to the BEA Tuxedo Reference Manual.
In contrast, the features of manageable resources in SNMP are called objects rather than attributes, and objects fall under MIB groups rather than classes.
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|