Operations | Monitoring | ITSM | DevOps | Cloud

The raw data imported from the external sources (CSV, SQL, REST API, LDAP, etc.) is usually not in the right format. Hence, they have to be processed or converted before they are used to modify objects using synchronization rules. To do this, Icinga Director provides different property modifiers. There are many property modifiers provided by Icinga Director.

There are many ways to interact with the data that Icinga 2 collects, processes, and produces. The most common is probably Icinga Web, which displays checks in all the colors of a traffic light. Icinga 2 also comes with several metrics or performance data writers. But that is not all. Icinga 2 has open interfaces to integrate all kinds of third-party tools if one is not afraid to write a little glue code.

If you’re reading this, chances are high you’re looking for a PRTG alternative and considering switching from Paessler PRTG to Icinga. Maybe it’s the rising costs of PRTG, or maybe you want a monitoring solution that gives you more flexibility and control. Whatever your reason, I want to give you an honest, technical perspective on what that switch entails. I’m not here to tell you PRTG is bad – far from it.

SSL/TLS certificates are critical for secure communication, and keeping track of their expiration is essential. Until now, Let’s Encrypt has sent email notifications when certificates were about to expire. However, as of June 2025, Let’s Encrypt will discontinue these expiration emails. This change could lead to expired certificates going unnoticed, potentially causing security risks and downtime.

Imagine you have one more special thing to monitor. While our Icinga 2 can observe infrastructure of almost any size, it still needs a plugin for each kind of check. Unfortunately not every command meets the monitoring plugin API: exit code 0-3 (ok, warning, critical, unknown), performance data, etc. E.g. often programs exit with 1 in case of a fatal error, which is considered just a warning by Icinga.

When working with systemd services in Linux, you might encounter situations where multiple instances of a service need to be managed dynamically. When I had to develop a solution to monitor multiple Kubernetes clusters with Icinga for Kubernetes, I ran into exactly this challenge.

The fundamentals of Icinga 2 are check plugins. They are being executed and their return value is mapped to either Host or Service objects. Everything else follows on top. These check plugins can be either from the Monitoring Plugins or custom. While their origin does not matter, they are the building blocks of an Icinga monitoring stack. If a plugin goes CRITICAL, Icinga 2 alerts the sysadmin.

Today we are happy to announce that we released Icinga for Windows v1.13.0 a couple of days ago. We have already talked about the changes coming to v1.13.0 with the beta blog-post last year in more depth, and will focus only on some core changes here.

Icinga is an open-source project, but it’s only become the product we like to use thanks to co-development, brainstorming and suggestions from the community. That’s why we created a platform in the past to facilitate the exchange of custom implementations like check plug-ins, styles, extensions and bridges to third-party systems. We’re talking about our Exchange Portal, of course.

In today’s fast-paced digital landscape, businesses are moving their operations to the cloud more than ever before. This shift brings incredible benefits like scalability, flexibility, and cost-efficiency. While it does introduce various common cloud monitoring challenges, there are effective solutions that organizations can implement to ensure optimal performance, security, and cost control.