Setting up New Devices in Cricket

Cricket is designed to be flexible enough to be able to monitor more than just router interfaces. The sample config tree that comes with it will help you learn about its capabilities, but to monitor other things, you'll need to write your own branches of the config tree.

Read this document to learn how to get the most from Cricket, by teaching it to gather data from all kinds of sources.

Creating Custom Target Types

Cricket gives you complete control over the contents and layout of your RRD files. This means that if you are going to be doing any serious target-type hacking, you need to understand the following concepts:

Now, with all those terms under your belt, you'll understand this statement: Using the datasource, RRA, and targetType dictionaries, you can completely control the kind, source, and quantity of data you store. The RRA's in the sample-config reproduce MRTG 2.x's data format precisely, and that configuration has proven to work well for most needs. If you are going to be using Cricket for the jobs it comes ready to do, you'll simply need to copy the sample-config tree and make minor changes to the targets it specifies.

If you need to customize Cricket to talk to other things, then you'll be following the following general steps:

  1. Create entries in the datasource dictionary that tell Cricket how to fetch your new measurement. If you are using SNMP, you'll probably want to add an entry to the OID dictionary in the same subtree, to make your datasource entry readable. For instance, say we wanted to use Cricket to talk via SNMP to an agent running on a Unix machine, and fetch the load average. We would add the OID for the load average to the OID table, then add a new entry (named "load-average") to the datasource dictionary that described this new datasource.
  2. Create a targetType entry to tell Cricket what datasources make up your new target-type. Assuming the RRA definitions from the --default-- entry are right, you only need to add set the "ds" tag for this entry. For the load average example, we'd put "ds=load-average" into a targetType entry named "unix-machine".
  3. Create a new target who's target-type tag is set to the targetType you created in the last step. If you are using SNMP to talk to the host, you need to make certain the variable snmp-host is set (since it contributes to the snmp variable, which in turn is required in SNMP ds-sources). You could set the snmp-host tag explicitly for every tag, but that would be a pain. Instead, you could choose your target names to be hostnames, then use the auto-target-name to set snmp-host correctly all the time, by adding a line like snmp-host = %auto-target-name% to the --default-- entry for that sub-tree. If you have a rare case in your system where the target name is not the name you want to send SNMP packets to, then you could override the default snmp-host by setting snmp-host directly for that one target.
  4. Run the collector on your new subtree, using the "-loglevel debug" option. This will tell you exactly what Cricket thinks things are set to when it tries to fetch your data, as well as what exactly happened when it went to fetch the data

If you come up with an interesting configuration, please share it with the Cricket community by submitting it to the Cricket contrib site hosted by the nice folks at GNAC.

If you need to add a new kind of data gathering subroutine, you'll want to read the code to snmp.pm very carefully and make a module like it to collect your data. It's not too hard, but it might not be worth the effort -- consider using a simple Perl script to let you fetch the data via the exec method. See the http-performance sub-tree for an example of how to do this.

Cricket version 1.0.5, released 2004-03-28.

Copyright (C) 1998-2000 Jeff Allen. Cricket is released under the GNU General Public License.