Operations | Monitoring | ITSM | DevOps | Cloud

Sometimes you just want to fetch all Icinga 2 objects of a given type from the API and do something with them. Then you notice that Icinga 2’s memory usage jumps up with every large request and never comes back down, as if each HTTP request leaked a huge chunk of memory. And once enough of these requests run in parallel, no matter how much RAM the machine has, Icinga 2 runs out of memory and crashes. Here’s what was really going on, and how we fixed it in Icinga 2 v2.16.

Icinga Notifications 1.0.0 is here: the right people, informed at the right time. Monitoring only helps if the right person hears about a problem at the right moment. That is what Icinga Notifications does. Version 1.0.0 is the first stable release, and we consider it ready for production use. With it, you decide who gets notified, how and when. You also see at a glance which problems are open and who takes care of them. In this post, we show you what this means for your daily work and how to get started.

Clusters get retired. A test cluster is torn down, a workload moves to a new environment, a provider contract ends. Icinga for Kubernetes does not know about any of that. Since v0.3.0, several clusters can write into one shared database, and Icinga for Kubernetes Web shows them side by side. But stopping or uninstalling the daemon for a cluster leaves all of its data in place.

What happens when you treat the service grid like a screen. Every now and then a side project starts as one thing and quietly turns into something much sillier. Mine started as a way to get more comfortable with the Icinga 2 configuration. It ended with a question nobody asked: can the service grid in Icinga Web play GIFs? Spoiler: kind of. And on the way, I learned a lot about how Icinga 2, Icinga DB and Icinga Web work together.

Monitoring as code means defining hosts, checks, thresholds and notification rules in version-controlled files, and deploying them through review and automated validation, the same way infrastructure as code handles servers and networks. With Icinga you can do this with plain configuration files in Git, the Ansible collection maintained by NETWAYS, the Puppet modules maintained by Vox Pupuli, the Icinga Director, or the REST API from tools such as Terraform.

An Icinga Web filter is a chain of conditions, each one a column, an operator, and a value, combined with & and |. You type it into the search bar of Icinga DB Web, but the same syntax shows up in URLs, dashboards, role restrictions, and the event rules of Icinga Notifications Web. This post covers the whole thing: operators, wildcards, grouping, and filtering all the way down into arrays and dictionaries.

When I first tried Claude Design, shortly after it was released, I wasn’t impressed. As an every day Figma user, I missed the option to manipulate elements directly, especially for fine tuning details. What I overlooked at that point was the fact that it is really good at generating different options efficiently. Most of them aren’t usable, but getting these options suggested helps when exploring and combining different approaches and ideas.

Icinga Director 1.12.0 is out now. This release finally gives custom variables full support for dictionaries, fixes a long standing bug that broke user group restores, and raises the module’s minimum requirements to match the rest of the Icinga Web ecosystem. You can find issues and feature requests related to this release on our roadmap.