Operations | Monitoring | ITSM | DevOps | Cloud

Designing user interfaces for Icinga Web is always a bit of a balancing act. Once we’ve worked through all the technical and conceptual details of a new feature, it can be tough to step back and see things from a fresh user’s point of view. We as developers know too much — and that makes it hard to guess how others will understand what we’ve built.

This is a guest blogpost by Adam Sweet from the Icinga Partner Transitiv Technologies. Since this is a longer post, we added a tl;dr at the end. For many, host and application monitoring is an afterthought at the end of a project. Some people don’t think about monitoring at all until a few failures go unnoticed and a customer or end-user calls to ask why something isn’t working.

Modern applications are often built using microservices: Small, independent components that work together. This makes systems more flexible and scalable, but also harder to monitor. In this guide, we’ll explain what microservice monitoring is, why it’s different from traditional approaches, and how to do it effectively. Whether you’re starting from scratch or improving an existing setup, this article will help you monitor microservices with confidence.

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.