1. Introduction/FAQ

MRTG is awesome, but by default it’s limited to SNMP metrics. These extension packages allow for much finer detail for performance monitoring, and they’re easy to set up, configure and maintain. Plus, since you don’t need to have an SNMP daemon running, your system is more secure.

Just untar the file and copy the appropriate .pl files to your run directory, then create your own config file from the templates provided.

Just about anything that comes out of vmstat, plus a few extras. For Solaris you can monitor CPU and memory utilization, paging and swapping, the run queue, the number of blocked processes, the scan rate, as well as disk (partition) capacity, and disk performance. Linux monitors include CPU and memory utilization, swapping, the run queue, the number of blocked processes, and disk (partition) capacity. BSD monitors include CPU, memory, the run queue, the number of blocked processes, disk (partition) capacity, and some disk performance characteristics.

Right now, all I have available are some static screenshots of a Linux box, but the Solaris and xBSD monitors look almost identical. You can see these static (they don’t update) Linux screenshots of these metrics: CPU Memory Swap Memory Processes Swapping root (/). If someone would like to contribute live links, or some Solaris or xBSD static screenshots of a box that sees heavy use, that would be awesome.

This software is GPL and comes with ABSOLUTELY NO WARRANTY. Use at your own risk, but it’s stable and I’ve been using it in a production environment for a couple of months. As far as support goes, I do this in my spare time. Feel free to send me (or even Mark) an e-mail is you have questions or concerns, but please read the docs first! I went to a lot of trouble to make these extensions as easy as possible to set up and use.

Also, I don’t claim to be a performance-monitoring guru. If any of my explanations of what a performance characteristic means are incorrect, then let me know and we can discuss it. This is also my first open source contribution.

I’d like to port these monitors to other operating systems when I get the chance. This release includes the port to xBSD, and in the future I may develop ports to AIX and possibly HP-UX. If you have a suggestion or request let me know.

I’d like to create a disk performance monitor for Linux, but that requires a kernel patch that I can’t seem to find (see the details in section IV). Please let me know if you have any information in this area.

The next release will probably include some network monitors generated from netstat of some sort.

Who do you want to thank?

First, I have to thank my partner Mark, who got me started in this whole mess anyway. I also want to thank my employer, Crave Technology who supported all of my development efforts. Of course, I also want to thank Tobias Oetiker and Dave Rand, without whom there would be no MRTG project for me to write extensions for. Finally, I want to thank my Mom because without her I wouldn’t be here making cool software for the rest of you! If I left anyone out, just whine and I will include you.

Perl scripts have been developed to be used in conjunction with MRTG to monitor Solaris, Linux, and xBSD systems remotely. This remote monitoring uses ssh to transfer performance statistics to the performance monitoring station. This section discusses the details of how to install and configure the ssh package.

While performance data is gathered from remote machines, all scripts are executed on the machine that started the MRTG process. Localhost monitoring runs a local command such as "vmstat 1 2" and then parses the output of this command for data. Remote hosts are monitored by initiating a secure shell (ssh) connection to the remote host and then executing an identical command on that host. The output of this command is returned to the MRTG host which then parses the output in an identical fashion to the localhost version.

Prior to the development of ssh, traffic between hosts was usually unencrypted or trivially encrypted. The ability to "sniff" the transactions of a telnet or remote shell (rsh) session meant that unscrupulous personnel could acquire passwords from wire traffic with relative ease. Secure shell (ssh) non-trivially encrypts traffic between hosts and prevents the acquisition of passwords through the use of "sniffers".

The use of ssh in the MRTG scripts mimics the functionality of rsh, in that a trusted host (as specified in an .rhosts file for rsh) is allowed to execute commands on a system remotely. For ssh, not only can access be restricted to specific hosts, it is restricted to specific users at specific hosts.

Each host with ssh installed has both a public and a private key for each user which are used for encryption. During the establishment of a trusted connection, the trusted host sends its public key for the user initiating the connection to the trusting host. The trusting host compares this key with its list of authorized keys for that user. The username on both the trusted and the trusting hosts must be identical. If the key exists in the trusting host’s authorized key list for the specified user, access is granted (without a password). If the key does not exist in the authorized key list, the user is prompted to present a password for authentication. If the password fails, no connection is established.

As described above, ssh trusts require that an identical login exists both on the monitoring station and the systems to be monitored.

It should also be noted that from a security standpoint if the MRTG user account on the monitoring station were compromised, then an attacker would be able to run remote shells as the MRTG user on any machine being monitored. Thus, the monitoring host should be hardened as much as possible. However, the reverse is not true because the monitoring station does not trust the monitored hosts by default.

Installing the ssh Package on Monitored Hosts

Version 1.2.27 is the recommended version of ssh to be installed, as these scripts have not been tested (but are likely to be compatible with other versions).

For specific installation instructions, please refer to the ssh documentation. However, the following are the general steps necessary to set up ssh for MRTG.

1. Download and install ssh on the monitoring host and all the machines that you want to monitor.
2. Create a user account for MRTG to use that is identical on the monitoring station and all of the monitored systems. Do NOT use the root account. If you do and your monitoring station gets hacked, the intruder will automatically have root access on all the boxes you are monitoring.
3. Create a ~/.ssh directory for the MRTG user account on each of the monitored hosts and set the permissions on the directory to 700.
4. On the monitoring station, log in as the MRTG user account and create a public key using the ssh-keygen command. This should create (among others) an ~/.ssh/identity.pub public key file.
5. Use scp to push the file ~/.ssh/identity.pub to all of the monitored hosts. On each of the monitored hosts this file needs to become the file ~/.ssh/authorized_keys which is used to authenticate the trust. Your command might look something like "scp ~/.ssh/identity.pub mrtguser@host:/home/mrtguser/.ssh/authorized_keys."
6. Test that the trust works by issuing the command ssh –v remotehost. If you are dropped to a shell on the remote host without being asked for a password, then your trust is working properly. If you are asked for a password, the debug messages should help you determine what the problem is.

This document discusses the details of how each of the perl scripts for gathering Solaris performance metrics functions. All scripts are provided as-is with no warranty.

Perl scripts have been developed for use in conjunction with MRTG to monitor performance on Linux systems. This document discusses the details of how each of these scripts functions. All scripts are provided as-is with no warranty.

POSSIBLE BUG NOTE: While this script works great on its own from the command-line, I have been having some difficulty getting it to interface correctly with MRTG. As a result I sometimes get very odd looking graphs similar to this one, ONLY when monitoring LINUX hosts. My suspiction is that this is a result of improper clock settings on my monitoring server, but I only develop the problem with this particular monitor on Linux only. If you experience similar difficulties, please let me know.

Disk Performance Statistics

Perl scripts have been developed for use in conjunction with MRTG to monitor performance on xBSD systems. This document discusses the details of how each of these scripts functions. All scripts are provided as-is with no warranty. At this point, the scripts have only been tested on FreeBSD 4.1.1-RELEASE #0 and OpenBSD Generic #25. I haven't used these scripts in production yet (mainly because I don't have any xBSD boxes in production) but they seem to be working just fine. If you find any bugs, please let me know.

WARNING! I don't have access to any xBSD machines that have more than one disk, so I don't know how the vmstat output changes. If extra disks mean extra columns in vmstat, then the CPU monitor may be affected. If you have multiple disks in your xBSD boxes, and the CPU monitor works for you, then please let me know!

Change Log

All copyrights are properties of their respective owners, and none of them endorse this site. Please don't sue me.