Here it is, version 0.9 of Attuor!

Meanwhile, we have been working hard on a new project. A project that is not so exciting at first sight. In fact, there are already many solutions for it. However, these solutions do not do everything you need them to. We have chosen to build it as Open-Source. Tuxis makes a lot of use of Open Source software and this is an opportunity to do something in return. Together with students of the CHE and our sister company CodeBee we started and there is now a nice repo.

Attuor

Monitoring. We are talking about a monitoring application which we have called Attuor. That doesn't seem very exciting, boring even, until you list the requirements. After all, monitoring is an application that MUST work. And that makes deploying a cloud service tricky. How can you be certain that the service is running? You can't monitor them! The fact that their website works says nothing about actual monitoring. ??

Then you also want to be able to decide what is monitored. You don't want to be bothered with firewalls. So, all systems that intend to retrieve data from the systems to be monitored are excluded.

Then there is the price. Billing per server? Not very amusing if you have to monitor hundreds of servers. Per service then? Same thing.

Build it yourself then? No, of course not. And with open source, you don't have to.

What does Attuor have to be able to do? That is quite a list:

• Scalable. The number of things you want to monitor must be "infinite";
• Monitoring client pushes data, so you don't have to deal with firewalls;
• Universal. Windows, Linux, Mac...RouterOS. You must be able to monitor all kinds of things;
• Meaningful notifications and therefore extensive control over the notifications;
• Freedom in the manner of notifications so that Pushover, Signal, E-mail can be used;
• Expandable with new features. In other words, open data and API.

These requirements have been drawn up from past experience. We once started with a server that monitors clients (the part to be monitored). The server then asked what the status of the client was, and the client had to be accessible to the server. One server can only poll a maximum number of clients. You can add an extra server, but then you have to divide the clients over the servers and that becomes cumbersome. However, having several servers listening is easy to solve with load balancing. And the client only needs internet access from inside to outside. Just like every tablet, phone and PC already has it. So, that usually works.

Pointless reports

Driving on errors. This works best provided that the notifications you receive really are meaningful. Otherwise, you will ignore notifications eventually and important notifications may be missed.

Pointless notifications are a major frustration. That one server complains about that one thing, but that's logical (backups always run around that time or something) and not a problem. But yes, it does wake you up all the time. So, what if you could easily mute that one notification for that recurring period. Or for maintenance, or holidays.

Also in the case of a cluster, for example. A cluster uses one storage method and all servers use it. If something goes wrong, then it can happen that all servers report an error. After all, the storage is not available to them. So, there will be 30 reports. By linking reports, this becomes one report.

Open for suggestions

There is a demo: https://demo.attuor.net/ and a website: https://www.attuor.net/.

Would you like to take a look at it and give us your ideas below? Then we can make feature requests and create a nice monitoring product. And of course you can help us build it.