Operations | Monitoring | ITSM | DevOps | Cloud

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.

Icinga and Checkmk are the two open-source monitoring tools that turn up most often on the same shortlist. Both monitor IT infrastructure, and on a feature list they look close to interchangeable. In practice they are built on different assumptions, and those assumptions decide which one fits. This page works through the differences section by section: setup, customization, integrations, Windows, distributed monitoring, multi-tenancy, licensing, and cost.

Running Icinga 2 in a rootless Podman container is pretty straightforward, it works just the same as on Docker, so all the examples on our Docker Hub page work as expected. For example this one to generate certificates and initialize the master configuration: Same as with mounting some existing configuration into the container: But once you want to combine the two, for example to store the certificates on the host and mount them into the container, generating or renewing certificates will fail.

The ability to log into all corporate applications with one username and password is pretty convenient, even compared to a password manager. As a benefit, the IT department can centrally enforce one desired two-factor auth mechanism. Now we, Icinga, also provide a so-called OpenID Connect integration for single sign-on. By the end of this text you’ll know how to connect your Icinga Web instance to the ID provider of your choice.

Icinga Director’s CLI commands have supported import sources and sync rules for a long time, which includes listing, checking and running them. Before Icinga Director v1.11.6 two things you couldn’t do from the CLI, though, were narrowing a health check down to a single object, or deleting an import source or sync rule without opening the web UI. I’ll walk through both, using examples.

Guest post by Markus Opolka, Senior Consultant at NETWAYS. Originally published on the NETWAYS blog as “Icinga und Prometheus integrieren” and “Alertmanager-Icinga-Bridge – Ein Signalilo Fork”, combined and adapted for the Icinga blog with permission. Icinga and Prometheus are both great monitoring solutions, however, their focus is different. In this article, we look at how to integrate both monitoring systems and utilize the strengths of both tools.

Icinga Web 2 now ships a PasswordPolicyHook that gives administrators and module developers full control over what constitutes a valid password. Instead of hard-coding a single rule set for every deployment, the hook makes password validation an extension point: any module can register a policy, admins select the active one from the configuration UI, and Icinga Web 2 enforces it everywhere a local password is set or changed.