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.
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.
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 metis-server
Boom, you're up and ready... though you won't have any monitors defined.
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" end end
You can set the result of the monitor using
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 Time.now.hour >= 21 critical("Real close now!") if Time.now.hour >= 23 ok("We're all good") end end
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 Time.now.hour >= params[:warning] critical("Real close now!") if Time.now.hour >= params[:critical] ok("We're all good") end end
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 end end
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 :eod do warning 21 critical 23 end
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 end
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.