[38]Many devices say they are SNMP-compatible but support only a few MIBs. This makes polling nearly impossible. If you don't have the object(s) to poll there is nothing you can do, unless there are hooks for an extensible agent. Even with extensible agents, unless you know how to program, the Simple in SNMP goes away fast.Each of the external polling engines we will look at uses the same polling methods, although some NMSs implement external polling differently. We'll start with the OpenView xnmgraph program, which can be used to collect and display data graphically. You can even use OpenView to save the data for later retrieval and analysis. We'll include some examples that show how you can collect data and store it automatically and how you can retrieve that data for display. Castle Rock's SNMPc also has an excellent data-collection facility that we will use to collect and graph data.
WARNING: Starting xnmgraph from the command line allows you to start the grapher at a specific polling period and gives you several other options. By default, OpenView polls at 10-second intervals. In most cases this is fine, but if you are polling a multiport router to check if some ports are congested, a 10-second polling interval may be too quick and could cause operational problems. For example, if the CPU is busy answering SNMP queries every 10 seconds, the router might get bogged down and become very slow, especially if the router is responsible for OSPF or other CPU-intensive tasks. You may also see messages from OpenView complaining that another poll has come along while it is still waiting for the previous poll to return. Increasing the polling interval usually gets rid of these messages.Some of NNM's default menus let you use the grapher to poll devices depending on their type. For example, you can select the object type "router" on the NNM and generate a graph that includes all your routers. Whether you start from the command line or from the menu, there are times when you will get a message back that reads "Requesting more lines than number of colors (25). Reducing number of lines." This message means that there aren't enough colors available to display the objects you are trying to graph. The only good ways to avoid this problem are to break up your graphs so that they poll fewer objects or to eliminate object instances you don't want. For example, you probably don't want to graph router interfaces that are down (for whatever reason) and other "dead" objects. We will soon see how you can use a regular expression as one of the arguments to the xnmgraph command to graph only those interfaces that are up and running. Although the graphical interface is very convenient, the command-line interface gives you much more flexibility. The following script displays the graph in Figure 9-3 (i.e., the graph we generated through the browser):
You can run this script with the command:#!/bin/sh # filename: /opt/OV/local/scripts/graphOctets # syntax: graphOctets <hostname> /opt/OV/bin/xnmgraph -c public -mib \ ".iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInOctets::::::::,\ .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOutOctets::::::::" \ $1
The worst part of writing the script is figuring out what command-line options you want -- particularly the long strings of nine colon-separated options. All these options give you the ability to refine what you want to graph, how often you want to poll the objects, and how you want to display the data. (We'll discuss the syntax of these options as we go along, but for the complete story, see the xnmgraph(1) manpage.) In this script, we're graphing the values of two MIB objects, ifInOctets and ifOutOctets. Each OID we want to graph is the first (and in this case, the only) option in the string of colon-separated options. On our network, this command produces eight traces: input and output octets for each of our four interfaces. You can add other OIDs to the graph by adding sets of options, but at some point the graph will become too confusing to be useful. It will take some experimenting to use the xnmgraph command efficiently, but once you learn how to generate useful graphs you'll wonder how you ever got along without it.$ /opt/OV/local/scripts/graphOctets orarouter1
WARNING: Keeping your scripts neat is not only good practice, but also aesthetically pleasing. Using a "\" at the end of a line indicates that the next line is a continuation of the current line. Breaking your lines intelligently makes your scripts more readable. Be warned that the Unix shells do not like extra whitespace after the "\". The only character after each "\" should be one carriage return.Now, let's modify the script to include more reasonable labels -- in particular, we'd like the graph to show which interface is which, rather than just showing the index number. In our modified script, we've used numerical object IDs, mostly for formatting convenience, and we've added a sixth option to the ugly sequence of colon-separated options: .1.3.6.1.2.1.2.2.1.2 (this is the ifDescr, or interface description, object in the interface table). This option says to poll each instance and use the return value of snmpget .1.3.6.1.2.1.2.2.1.2.INSTANCE as the label. This should give us meaningful labels. Here's the new script:
To see what we'll get for labels, here's the result of walking .1.3.6.1.2.1.2.2.1.2:#!/bin/sh # filename: /opt/OV/local/scripts/graphOctets # syntax: graphOctets <hostname> /opt/OV/bin/xnmgraph -c public -title Bits_In_n_Out -mib \ ".1.3.6.1.4.1.9.2.2.1.1.6:::::.1.3.6.1.2.1.2.2.1.2:::,\ .1.3.6.1.4.1.9.2.2.1.1.8:::::.1.3.6.1.2.1.2.2.1.2:::" $1
Figure 9-5 shows our new graph. With the addition of this sixth option, the names and labels are much easier to read.$ snmpwalk orarouter1 .1.3.6.1.2.1.2.2.1.2 interfaces.ifTable.ifEntry.ifDescr.1 : DISPLAY STRING- (ascii): Ethernet0 interfaces.ifTable.ifEntry.ifDescr.2 : DISPLAY STRING- (ascii): Serial0 interfaces.ifTable.ifEntry.ifDescr.3 : DISPLAY STRING- (ascii): Serial1
This tells us that only two interfaces are currently up. By looking at ifDescr, we see that the live interfaces are Ethernet0 and Serial0; Serial1 is down. Notice that the type of ifOperStatus is INTEGER, but the return value looks like a string. How is this? RFC 1213 defines string values for each possible return value:$ snmpwalk orarouter1 .1.3.6.1.2.1.2.2.1.8 interfaces.ifTable.ifEntry.ifOperStatus.1 : INTEGER: up interfaces.ifTable.ifEntry.ifOperStatus.2 : INTEGER: up interfaces.ifTable.ifEntry.ifOperStatus.3 : INTEGER: down
It's fairly obvious how to read this: the integer value 1 is converted to the string up. We can therefore use the value 1 in a regular expression that tests ifOperStatus. For every instance we will check the value of ifOperStatus; we will poll that instance and graph the result only if the status returns 1. In pseudocode, the operation would look something like this:ifOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } ACCESS read-only STATUS mandatory DESCRIPTION "The current operational state of the interface. The testing(3) state indicates that no operational packets can be passed." ::= { ifEntry 8 }
Here's the next version of our graphing script. To put this logic into a graph, we use the OID for ifOperStatus as the fourth colon option, and the regular expression (1) as the fifth option:if (ifOperStatus == 1) { pollForMIBData; graphOctets; }
This command graphs the ifInOctets and ifOutOctets of any interface that has a current operational state equal to 1, or up. It therefore polls and graphs only the ports that are important, saving on network bandwidth and simplifying the graph. Furthermore, we're less likely to run out of colors while making the graph because we won't assign them to useless objects. Note, however, that this selection happens only during the first poll and stays effective throughout the entire life of the graphing process. If the status of any interface changes after the graph has been started, nothing in the graph will change. The only way to discover any changes in interface status is to restart xnmgraph. Finally, let's look at:#!/bin/sh # filename: /opt/OV/local/scripts/graphOctets # syntax: graphOctets <hostname> /opt/OV/bin/xnmgraph -c public \ -title Octets_In_and_Out_For_All_Up_Interfaces \ -mib ".1.3.6.1.2.1.2.2.1.10:::.1.3.6.1.2.1.2.2.1.8:1::::, \ .1.3.6.1.2.1.2.2.1.16:::.1.3.6.1.2.1.2.2.1.8:1::::" $1
The labels are given by the second and sixth fields in the colon-separated options (the second field provides a textual label to identify the objects we're graphing and the sixth uses the ifDescr field to identify the particular interface); the constant multiplier (.001) is given by the eighth field; and the polling interval (in seconds) is given by the -poll option.#!/bin/sh # filename: /opt/OV/local/scripts/graphOctets # syntax: graphOctets <hostname> /opt/OV/bin/xnmgraph -c public -title Internet_Traffic_In_K -poll 68 -mib \ ".1.3.6.1.4.1.9.2.2.1.1.6:Incoming_Traffic::::.1.3.6.1.2.1.2.2.1.2::.001:,\ .1.3.6.1.4.1.9.2.2.1.1.8:Outgoing_Traffic::::.1.3.6.1.2.1.2.2.1.2::.001:" \ $1
[39]Different vendors have different UPS MIBs. Refer to your particular vendor's MIB to find out which object represents low battery power.Before leaving xnmgraph, we'll take a final look at the nastiest aspect of this program: the sequence of nine colon-separated options. In the examples, we've demonstrated the most useful combinations of options. In more detail, here's the syntax of the graph specification:
The parameters are:object:label:instances:match:expression:instance-label:truncator:multiplier:nodes
[40]You can collect the value of an expression instead of a single MIB object. The topic of expressions is out of the scope of this book but is explained in the mibExpr.conf (4) manpage.
[41]This object is in HP's private MIB, so it won't be available unless you have HP printers and have installed the appropriate MIBs. Note that there is a standard printer MIB, RFC 1759, but HP's MIB has more useful information.
The polling interval is the period at which polling occurs. You can use one-letter abbreviations to specify units: "s" for seconds, "m" for minutes, "h" for hours, "d" for days. For example, 32s indicates 32 seconds; 1.5d indicates one and a half days. When I'm designing a data collection, I usually start with a very short polling interval -- typically 7s (7 seconds between each poll). You probably wouldn't want to use a polling interval this short in practice (all the data you collect is going to have to be stored somewhere), but when you're setting up a collection, it's often convenient to use a short polling interval. You don't want to wait a long time to find out whether you're collecting the right data. The next option is a drop-down menu that specifies what instances should be polled. The options are "All," "From List," and "From Regular Expression." In this case we're polling a scalar item, so we don't have to worry about instances; we can leave the setting to "All" or select "From List" and specify instance "0" (the instance number for all scalar objects). If you're polling a tabular object, you can either specify a comma-separated list of instances or choose the "From Regular Expression" option and write a regular expression that selects the instances you want. Save your changes ("FilesysObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining what kind of box' is being managed. For example, if vendor 'Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its 'Fred Router'." ::= { system 2 }
Once the graph has started, no real (live) data will be graphed; the display is limited to the data that has been collected. You can click on "File#!/bin/sh # filename: /opt/OV/local/scripts/graphSavedData # syntax: graphSavedData <hostname> /opt/OV/bin/xnmgraph -c public -title Bits_In_n_Out_For_All_Up_Interfaces \ -browse -mib \ ".1.3.6.1.4.1.9.2.2.1.1.6:::.1.3.6.1.2.1.2.2.1.8:1:.1.3.6.1.2.1.2.2.1.2:::,\ .1.3.6.1.4.1.9.2.2.1.1.8:::.1.3.6.1.2.1.2.2.1.8:1:.1.3.6.1.2.1.2.2.1.2:::" \ $1
We'll use the orahub device for this example. Start by clicking on the MIB Database selection tab shown in Figure 9-9; this is the tab at the bottom of the screen that looks something like a spreadsheet -- it's the second from the left. Click down the tree until you come to iso.org.dod.internet.mgmt.mib-2.snmp. Click on the object you would like to graph (for this example, snmpOutPkts). You can select multiple objects with the Ctrl key.snmpOutPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP messages which were passed from the SNMP protocol entity to the transport service." ::= { snmp 2 }
TIP: SNMPc has a nonstandard way of organizing MIB information. To get to the snmpOutPkts object, you need to click down through the following: "Snmp MIBsOnce you have selected the appropriate MIB object, return to the top level of your map by either selecting the house icon or clicking on the Root Subnet tab (at the far left) to select the device you would like to poll. Instead of finding and clicking on the device, you can enter in the device's name by hand. If you have previously polled the device, you can select it from the drop-down box. Figure 9-10 shows what a completed menu bar should look like.mgmt
snmp
snmpInfo." Though this is quicker than the RFC-based organization used by most products, it does get a little confusing, particularly if you work with several products.
Copyright © 2002 O'Reilly & Associates. All rights reserved.