Presentation of genDevConfig

genDevConfig is a perl Script that will generate the configuration to supervise a networked device using SNMP. The configuration that is generated is meant to be used with the Shinken monitoring system.

genDevConfig includes plugins to identify various hosts and RFC compliant interface types. Each plugin is a perl script that is imported at runtime by genDevConfig.

The script includes a definition files called Defaults.* for all the generic SNMP collection parameters such as :

• OIDs (basic SNMP information to collect data)
• datasources (which add instructions for OID collection)
• triggers (threshold calculations)
• device types (for a given device type what datasources should be collected)

Installation

The included INSTALL file has all the installation and setup information necessary to use the tool.

Documentation

The documentation is maintained in a Microsoft word format and contains references for :

• genDevConfig execution workflow (diagram and explanations)
• genDevConifg -h (runtme help options explained)
• How to add a new plugin (very easy, step by step explanation and example)
• Troubleshooting

Note: It refers to genRtrConfig and genDevConfig 2.x which are previous versions of the script not meant for use with Shinken, but the information is still relevant and plugin building has not changed.

Expected output

For the given device, genDevConfig will generate a Shinken configuration directory. Within this directory it will place a file, named after the "device host_name", which will contain the following information:

define host {

host_name ... ...

}

define service {

chassis_service

}

... custom_service1 ... custom_serviceN

interface_service1 ... interface_serviceN

Shinken monitoring system integration

Shinken host and service configurations generated by genDevConfig are meant to be used with SnmpBooster, the Shinken SNMP poller module.

Learn more about the installation and use of SnmpBooster in the Shinken wiki.

Known issues

The design specification tracks implemented features.

There are a number of known issues at this time :

• A DSTEMPLATE cannot have more than one instance map.

This is because the instance is passed as a check_command parameter. So DSTEMPLATES that expect different types of instance mapping per DS will not work correctly. We have to choose either Option-1, an inelegant multiple instance passed in check_commands, Option-2 split DSTEMPLATEs so that they only use a single instance map passed in the check_command, as is done today, option-3 Same as option-2, but also permit static instance mapping keys specified in the DS.

• The INI configuration files cannot have duplicate key/values. The configObj module will spit an error and bail. :-(
• Some plugins have not been tested against the actual equipement, consult the design specification to know which ones. Feedback and pull requests are welcome.
• In case of suspected problems, run genDevConfig with loglevel set to debug. genDevConfig -h for syntax.