Attuor: Scalable monitoring

20 Jan 2020 | Development

Attuor: Scalable monitoring

Monitoring is an essential part of our industry. As an industry, we supply high-quality products to our customers, who always have to work. And if something doesn’t work, we want to know, and pronto !.

There are always a few products that we can find to monitor our services. We have monit , Nagios , Zabbix , Sensu , netdata , Icinga , PRTG . Plenty of choice, but never exactly what we are looking for.

Sensu

At the beginning of 2017, Tuxis opted for Sensu as its monitoring solution. Sensu does everything we wanted. There was a client that contacted a server, got its config there, and returned the results. We could configure overrides on the client if we wanted and on the server side we could link with our own https://admin.tuxis.nl/ code for authentication.

Unfortunately Sensu has decided to go for a new version building, which is considerably less attractive. A completely new version, making the old EndOfLife and thus unusable. p>

Enter Attuor

So we had to make new choices. We have not looked at Nagios and derivatives thereof. We knew we wanted something in the Sensu category. At the time, we chose Sensu because it did (almost) exactly what we thought we wanted and wanted to build. Programming was not necessary due to the presence of Sensu, but now it is.

And so we set to work on that, project Attuor. Attuor is Latin for ‘observe’. And that’s what Attuor does. The concept is that the basis remains very simple and makes use of ‘industry standards’. The Proof Of Concept shows that very well.

We know that many other companies see the same challenges as we do. Open source software is increasingly a means to turnover, instead of a solution to your own problem that you would like to share with others. We will not deny that we want to be proud of being the driving force behind Attuor. But Attuor will always remain open source and free. Attuor will also not get an ‘enterprise’ version.

Properties

  • Fully Python based
    Python is a language that can run on almost any device
  • For checks we use the Nagios logic
    It seems that Nagios has set a standard for checks. In terms of exit codes, output, performance output. By adopting this, all Nagios checks are directly usable for Attuor
  • Client and Server communicate via HTTP (s). Client pushes results to the server.
    So we don’t need to poke holes in firewalls for strange ports. Virus scanners ‘just’ see JSON going over the connection. So it will work pretty much anywhere
  • The client uses as few libraries as possible. This makes it very portable across the different OSes.
  • The server publishes messages to a message broker (Redis). So we will not easily get into the situation that the server does not keep up. Subscribers on the Redis channel can execute all logic and track status

Can we count on your help?

I have now built a PoC. It starts and does some things. But Attuor is a long way off. We will be working hard on it in the coming weeks and we hope that there are people who want to help improve and expand it. You can help out at https://gitlab.tuxis.nl/oss_public/attuor.