Operations | Monitoring | ITSM | DevOps | Cloud

When you work closely with Icinga Web 2, developing modules, building dashboards, poking around the internals, you naturally pick up on features that most users never think about. Some are usability improvements that deserve more attention than they get. Others are developer conveniences that turn out to be genuinely useful in the right user situation too. They’re just the kind of thing that rarely makes it into the getting-started guide. Not all of these will apply to your daily workflow.

A container reporting “up” tells you the process is running, not that the workload is healthy – but that caveat is true of any service, on a container or a bare server.

Most form fields ask users for a single value like a name, an email, or a date. But some need a list of values. A plain text input with comma-separated values can technically do the job, but it gives no feedback while typing, no suggestions, and one invalid entry rejects the whole field. The ipl-web TermInput solves this problem. Each value becomes a separate term with its own validation; terms can be enriched, and the input even supports suggestions.

If you’ve been using Icinga 2 for a while, you probably know the built-in checks cover a lot of ground: disk space, CPU, memory, ping. But sooner or later you’ll run into something specific to your setup that no existing plugin handles. That’s where writing your own plugin comes in. The good news? It’s simpler than it sounds. Icinga 2 doesn’t care what language your plugin is written in. It just runs the script, reads the exit code, and displays the output. That’s it.

Today, we are going to look at a few things related to handling secrets. While Icinga 2 has no dedicated mechanisms for secret handling, there are a few tricks you can do with standard features. This is not meant as a step-by-step tutorial, but rather as an inspiration where you can adopt the ideas that make sense in your setup.

Lots of big companies lock down their IT infrastructure in the internal network, sometimes they even use only locally mirrored repositories. I totally understand this, especially since our CVE-2024-49369. Nowadays, when LLMs find security holes even in OpenBSD, you definitely shouldn’t expose any services to the public without need.

With the new NETGEAR AV Line monitoring plugin, you can easily monitor NETGEAR AV Line devices in Icinga 2. This lightweight yet powerful Go-based tool communicates directly with the devices’ API and provides clear status values – including perfdata.

The OTLPMetricsWriter is a new Icinga 2 feature available since v2.16 that exports check plugin performance data as OpenTelemetry-compliant metrics via the OTLP HTTP protocol. With a single configuration object, it connects Icinga 2 to any OTLP-compatible backend like Prometheus, Grafana Mimir, Datadog, Elasticsearch, VictoriaMetrics, and more.

We are happy to announce the release of two new versions of Icinga 2 today, 2.16.0 and 2.15.3. The first one includes some new features highlighted below, as well as a number of bug fixes and other improvements. The latter one is a small bug fix release that brings some of the other fixes included in 2.16.0 to the 2.15.x branch as well.

CMake tends to have a bad reputation for being to complex and convoluted, but often that notion stems from very old versions of CMake. Sure, CMake is a Turing-complete scripting language, but that is really needed for an ecosystem as complex as that of C and C++. And as Greenspun’s tenth rule of programming goes: There are countless build-systems and build-system generators for the C/C++ ecosystem. Some of them tried to use a simple, declarative approach.