Exploring Cricket

An open-source tool, Cricket lets you easily create baselines to monitor everything from frame-relay error rates on routers to disk and CPU utilization on servers.

October 7, 2005

7 Min Read
Network Computing logo

Cricket is essentially an interpreted, rather than binary, package, but we strongly advise using prebuilt packages in whichever Linux distribution you choose. One option is to implement the Cricket home page's current TGZ (tarred and g-zipped) package--version 1.0.5, at this writing--but if you're a newbie, use an RPM with the up2date or yum command for Red Hat, apt-get for Debian, to install the latest and greatest Cricket image.

When installing Cricket on a Debian system, make sure the Apache Web server is loaded, then use the command apt-get install cricket. You shouldn't have to modify /etc/apt-get/sources.list--the default should work fine.

How It Works

Cricket polls devices at user-defined intervals, collecting pre-defined SNMP OIDs (object identifiers). It feeds that data to RRDTool, a "round-robin" database that keeps recent data and rolls up older data into averages over time, such as five-, 15- or 60-minute intervals. Cricket uses RRDTool's graphing functionality to display the graphs over the Web server on the host.

In the Debian package, Cricket's configuration files live in /etc/cricket/config. These files tell Cricket how to collect from a device or group of devices, as well as how to handle errors and when to poll. Every directory, including the root of the config directory and subdirec-tories, gets its configuration information from two types of files: the defaults file, which sets up the environment of any configuration in a given subdirectory; and the targets file, which indicates the devices Cricket will monitor for this portion of the tree. A defaults file sets up things like snmp-version, or the SNMP version that is to be used in protocol communications. A targets file, for example, sets up specific devices using the target verb, which indicates the host name being used to contact the device.

Cricket works on the principle of inheritance where any subdirectory inherits the attributes of the directory above it. In one group, we used inheritance to create separate SNMP community strings for devices based on their geographic location. You can also put similar devices into a subdirectory structure--for example, /etc/cricket/config/ westside/servers could be all servers on the west side of town. All servers in the servers subdirectory would inherit the attributes of the west side (community strings, in this case), as well as those in the westside/servers directory.

The defaults file for a given subdirectory contains the counters themselves, the SNMP OIDs to be used and graphing methodology. It's not a good idea to mix device types within a given subtree--if the default for a certain subtree keeps track of hard-drive utilization, it doesn't make sense for a router to inherit that.

Cricket can monitor just about anything that has a counter associated with it. As users of MRTG will appreciate, knowing your octet (byte) count on your inbound and outbound interfaces helps determine if there's a problem on an interface.Typically, the devices from which Cricket collects data are defined in a targets file, which will accept an IP address. Alternatively, you can have them defined in an /etc/hosts file--or, better still, in DNS. As we all know, IP addresses can and will change, and it's less labor to set up your network management to refer to symbolic rather than numeric addresses.

Don't waste your time trying to craft defaults files. Rather than plugging in OIDs from various vendors, go to the Cricket Contrib page (cricket.sourceforge.net/contrib/). Our favorite contrib script for Cricket is GenRtrCfg, which supports Juniper and Cisco routers, firewalls and switches, among others. It uses SNMP for its autodiscovery, not remote commands through telnet or SSH.

But just setting up the configuration won't produce graphs. You must compile the configuration and set up Cricket's collector to run from the local scheduler. For Debian Linux, that would be from cron, in the file /etc/cron.d/cricket. The Cricket collector typically gets called every five minutes and collects data from every target defined in the Cricket config directory (/etc/cricket/config).

The default Debian installation avoids the use of root by defining a specific cricket user. You can log in as "cricket" to compile your configuration or use "su" to impersonate the Cricket user for the compile:

su -m --command="cricket-compile" cricketIt's important not to run the cricket-compile command as the root user. If you do, all the files the compile generates will be owned by root and the Cricket user won't be able to access them. That makes data collection difficult.

Debian sets up the proper cron entries so the collector runs every few minutes. But until you get the setup right, root is going to get an error report in its mailbox every few minutes after you install it.

Before setting up your data collection, lock down SNMP on your devices. If you wait until later, you'll have to set up your data collection once again, which is no fun.

Cricket Management ScreenClick to Enlarge

Use an SNMP community string--essentially a password--that's a complex sequence of uppercase, lowercase and special characters. If you don't need rw access, turn it off. Next, make sure your device is responding to SNMP. Because any device connected to a network has an interface, try to list your device's interfaces using this: /usr/share/cricket/util/listInterfaces hostname community-string

Any self-documenting you do with your routers or switches, such as using the description function in a Cisco port configuration, will show up on Cricket. Therefore, keep those description fields current so people viewing the Cricket graphs will know what they're looking at. For example, the setup for "daily utilization" (see image at left) shows COA_EXCHANGE as a label. This was picked up from the switch-description field and didn't have to be entered manually.

To use the GenRtrCfg script to configure a variety of routers, switches and firewalls, copy it to the /usr/share/cricket/util directory. The script will create a subdirectory for each device, so navigate to the parent directory for the device and invoke GenRtrCfg. To generate a configuration for a headquarters router named datacenter-6509 with a community string of mys3333cr3t, type:

cd /etc/cricket/config/headquarters

/usr/share/cricket/util/genRtrConfig -C mys3333cr3t--nounused datacenter-6509

GenRtrCfg will take care of the rest. It creates a subdirectory called datacenter-6509 and puts the right targets and defaults into place.

Testing 1-2-3

It's a good idea to manually test the collector function, or at least know how to do this if you're troubleshooting to see why your graphs aren't updating, for instance.Either log in as "cricket" or use the "su" command:

su -m --command="/usr/share/cricket/collector" cricket

Any errors upon collection will show up here for sure. Don't use root.

Once your setup is in place and you're collecting, you can navigate the Cricket Web hierarchy by browsing the host. If your host is called crickethost, its URL will be crickethost/cgi-bin/cricket/grapher.cgi. Don't panic if you don't see any data in the graphs. It takes a few minutes, so get a cup of coffee. Then check cron in Cricket's cron file:

/etc/cron.d/cricketOne error that new users of Cricket typically run into during a compile command is "No ds tag found for target type." This simply means that the target type in a targets file isn't valid. Check the "target type" in the targets file, and ensure that this type is defined somewhere in a "defaults" file--either in the current directory or somewhere higher in the tree.

If the output from a given page shows nan instead of a value, this likely means the permissions are messed up in /var/lib/cricket/. Make sure these directories are owned by the cricket user.

Once Cricket's running, you'll have baselines available for the week, month and year. You'll know what's normal in everything you monitor. So the next time the network slows down, maybe you won't have to resort to rebooting.

Jonathan Feldman is director of information services for the city of Asheville, N.C., and a contributing editor to Network Computing. Previously, he was director of professional services at Entre Solutions, an infrastructure consulting company based in Savannah, Ga. Write to him at [email protected].

Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like

More Insights