I'm a dev at Icinga and I recently shipped an OTLP Metrics Writer for Icinga 2. Going in, I had basically zero prior OTel experience. Just want to give you some insights into the last four months to share my experience:

My first instinct was to use the OTel C++ SDK - it's well-established and had everything we needed. But integrating it with our existing codebase turned out to be much harder than expected, and honestly more complex than our use case required. After failing to get it working in a reasonable timeframe, I switched to a tiny OTLP client built on Boost.Beast, which we already used elsewhere in the codebase.

For one, we already used Boost.Beast in our codebase, so it was a no-brainer to use it for the OTLP client as well. Additionally, since the OTel proto spec require proto3 language syntax, we would have had to build the entire OTel SDK from source in order to use our writer with the latest C++ SDK on RHEL 8 and 9 systems, which would not have been feasible for us.

But I didn't see this one coming: proto3 isn't supported by the default protoc on RHEL 8/9, Amazon Linux 2, Debian 11, and Ubuntu 22.04. Two options: ship our own protoc binary, or just disable the writer there. Since most of our customers run RHEL-based systems, disabling wasn't an option - so we ended up packaging our own Protobuf compiler for RHEL 8 and 9. For Amazon Linux 2, Debian 11, and Ubuntu 22.04, the writer is currently unavailable unless you build from source.

In OTel, a service presents itself and its metrics are associated with that service. Icinga doesn't work that way. it's not the one being monitored, it's acting as a proxy for the checkables it monitors. We went back and forth a lot on this one. How do you even represent Nagios-style check results in a way that makes sense in OTel? Shoutout to Markus Opolka (on Github) who provided a lot of useful input on this part.

And just before final reviews, my colleague Alvar Penning (Github) found a severe bug in the OTLP client that caused Icinga 2 to hang on reload. Major refactoring, significant delay. The embarrassing part: the bug was trivial to trigger. If I had reloaded Icinga 2 even once in my dev environment during development, I would have caught it. :P Won't make that mistake again.

__

Four months total (longer than expected), mostly because starting from scratch with OTel means working through a lot of documentation before you can write anything meaningful. Also came out the other end knowing a lot more about Protocol Buffers than I expected.

Happy to answer questions about the metrics mapping or the proto3 packaging approach, or anything else that comes to your mind!

Yonas/ Icinga

Icinga Exchange is shutting down on July 1, 2026.

Usage has been low for a while. What was still active were the plugin listings - and those are now at icinga.com/plugins.
The new location also adds something Exchange didn't have: plugins are grouped by what you're monitoring. (That is just the default, you can still search by name, category, vendor, ...)
So if you want to check Apache2, there's a dedicated page with relevant plugins listed: mod_status, balancer pool, mod_jk, mod_qos, version checks, and so on.
Instead of having to search and filter for what you want to monitor, there is a handy list of suggestions for you.

What this means practically:

• Most plugins from Icinga Exchange have already been moved over.
• If you maintain one that hasn't made it across yet (or you have one in mind that is still missing), there is a submit button on the page.
• After July 1 exchange.icinga.com URLs will stop working. Update any bookmarks or internal links.

If you've contributed to Icinga Exchange: thank you. The plugins there have been in use in real environments, and we'd like to see them continue to from their new location.

If you have questions or need help migrating a plugin, reply here or contact us and we'll sort it out.

We recently added native OTLP metrics export to Icinga 2 (in v2.16), which means a monitoring system with roots deep in the Nagios ecosystem can now push plugin perfdata directly into modern OTel pipelines and backends. (Yay!)

One of the weirder things about working on monitoring software in 2026 has been realizing that eventually everything becomes an OpenTelemetry integration project.

A lot of the implementation work that we did was basically translating classic infrastructure monitoring concepts into the OpenTelemetry world:
perfdata -> OTel metrics
thresholds -> metric streams
host/service metadata -> resource attributes
HA monitoring clusters -> avoiding duplicate telemetry

What stood out to me most during the project is how OTLP increasingly feels less like an "observability standard" and more like general purpose telemetry infrastructure that everything eventually has to speak.

Even traditional monitoring systems now end up integrating with tools like Prometheus, Grafana Mimir, OpenSearch, ...

I assume you lot here are also working on monitoring/infra tooling, are you seeing the same thing?

Asking here is probably skewing the answers a bit, but is OTLP basically becoming the universal interoperability layer now?

And if you’ve integrated older systems into OTel pipelines, I’d be interested what parts were most awkward for you and how you went about solving this.

Edit:
In case you’re interested, we have a longer writeup with all the implementation details (and significantly more marketing terminology than I would use on Reddit): https://icinga.com/blog/opentelemetry-integration/

Hallo in die Runde! Nach Absprache mit den Moderatoren möchten wir gerne auf unser Event im Rahmen der Nürnberg Digital Festivals aufmerksam machen. 

Wer Lust hat, sich zu den Themen Open Source, Digitale Souveränität, Cloud und AI (juhu, Buzzword) auszutauschen und den Abend am 23.06 ausklingen zu lassen, ist herzlich eingeladen. 

Für uns stehen ganz klar das Zusammenkommen und der Austausch im Mittelpunkt, für all diejenigen, bei denen im Arbeitsalltag die Themen relevant sind.

Meldet euch gerne hier an:

https://nuernberg.digital/de/events/2026/open-source-night-ai-digitale-souveraenitaet-cloud

/ Simona von Icinga

Hey everyone,

we’re hosting another webinar soon:

This time it’s focused on Windows monitoring with Icinga. Nowadays mixed infrastructure is the norm. While a lot of your architecture might be Linux and in the cloud, there is probably also a Windows Server or two running as well.

We’ll walk through how to get Icinga for Windows up and running and how to actually use it in a real setup.

Date: April 23, 2026
Time: 3 PM - 4 PM CEST

In this session, we’ll cover:

• How to install Icinga for Windows from scratch
• A tour of the core features and components of Icinga for Windows
• Setting up essential Windows checks (CPU, memory, disk, services, and more)
• Connecting Windows agents to your Icinga monitoring environment
• Best practices for keeping your Windows monitoring reliable and maintainable
• Interactive Q&A session

It’s aimed at both people getting started and those who want to improve their current setup.

If you’re interested, you can check out the details and register here.

Everything from the UI to the libraries behind it.

Raising the PHP version to 8.5 gave us room to modernize the foundation with strict typing, new packages, and a more predictable API.

We also moved all affected modules from GPL v2 to v3.

While we were already in the spring cleaning mood and making changes, we cleaned up our libraries for Icinga Web development, resulting in two new packages: icinga/zf1 our own lean fork of the Zend Framework 1, and icinga-php-legacy as a new home for the gipfl libraries to replace the incubator.

tl;dr:

- Modules updated across the board
- Monitoring module moves out into maintenance mode as a standalone package
- Two release tracks for better compatibility

If you maintain custom modules, make sure to review the upgrade notes.

Details and how to upgrade: https://icinga.com/blog/release-icinga-web-ecosystem/