Web-Based Network Management - A Free Add-On to HP Openview
Many of today's Web-based system administration tools exhibit two characteristics. First, in some proprietary systems a system administrator must use the vendor's GUI and a manager must rely on the system administrator for notification of a problem. However, often a system administrator's large workload makes it difficult to constantly monitor the network, leaving problems undetected and unreported for too long. Second, many of the available tools are cumbersome to use and sometimes just too expensive. I decided to come up with a solution for system administrators and managers in my environment. There are a couple of commercial products that do exactly what this code does, but considering that I already had access to a MIB collecting station, I decided to write the code myself.
In the environment in which I work, there are several high-end, mission-critical Sun Microsystems UNIX servers, all running HP Openview 4.1 and monitoring over ten thousand network nodes. On the front-end, there are several types of clients, including Sun workstations, Macintosh, Windows 95, and Windows NT personal computers. Corporate wanted a way for any manager to look at a server and be able to tell if it has a problem or if a trend might develop into a problem. The only thing common to all client types was Netscape Navigator. My solution for corporate's objective had to satisfy four design criteria:
- All clients must be able to view summary detail (platform independence).
- The interface must be intuitive and easy to use (no training).
- A user should be able to generate their own queries.
- There must be no capital outlay.
The program that satisfied these requirements appears at:
This program satisfies the design criteria by including the functionality of HP Openview's SNMP collecting database, the easy interface of Netscape Navigator, and with no additional outlay of money, except for the time taken to write the code.
The first step in this procedure was to decide which variables to monitor. We chose Disk Utilization , CPU Utilization, Swap Space, and SNMP Packets In. The SNMP Packets In gives us an indication of just how much SNMP traffic these servers were handling. With the large number of nodes being monitored, there is a substantial amount of SNMP traffic to these servers. In the HP Openview's SNMP configuration we set up monitoring of these four variables at 15-minute intervals.
Now that HP Openview was collecting this information, we needed to convert the information from an xwd-formatted file (HP's default) to an image that could eventually be displayed on a Web page. We chose the GIF format. The script SNMPtoweb.pl takes care of this. The script converts the xwd data file to a GIF file, using the freeware PNG graphics utilities, and puts the GIF file in a directory where the http server can display it.
The next step was writing a couple of html files that call and display the image. The image starts off as a thumbnail and then, if trouble is spotted, a user or manager can click on it to examine the larger image. The use of HTML files allow the system administrator to control both the information that is available and how it can be displayed.
The last step was to put the image gathering and conversion script into root's crontab, so the information is periodically updated. We chose to run the SNMPtoweb.pl script every 15 minutes.
The Perl script, SNMPtoweb.pl, is shown in Listing 1. It takes an xwd data file and produces a GIF format file for displaying on a Web page. Here is an overview of some of the key aspects of the script.
Line 8 opens a log file to direct standard output and error.
Line 14 takes the output of the xnmgraph utility supplied with HP Openview and redirects it to a file called SNMPin.xwd, which is in the xnmgraph output format. The displayWidth sets the data graphed to seven days.
Lines 15 - 17 sets up the remaining three variables to be collected.
Line 23 calls the utility xwdtopnm, a set of PNG graphics utilities that allows any graphic image to be converted to any graphic image. (For source code availability and additional information about PNG, look at http://www.wco.com/~png/.) This line takes in the SNMPin.wxd data file and outputs a SNMPin.pnm graphic file.
Lines 24 - 26 continue with the remaining xwd data files.
Line 33 gives the user the ability to look at several thumbnails at once. Without this step, a full-page GIF file would appear and the user would have to constantly move to different pages to look at other variables. In this way the user could call up the system page and take a quick look at several items at once. The output of this file is the icon image in pnm format. pnmscale is another PNG utility. In this line I am taking a full-size image and scaling it down on both the x-axis and the y-axis. The output is the file SNMPin_icon.pnm.
Lines 34 - 36 complete this step.
Line 42 is an important step. By iconizing these files, the lines that indicate potential problems blend in with the black background of the image, so it is sometimes difficult to read. pnmgamma 35 is basically making these images brighter so you will easily be able to distinguish these spikes. These are output to a temp file t_SNMPin_icon.pnm.
Lines 43 - 45 continue this process.
Line 50 is needed because in the next step of converting these icon images to GIF files, the colors need to be re-synched. ppmquant 256 is basically looking at the temp file to grab 256 colors and output this to another temp file.
Lines 52 - 53 continue this process. This step is needed only for the icon images.
Line 59 is where the conversion takes place, if everything to this point is done correctly. The output of the pnm files gets converted to GIF images.
Lines 61 - 66 finish this procedure. Both the full-scale and icon files get converted to GIF images.
The rest of this script changes ownership for the http server, moving images and cleaning up the directory. Once the images are placed in the proper html server directory, additional html files point to the correct image.
Index.html, shown in Listing 2, is a sample of html code that points to an image. Here are several important elements of the file.
Line 10 is why I use html pages to call the GIF images. By having html pages I can then include SSI commands to produce time and date stamps and execute any other information I may need to pinpoint the source or active server.
Lines 12 - 15 set up the links from the images to the full-scale GIF files, again using SNMP.html as the anchor for this thumbnail SNMPin_icon.GIF.
Listing 3 shows a copy of SNMP.html. Line 3 of that file allows you to show the date and time the image was created. xnmgraph has no built-in function to show the date and time on the GIF file.
The last line in Index.html gives the sys admin considerable flexibility in choosing what information is available for their network monitoring. The last line in Index.html calls up Index2.html (Shown in Listing 4.). A manager may just want to see the last two days of data, data from a different server, or only a particular managed object. By adding the OID to the HP collection capabilities and editing the Index2.html file to add additional OIDs and servers, the sys admin can extend his network monitoring capability.
I find that network management is a lot more than just SNMP. While the RFC says it is, I look at network management as a process that is continually defining its role, expanding its role, and encompassing all aspects of technical knowledge for the sake of the network. In this project, I used different applications - commercial, freeware, programs, scripts, and utilities - and I find that all components can effectively work together if used in their proper place. So instead of using one app to do everything, I used apps where they should be used and utilized them effectively. What I see as a future development to this project would be to use some freeware databases and SNMP collecting stations and make this a totally free product. The talent of the individuals in the freeware software arena is unsurpassed due to their committment to their trades. n
About the Author
Steven Brown is a Network Systems Administrato and has over 15 years of experience in integrating large-scale heterogeneous mixed networks. He currently works for Paranet, based in Houston, Texas, and is studying for his Doctoral Degree in Information Systems Management at NOVA Southeastern University in Ft. Lauderdale Florida. He can be reached at firstname.lastname@example.org.