After being a software developer for several years, I have decided to join an operations-team to move along the delivery pipeline and get a clear picture of what is going on there.

Side-note: Every software developer should do this at least once in his career:

Understand what “production” really means.
24/7 on-call support.
Directly talk to clients when times are rough.
Appreciate the value of automation, logging and monitoring.

Just to name a few.

Back to the topic.

I was given the task of setting up monitoring for our servers by using the Sensu monitoring framework.

So, there I was, our servers, the Sensu Wiki and a few blog posts here and there.

The not so Good Old Times of Monitoring #

While doing some more research on the web I have found some strange things about monitoring and the tools around it, especially Nagios, the de-facto standard.

Nagios is a very complex system and it needs lots of time to master it. It is far from an easy task to configure it and tailor the system to your needs. Additionally, it is very rigid and hard to extend. The more instances that need to be monitored the harder it gets. Nagios is pretty much overwhelmed with a large number of systems.

Most of all, it is not suited for cloud infrastructures with servers changing at every moment. Whenever the infrastructure changes, Nagios has to be reconfigured and restarted. Although this can be automatically done with configuration management tools, it is still not a clean solution, since provisioning runs are performed only in certain intervals. The monitoring tool should be able to handle a changing environment on its own in real-time.

Why I am using Sensu #

Sensu starts where most other tools stop. As written in the introductory blog post of Sensu by Sean Porter, it aims to be

simple
malleable
scalable

Now, let’s dive into that.

Sensu is simple #

Have you looked at its code base? No? I highly recommend it, it’s a pure joy. The server core is less than 1k lines of code.

Installing Sensu is a matter of minutes. I have installed it manually first. Then I have written a Puppet module to automate that procedure. It took a while until I have figured that out, not because of Sensu, but because I was new to Puppet and have never written a module for it. See my post “Provisioning Sensu with Puppet”. The code can be found in my GitHub repository. It is far from perfect but it gets the job done for now.

In fact, Sensu is made for configuration management tools. You won’t find anything in Sensu that can’t be configured by Chef, Puppet or others.

Playing into that, Sensu is also very light on configuration. All it takes are a few simple JSON files.

Sensu is malleable #

You can change and adapt Sensu according to your needs. It is extensible and driven by your own coding, so you are able to change it to make it work for your own needs.

Sensu is open source with an active community. Take it and do whatever you want with it and contribute to the project.

Sensu is scalable #

I have to admit, I am totally hooked on the whole cloud infrastructure thing. Actually, even this blog is hosted at Heroku.

The real advantage of cloud infrastructures are, that they can be scaled whenever it is required, no up-front investments needed. Whenever you have to scale up or down your infrastructure, Sensu comes along. Nothing has to be reconfigured or restarted since new instances will be discovered automatically.

What does “Sensu” mean? #

Sensu is the japanese word for folding fan (扇子). It is an allusion to the fanout exchange, one of the exchange types used by RabbitMQ.

From Here to There #

In the next couple of blog posts I will write more about Sensu, on how to install and configure it and let’s see what will also come up. Finally, everything will find its place in “The Book of Sensu” in the near future.

In the meantime, check out the following links. Those were my starting point to Sensu and are the main resources for this post.

There are more links in the Sensu WiKi.

Done for today!