After being a software developer for several years, I 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 their career:
- Understand what “production” really means.
- Experience 24/7 on-call support.
- Talk directly 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 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 Days of Monitoring
While doing some more research on the web I found some odd things about monitoring and the tools around it, especially Nagios, the de facto standard.
Nagios is a very complex system and it takes a lot of time to master. Configuring it and tailoring the system to your needs is far from easy. Additionally, it is rigid and hard to extend. The more instances that need to be monitored, the harder it gets; Nagios can be overwhelmed by a large number of systems.
Most of all, it is not suited for cloud infrastructures with servers changing constantly. Whenever the infrastructure changes, Nagios must be reconfigured and restarted. Although this can be automated with configuration management tools, it is still not a clean solution, since provisioning runs occur only at 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 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 installed it manually first, then wrote a Puppet module to automate the procedure. It took a while to figure that out, not because of Sensu, but because I was new to Puppet and had 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 to your needs. It is extensible and driven by your own code, so you can modify it to work the way you want.
Sensu is open source with an active community. Take it, do whatever you want with it, and contribute to the project.
Sensu is scalable
I have to admit I ‘m hooked on cloud infrastructure. Actually, even this blog is hosted at Heroku.
The real advantage of cloud infrastructures is that they can be scaled whenever required, with no up-front investments. When you scale up or down, Sensu comes along— nothing has to be reconfigured or restarted since new instances are 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 few blog posts I ‘ll write more about Sensu— how to install and configure it, and whatever else comes up. Finally, everything will find its place in “The Book of Sensu” in the near future.
In the meantime, check out the following links. These were my starting points for Sensu and the main resources for this post.
There are more links in the Sensu WiKi.
Done for today!