A Web-based Graphical Front End for sar

Brian Rice

If you want to monitor your UNIX system's performance, you have a choice: you may have either graphical display or vendor neutrality, but not both. Many System V UNIXes offer the system activity reporter, sar, which reports, in a tabular format, data about resource demand over time. Tabular data are often adequate for personal use, but to convince management to buy faster equipment or convince users to make their programs more efficient, you may need to draw them a picture. Also when you are searching for patterns in load and performance, you may find a graphical display useful as well.

For graphical presentation, different vendors offer different tools: Silicon Graphics offers gr_osview, Sun offers sag, Hewlett-Packard offers glance, and so forth. Thus, monitoring performance in today's multi-vendor environments can mean significant ad hoc learning. Also, not all of these tools are network-aware, so using them for remote monitoring may require preparing another layer of software infrastructure.

Only sar is almost universally available and generally similar on all platforms. So, if you wish to build a platform-independent, network-aware solution, sar is the obvious foundation. In this article, I will show websar, a graphical remote monitoring system suitable for the intranet.

Introducing sar

The System V system activity reporter, sar, uses any of several proprietary techniques to read performance data from the kernel. See Listing 1 for an example of what sar looks like used from the command line.

The command asked for three samples, at one-second intervals, of system CPU utilization (-u). This example, from a Silicon Graphics server running IRIX, shows a not particularly busy system; the first six fields divide the CPU time of the last interval into time spent executing user code, time spent in the kernel, time spent servicing interrupts, time spent waiting on I/O, idle time, and time delivering dynamically allocated memory to some process. The last five fields further subdivide I/O wait time: this system I/O is almost exclusively with the filesystem. Listing 2 shows the same command on a Sun.

These listings demonstrate the first obstacle in designing a vendor-neutral front end: not all platforms offer the same data. In fact, different vendors' sar commands take different sets of option letters - the -u option is universal, as far as I know - and report mostly similar, though not identical, data items for each. So, the strategy will be to get sar to tell me everything it knows on each platform using the -A ("all") flag. Listing 3 shows a sample of sar -A on a SCO system.

The value for the mth data item on the nth row of the header is the mth number on the nth row of data. Other details to worry about include: some data lines can be blank, to indicate that their data would be meaningless or are unavailable; some data items can be wrapped in parentheses; and some data items have two values, such as in the ninth line of data shown in Listing 3. The value of proc-sz, 99/107, means that of the 107 entries in the kernel's process table, 99 are used.

Why a Web-based front end? Why Perl?

A good way to make any data available over a network at the smallest cost in management overhead is to feed that dataset to a Web server. Web servers are simple to install, and many are freely available. Like most UNIX Internet daemons, they consume CPU time only when responding to requests. A Web server can fit comfortably into 75 Kb of disk space and 400 Kb of memory. And, the capabilities of any Web server can be easily extended using the Common Gateway Interface (CGI). A CGI program receives data from Web browsers either through an environment variable or on its standard input. Everything the CGI program outputs is sent by the Web server back to the browser. Thus, your program need not worry about network details.

