It has been a long time and a long journey for Aiki Linux, but sadly things must come to an end.

Due to many factors, some of our business ventures were not as successful as we hoped for and we had to forgo those, one of those is our partnership with Icinga, not due to any bad blood or any doubt in the product, quite the opposite, it is just the the venture did not end up profitable to us.

We will be closing Aiki Linux for future commercial activity at the start of 2020.

We thank all that worked with us and taught us along the way.

We just came back from the @icinga #icingacamp #berlin 2019 and it has been a great day of meeting new people and hearing great talks about how people use Icinga and what the road map both for community development and actual code features will be.

We are very excited about the upcoming reporting module and the IcingaDB feature that will help speed up the IcingaWeb presentation and help elevate the slowness that the IDO added to the flow.

Also the announcement for the 2 day Icinga conference in Amsterdam next year is an exciting thing, it is great to see a project we have been involved with from early stages grow so much and to such a success.

We finished the first Icinga 2 Fundamentals course held in London , So far the course has proved very useful to our students and has shown them how to use Icinga in ways that were confusing before.

We covered some basic subjects outside the scope of the course to help some of the students become better acquainted with the Linux operating system.

The course pace varied as in the first day we went through a large part of the material, but as we moved to the “lab heavy” sections we slowed down, but we managed to overcome and achieve the goals.

A subject that came up repeatedly in the course is the request for training on the Icinga Director , which is a tool many users want to incorporate in to their system.

We believe that we might add another day to the next training course on that subject …

A client asked to evaluate Prometheus Monitoring solution for it’s AWS infrastructure, so after 2 days of reading and testing the Prometheus system we can say several things about the tool:

1. The modular build of the application is confusing at first and can be challenging to someone that is used to have the core product handle all the functions (comparison, alerting , test logic etc’), but once you are able to adjust your way of thinking to it, it makes sense and easy to see the logical division.
2. Another “shift” from the Nagios approach is the way that Prometheus is evaluating when and how to alert. In Nagios and any system that has evolved from it’s school of thought the evaluation of the triggering is done on the individual data check (service), where as in Prometheus the individual check is irrelevant,the alerting logic is where the evaluation is done, based on multiple dividers: node names,logical grouping, the data point relative to time series and you can also add arithmetic calculation for prediction alerting based on historical data.
3. The Prometheus clients capture many data points on your remote nodes and require very simple configuration for the server to read the data. The advantages of the “pull” (or “Active” to those coming from Nagios evolved systems) method is apparent as you can have many servers read the data from a single client for redundancy and be fast aware when a remote agent is no longer responding.
4. A fully evolved query language that allows building complex logic for parsing and slicing the data to present the metric you wish to get.

With those good points (and there are more)  there are some issues that seem to be lacking :

1. The built in interface does not update in a regular intervals, to achieve a visualisation that keeps the graphs current you need to use a 3rd party tool, the recommended one is Grafana, which already has the capability to use Prometheus as a data backend for querying.
2. The modular build of the product may be an issue when the internal parts fail (alertmanager) as you will not be aware of the issue, as no alerts will be sent and the only indication will be the dashboard, granted you may define many alert manager instances to eliminate that issue, but for small implementation that still feels like a problem.
3. “More is Less”: the abundant metrics supplied by the client can be daunting to begin with and understanding how to handle and use those for a basic monitoring setup can be overwhelming, causing the novice user to shy away and seek “simpler” solutions.

There are many more points that can be said both as Pro’s and Con’s on the system, as I am sure that many in the Monitoring world will point out, as a whole Prometheus provides a good solid tool, and as always, you need to consider 2 points when you choose a monitoring tool :

1. What do you want to achieve?
2. How much time you want to invest (Time = Money)  ?

When those two are defined and agreed upon, Prometheus could be one of the tools for consideration.

Working on a presentation for the FlossUK talk about the Metric led development I encountered some issues in the Ansible playbook that stopped the created Icinga from executing the remote checks via nrpe.

As I am learning Ansible and wanted to make the demo work (which can be found here ) I fixed the issue got the demo working.

With the move that Icinga did to use GitHub as the code repository, submitting the fix was an easy step and makes community contributions that much easier.

I also noticed that some features that I wanted were missing so I am planning to take up those tasks ( like having Icingaweb2 playbook work on Ubuntu) and try to get them working for the benefit of everyone.

Aiki Linux have been accepted to speak in the Floss UK this March.

We will be giving two talks:

• The evolution of Icinga , from a Nagios clone to standing on it’s own.
• Metric led development – Or, when to start monitoring

Come here us speak.