A management information base (MIB) number identifies an event and includes other data to describe the object that the event affects.
Because the MIB number is such an important part of identifying an event, vendors must not use the same MIB number to describe different events.
To avoid the use of the same numeric codes by multiple vendors, standards exist that result in MIBs being organized into one of three broad categories:
The International Standards Organization (ISO) sanctions and publishes these MIBs.
The Internet Assigned Numbers Authority (IANA) assigns the enterprise MIB numbers to a given organization. These MIB numbers are reserved for the exclusive use of that organization.
The IANA does not sanction or assign these MIBs, but can be as meaningful and useful as an ISO or enterprise MIB.
Pseudo‑MIBs often piggy‑back on the enterprise MIB of another organization and take advantage of many of the defaults available on a given platform.
Example:
Consider a pseudo-MIB that describes an event tree, in which each element on the tree represents information that could be sent when specified as a variable on the catrap command. At the top level, Enterprise 999 has two subtrees, Databases (999.1) and Financial Applications (999.2). The General Ledger database and application are identified as 999.1.1 and 999.2.1 respectively, and they have branches that represent various related events.
Represent General Ledger database shutdown, start, and journal full.
Represent General Ledger application warm start, cold start, and error.
Sending a trap of 999.1.1.2 is equivalent to sending the message "The enterprise database server that handles the General Ledger database has been started." A trap of 999.1.1.3 indicates that the General Ledger database has encountered a journal full condition. And a trap of 999.2.1.5 indicates that the General Ledger application has resumed processing after a temporary outage (warm start).
Taking the example further, assume that CSS is executing on several nodes in this network, but you have decided that all SNMP trap traffic is directed to a single monitoring computer, the Earth server. The Earth server receives the SNMP traps, which are recorded and acted on by the Event Management component.
Another computer in the network, the Mars server, is used for the production financial applications. For some unknown reason, an error occurs and the General Ledger production application running on Mars terminates with an error.
Testing the return code that the General Ledger production executable issues, the shell script realizes that the exit code indicates a problem and issues an SNMP trap to alert the Earth server that something has gone wrong by executing the following command:
catrap earth "" "" 6 0 22 999.2.1.7 integer 128
Sends the identified trap information to the Earth server.
Instructs catrap to take the default Enterprise code and the default agent address respectively for this node.
Indicates that this command is sending a specific trap.
Identifies the specific trap number for this example.
Defines an arbitrary number that we have selected as a timestamp indicator.
The next operands identify the variable binding (varbind) information for the trap.
Defines the ID of the object about which information is being sent. According to the event tree described earlier, this operand refers to an error in the enterprise financial application, General Ledger.
Provides more information about the event. This operand could mean “send an integer value of 128 to the Earth server,” assuming 128 is an error code that has meaning to the General Ledger application; or perhaps it is the exit code that the shell script detected as indicating an error.
When received at the trap target server Earth, the Event Management component (catrapd) decodes the event and performs automatic actions in response.
Returning to the event tree, you can see what other types of events could be sent, such as 999.1.1.1. This event indicates that the enterprise data server database for the General Ledger system has shut down.
When coupled with the other capabilities of CCS, the possibilities expand.
For example, you can use the Event Management facilities to intercept the error messages from any application and automatically execute customized catrap commands in response. The Workload Management function can detect key events and can send traps in response to files becoming available for processing or applications completing their processing. Security violation attempts detected by Security Management can result in other SNMP traps being sent, and so on.
When on the receiving side of an SNMP trap, you can use Event Management message handling policies to:
As this simple example demonstrates, the possibilities for using the SNMP trap information are endless.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|