Amon Five

By Martin Rusev read

Amon started as a side project in early 2011 and it will be five years old in less than 2 months.

This seems like the perfect time to release a new version and a new vision for Amon. If this is the first time you hear about Amon - it is a self-hosted server and app monitoring tool with strong focus on simplicity.

I want to take a moment and share what happened since version 3, which was released in February.

Amon 3 was a monumental release for me personally, because I decided to put my consultant career on pause and commit full time to Amon. I am quite happy with that decision and I am really grateful to all the people who decided to support me and bought Amon this year.

My time was split between promoting Amon and non stop improving the product. Thanks to the constant feedback, I've managed to push a total of 42 releases since February.

Amon 3 vs Amon 5 commits

Every single module in Amon has been improved. A lot of effort has been put in the following 5 areas:

First to explain what health/service checks are - they are usually snippets in your favorite scripting language that check your servers for specific condition and return the result with a status code(OK, WARNING, CRITICAL, UNKNOWN) and a message.


#!/usr/bin/env ruby

# get the current list of processes
processes = `ps aux`

# determine if the mysql process is running
running = processes.lines.detect do |process|
  process.include?('myqsl')
end

# return appropriate check output and exit status code
if running
  puts 'OK - MySQL process is running'
  exit 0
else
  puts 'WARNING - MySQL process is NOT running'
  exit 1
end

You can check just about anything - remaining disk space, postfix queue length , dns, ping, ssl certificates, snpm, sensor data, etc.

When I started thinking about adding service checks in Amon, I took a look at what is available out there and I was really disappointed. In every monitoring tool, you have to deal with config files for every check and install dependencies/plugins on the remote machines. This is fine for old tools like Nagios, but really lazy for products designed in this decade that brand this as a feature and hype it up as "Infrastructure as a Code".

In Amon everything happens in the browser and it uses the underlying zeromq connection to distribute and execute your checks on the targeted machines. You can easily tweak and improve your scripts and the changes are applied in real-time. Targeting a different set of machines is as easy as selecting a tag or a server from a dropdown menu.

Health checks difference

New identity

Amon Logo evolution

The first logo for Amon was something I created for an hour in Photoshop and as it usually happens - it stuck for almost 4 years.

For Amon 5, I took the time to think about the brand and the logo and wanted to create something clean, simple and instantly recognizable.

I've experimented with different shapes and forms. My initial idea was to put the chart lines from the old logo on a solid background. Then I tried to create a more modern, soft oblique look. The next stage was moving away from the charts to something that represents a stream of data.

For the final variant, I decided to break the brand of Amon from the function and settle for something more simplistic.

Amon Logo experiments

What is next?

Amon continues to evolve and there are tons of new and exciting things already in the works.

Amon is no exception with the agent being written in Python. Python is great, because it is installed by default on every UNIX distro.

Things get tricky when you want to extend the agent and monitor third party apps like Redis or MySQL for example. In this scenario you have to deal with dependencies and things not always work out, especially on older distros.

In the last few months, I've started working on complete rewrite of the agent in Go, instead of Python. With Go, you can bundle all the dependencies and deploy a single binary, which works great across distros and different architectures.

I've started looking at some great third party, widely supported collector agents - like scollector, which is part of Bosun and Telegraf by the people behind InfluxDB. My idea is to make Amon compatible with these agents and give you the option to send metrics to the Amon web app.

Telegraf will support Amon in the next release and you will be able to collect performance metrics from Elasticsearch, haproxy, memcached, redisdb - a constantly growing list.

The best part is - Telegraf is a precompiled Go binary, making deployment a breeze.

With Amon, I am trying to eliminate these two steps and move everything to the browser. Thanks to the zeromq remote execution engine, I am one step closer to that goal. All the improvements I described in the steps above will make Amon a better product and serve a double purpose by making any future automation easier to implement.

My idea for the next few releases is to fully automate third party integrations and move any remaining configurations to the central Amon server.

Thanks for reading this short introduction to Amon 5. I really hope I've managed to outline how Amon has evolved through 2015 and what you can expect in the near future.

P.S If you are new to Amon and read the whole post - I want to thank you for your time and attention with this promo code: AMON5TENPERCENTOFF. You can use it to purchase any self-hosted license with a 10% discount.