Operations | Monitoring | ITSM | DevOps | Cloud

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.

If you run a managed service provider, your RMM software is the backbone of daily operations. Remote management, patch cycles, ticketing workflows – it handles the essentials. But if you’re monitoring more than a few dozen client environments, you’ve likely noticed that monitoring and management are not the same thing. And that difference matters more the larger you grow. This post is not about replacing your RMM.

PHP has evolved over the years and has become a lot more reliable, faster and refined. And with the release of PHP 8, which contained many features (named arguments, union types, attributes, constructor property promotion, match expressions, the null safe operator (?->) etc) and optimizations (JIT compiler), PHP has become more faster and cleaner. There are many more improvements and interesting features in the later versions of PHP 8. The 4 features I now rely on and wish PHP had introduced much earlier.

When hosting in a secure or corporate environment, Internet access is often restricted or blocked completely. While this makes sense from a security point of view, this introduces some challenges. For one, getting software packages. There are usually two approaches to the package problem in such an environment: Either allow a certain package mirror in the firewall, or run your own mirror within the restricted environment with access to another package server to mirror packages from.