Eyes – a new monitoring system

It was over a year ago that I started getting really annoyed at the state of monitoring systems. They all do what you sort of expect a monitoring system to do – watch (poll) systems and alert you when something’s gone off. Pretty much anyone who’s done much system administration work knows the obvious critters: Nagios, Munin, Cacti, Zenoss. Zenoss is the start into the pay realm too – GroundWorks, BMC Patrol, HP’s SiteScope, etc.

So here’s my annoyance – all of these systems, even the open source ones, are really set up to be managed by people, not other systems. They’re not built with API’s to be able to create, update, check on, and delete monitors. Some of them come darned close – Zenoss, SiteScope, etc. Others have this sort of worked around from the back side – i.e. Puppet or Chef recipes that generate Nagios configuration files.

So a year ago I decided that I could probably put something together that does the same basics, but has API’s built in from scratch. I did a lot of noodling on the idea, scratching ideas in notebooks and such, before I really kicked things off. Then I decided to see what I could do to wrap up a new system. I built it around Nagios plugins – mostly because there’s a lot of them and they do some pretty good stuff right off the bat. And that’s all open source as well. And I wrapped that around with a web application based on Django, because – well – I know Django reasonably well. The result is a basic system that I’m calling “Eyes”.

The whole source, from the very beginning, is on Bitbucket at http://bitbucket.org/heckj/eyes. And after poking at it on and off for nearly 12 months, I decided to wrap this up a bit and get it out there – so as of today I have my first release on PyPi, with documentation. And I created a mailing list – eyes-monitoring – on Google Groups to have some place to talk around it.

I very intentionally included documentation for the project from the very beginning, embedded with the project. I also very intentionally wrapped a large number of tests around the project, and have been checking and watching test coverage as the project grows and changes. The state today? Basically functional, but you have to know the innards to do much more with it.

Today it doesn’t have anything related to alerting or escalation within it. It doesn’t have much of anything around a user interface, and the data is stored all in RRD files. It’s at the point now where the basic framework is in place – and there’s a lot more to go: design of the user interface, blocking in alternate mechanisms to do monitoring, and fleshing out higher level features like notifications and alerts – both via email and alternative mechanisms (like web-hooks, or XMPP event streams).

What it is ready for is outside eyes. If you’re interested in contributing, or even sharing some ideas about what to do with Eyes, I’d love to hear from you. Fork the code and try it out, or join the mailing list (http://groups.google.com/group/eyes-monitoring) and share some of your ideas or thoughts.