Monitoring with Pingdom
Swedish firm Pingdom offers a flexible, affordable service for monitoring the availability and response time of web sites, applications and other services. At Needle we provision an instance of our chat server for each partner we work with, and as a result I’ve found myself creating a Pingdom service check to monitor each of these instances. As you might imagine, this is a rather repetitive task, and the configuration is basically the same for each service check – a process ripe for automation!
Thankfully Pingdom provides a REST API for interacting with the service programatically, which has made it possible for me to write a Chef LWRP for creating and modifying Pingdom service checks. Source available here: http://github.com/cwjohnston/chef-pingdom
Requires Chef 0.7.10 or higher for Lightweight Resource and Provider support. Chef 0.10+ is recommended as this cookbook has not been tested with earlier versions.
A valid username, password and API key for your Pingdom account is required.
This cookbook provides an empty default recipe which installs the required
json gem (verison <=1.6.1). Chef already requires this gem, so it’s really just included in the interests of completeness.
This cookbook provides the
Opscode::Pingdom::Check library module which is required by all the check providers.
Resources and Providers
This cookbook provides a single resource (
pingdom_check) and corresponding provider for managing Pingdom service checks.
pingdom_check resources support the actions
add being the default. Each
pingdom_check resource requires the following resource attributes:
host- indicates the hostname (or IP address) which the service check will target
api_key- a valid API key for your Pingdom account
username- your Pingdom username
password- your Pingdom password
pingdom_check resources may also specifiy values for the optional
type attribute will accept one of the following service check types. If no value is specified, the check type will default to
check_params attribute is expected to be a hash containing key/value pairs which match the type-specific parameters defined by the Pingdom API. If no attributes are provided for
check_params, the default values for type-specific defaults will be used.
In order to utilize this cookbook, put the following at the top of the recipe where Pingdom resources are used:
The following resource would configure a HTTP service check for the host
1 2 3 4 5 6
The resulting HTTP service check would be created using all the Pingdom defaults for HTTP service checks.
The following resource would configure an HTTP service check for the host
bar.example.com utilizing some of the parameters specific to the HTTP service check type:
1 2 3 4 5 6 7 8 9 10 11
At this time I consider the LWRP to be incomplete. The two major gaps are as follows:
- Changing the values for
check_paramsdoes not actually update the service check’s configuration. I have done most of the initial work to implement this (available in the
check-updatingbranch on github), but there are still bugs.
- The LWRP has no support for managing contacts.
updateaction for service checks which modifies existing checks to match the values from
disableactions for service checks
- Add support for managing contacts (
TrueClassattribute values to
- Validate classes passed as
- One must look up contact IDs manually when setting