Graphical Web browsers are also readily available. The most popular, Netscape Navigator, does require the payment of license fees, however, your organization may have already licensed it. The NCSA Mosaic browser is available without license fees for "internal business purposes." (Microsoft's browser, Internet Explorer, although lavishly promoted, is not available for UNIX systems at this writing.) Regardless of which graphical browser you choose, its understanding of the Hypertext Markup Language (HTML) makes it easy to drop a graphical user interface onto any text-based tool. Your middleware program need only read text and output HTML, which is not a difficult task because HTML is a very simple page markup language. Little additional complexity is required to make that HTML output graphically rich.

Whenever the task at hand is to convert text from one format into another, Perl comes to mind. This freely available scripting language is everything good about UNIX in one box. Perl is eminently suited for writing CGI programs because of its text-manipulation abilities.

How websar Works

The websar tool is a CGI program. It expects to be started on demand by a Web server whenever a user points a Web browser at it, as if it were an HTML document itself. websar detects whether or not it is receiving the results of a form: if so, it treats that input as the user's preference for the type of graph to create. If not, websar sends a form to the user's browser, to solicit just such preferences. CGI programs that exhibit this "be-your-own-form" behavior are common.

In its form-presentation mode, websar must ask the system on which it's running which data items are available. websar does this by sending a list of sar -A's headers, with a checkbox next to each item. Because the device line is duplicated once for each device, it must also discover which devices are available. websar also examines the days for which sar data are available, and allows the user to choose one. Finally, because the sar command line gives the opportunity to restrict the report to a time range, and to ask for records at a particular time interval, websar offers text-boxes in which the user may type in values to sar. See Figure 1 for a sample of what this form will look like. After websar has sent this form to the browser, it exits.

When the user fills out the form and presses the "Graph!" button, the Web server starts websar again. Because the server hands websar the user's choices, websar runs in graphing mode. It runs the sar -A command using the data file for the day of the user's choice, passing in the start, end, and interval if given. websar extracts the desired data items from the resulting stream of data and stores them in an array, noting the maximum value for each. After sar -A finishes, websar computes an appropriate bar size to represent each value. Finally, it sends a bar graph to the browser, showing each data item returned by sar with its associated time. See Figure 2 for a sample. The Web browser itself does all the horizontal and vertical formatting; websar need only ask for it in HTML.

Note that websar does not send the binary image data for each bar itself; rather, it sends HTML that says, "Call back to this Web server and fetch this image and show it here." A selection of small bar images, in GIF format, is installed together with websar. To display a bar of a certain length, websar sends HTML requiring the display of several smaller bars of fixed sizes back-to-back. Because a Web browser need only download an image once, even if it is to be shown multiple times, this technique reduces network traffic.

The websar tool is written in version 4 of the Perl language. Because Perl 4 lacks multi-dimensional arrays, the program is more complex than a Perl 5 version might be. Nevertheless, Perl 5 has yet to achieve the widespread use that Perl 4 has, so websar remains a Perl 4 tool for now. Perl 5 is, by and large, a clean superset of Perl 4.

Starting a Tiny Web Server

For an excellent treatment of server setup, see Cornelius Cook's article "Configuring a Minimal Web Server" in the October 1996 Sys Admin. Cook explains how to set up the NCSA and Apache servers; either will work for our purposes here. Be sure to create a cgi-bin directory. websar will be installed there; its presence in cgi-bin will tell the Web server to run it when it is accessed, rather than simply to send it off to the browser as if it were a document. This will require a ScriptAlias line in the srm.conf file, such as the following:

ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/

Of course, you may choose the location of the cgi-bin directory, as long as you tell the Web server where it is.

Starting the sar Data Collector

Many UNIX systems that ship sar also ship sadc, the sar data collector. This tool collects all sar's data into binary-format data files, one file for each day's data. These files typically are stored in /var/adm/sa and are called sadd, where dd represents the day of the month on which the data were gathered. The script sa1 is provided as a convenient front end to sadc.

Whether you use sadc or sa1, you must create a cron job to gather data at intervals of your own selection. Make sure that the data files created are readable by the user ID that your Web server daemon is running as, because that is also the user identity that websar will run. You can do this by running your Web server as the same user as the owner of the sar data files, or by making sure that sadc creates world-readable files.

Installing websar

Place the websar script into the cgi-bin directory you created above. Again, make sure that the script is readable and executable by the user ID your Web server daemon is running as. Also, be sure to examine the first line of websar:

#!/usr/bin/perl

The #! must be the very first characters in the file, with no leading space, and following #! must be the correct absolute pathname of your Perl executable.

Check the Configurable Items at the Beginning of websar

Notice that websar will use a file containing canned output of sar -A if one is present. Creating a file like this is easy; you need only redirect the output of sar -A 1 1 into a file. On some UNIX versions, devices are included in this list only if they saw activity during the covered period. So, you might want to start some background jobs to rattle your disks before creating this file.

Make sure your system has cgi-lib.pl installed in its Perl library directory. If you don't have a copy of this excellent resource, just visit http://www.bio.cam.ac.uk/web/form.html.

You must also install the canned bars. The websar script expects those bars to be installed in a subdirectory, websar-bars, of the document area - conventionally /usr/local/etc/httpd/htdocs. Make sure these GIF files are readable by the user ID your Web server runs as.

Viewing Graphs with a Web browser

Any recent graphical Web browser, such as the Netscape Navigator or NCSA Mosaic, will do. If the target system (the one you wish to graph) is named walrus.foo.com, simply point your browser to the following Uniform Resource Locator (URL):

http://walrus.foo.com/cgi-bin/websar.pl

websar will notice the lack of form-response data, and your browser window will show a form. Complete this form and click the "Graph!" button.

Limitations and Possible Enhancements

Although I have sampled a wide variety of sar commands, websar is not guaranteed to be compatible with all. In particular, ICL UNIX sar's output is unusual and is not supported in this version.

This version of websar deals with binomial data items such as 99/107 by ignoring the second value - not unreasonable because the second value usually represents the (often fixed) size of some table. Nevertheless, it would be possible to graph that value as well.

As shown here, websar offers a maximum of three bar colors; if you graph more than three items, the same colors are reused. If you wish to use more colors, just create new sets of bar pieces c3s1.gif, c3s5.gif, etc., with a new color but of identical sizes to c0s1.gif, c0s5.gif, etc. Then modify the configurable parameter NCOLORS.

Conclusions

The ubiquity of Web servers and browsers means that any tool can have a graphical, network-aware interface. Languages like Perl will be adequate for placing a CGI front end on most tools; even highly interactive tools can be managed using something like Tcl. To bring the output of the program back to the browser screen in the most flexible way, you must know HTML.

Recently, I have seen more and more WYSIWYG text editors that save their text in HTML. System administrators should not let their use of these tools prevent them from becoming fluent in HTML. The program this article has described is a demonstration of the power of scripts that emit HTML.

Acknowledgements

Thanks go to the following persons, who responded to my plea for sar samples: Gerald N. Ginsburg, Joe Berry, Andrew Gierth, Doug O'Neal, Mark Sitkowski.

About the Author

Brian Rice is Member of Technical Staff with K Computing, a nationwide UNIX and Internet training firm. His duties include teaching and course development for system administration, networking, and programming classes. He also still does system administration. Brian received his B.A. in philosophy from Oberlin College in 1989.