Metis is an implementation of the Nagios NRPE daemon in Ruby. It provides an easy framework to write your own monitors in Ruby, have them running in a daemon, and distribute/share them with others.


Metis is built around the idea of:

  • Monitors in Ruby
    Why? Ruby is a great language with a rich ecosystem of users, gems/libraries, and culture of testing. The existing ecosystem of Nagios monitors has a lot of variance in what language they're in. Some are bash, python, perl, etc. That is an awesome strength, but also means less commonality.
  • Testable monitors
    We test our applications don't we? Our monitors are what are supposed to be making sure our applications and servers are running correctly. They should be tested too. And they should be distributed with tests as well. You're running a monitor from a 3rd party on all yours servers... do you have full confidence it was written well and is bug free?
  • Easy distribution of monitors
    Nagios has a great community and tons of available monitors for you to grab. But grabbing monitors others have written can be hairy. They can have varying dependencies such as modules from CPAN in Perl, or EasyInstall in Python. If you don't know those languages, can be easily confused. They have varying requirements, such as a check in python require v2.7 while your OS release only has v2.6. Metis focuses on building in dependency handling and any framework to describe the configuration of the checks.
  • Easy deployment
    Metis works to cleanly separate monitor definition from configuration. It utilizes a simple ruby DSL modeled after Chef for configuration of monitor parameters (username/passwords, warning/critical thresholds) as well as the monitor definition itself. It also strives for easy integration with chef-server, so that the two can work hand-in-hand for self configuration.
  • Making monitors simple
    If you've ever written any of your own Nagios monitors, there can sometimes be a lot of setup. Beyond just performing the check, you might also need to parse command-line parameters, remembering exit codes, and ensuring the proper messages get propagated. Its wasted time and effort. Metis provides a quick and simple way to define the output of your monitor and returns the most important parts.


Installing Metis is a simple matter of running:

gem install metis

Boom, you're up and ready... though you won't have any monitors defined.

Defining Monitors

Monitors are defined as define blocks containing configuration attributes and an execute block that defines what to actually do. The checks are defined in files under checks/*.rb from the working directory by default.

A simple monitor might be:

define :simple do
  execute do
    "Hello World"

You can set the result of the monitor using critical(), warn(), or ok(). By default, Metis will assume the monitor is OK and if the execute block returns a string, set it as the message.

define :eod do
  execute do
    warn("Getting close to the end of the day") if >= 21
    critical("Real close now!") if >= 23
    ok("We're all good")

Monitors can define attributes that can be configured outside of the monitor logic itself using the attribute keyword. They are then accessible within the monitor through a params hash. For instance, to make a configurable warning/critical threshold:

define :eod do
  attribute :warning,  :default => 21
  attribute :critical, :default => 23
  execute do
    warn("Getting close to the end of the day") if >= params[:warning]
    critical("Real close now!") if >= params[:critical]
    ok("We're all good")

How to set these will be covered in the next section.

Monitors can also define external libraries or gems they might be dependent on using require_gem. These will only be required when the monitor is triggered, return a critical result and message if not found, and soon be installed as a part of the deployment process.

define :check_mysql do
  require_gem 'mysql'
  execute do
    # Connect to mysql and query it

Configuring Monitors

By default, Metis will look for a config.rb file in the working directory that should contain all the extra configuration settings for monitors. Building on the :eod example from the last section, you could configure its alert thresholds using the configure block:

configure :eod do
  warning  21
  critical 23

If you defined a more advanced monitor that required username/passwords to connect to a resource, you could include all of those:

configure :check_mysql do
  username "foo"
  password "bar"
  port     3306

Testing Monitors

Helpers for writing tests against your monitors will be coming soon.


  • Fork the project.
  • Make your feature addition or bug fix.
  • Add tests for it. This is important.
  • Commit, do not mess with Rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)
  • Send me a pull request. Bonus points for topic branches.

Copyright (c) 2011 Ken Robertson. See LICENSE for details.