Operations | Monitoring | ITSM | DevOps | Cloud

Today, we are going to take a look at the Icinga 2 API and the various ways targets can be specified for different actions, such as querying information or scheduling downtimes. This post focuses on the API request payloads themselves and assumes some familiarity with sending requests to the Icinga 2 API. Please refer to our documentation for the missing details if you want to try the requests yourself. In general, specifying the objects to which an action applies works the same way for all actions.

Obviously nobody is disagreeing with this. It’s just that during ongoing development and while focusing on features and bug-fixes, testing often falls behind in priority, especially when developers would need to write tests for existing or legacy code, teams can be hesitant to invest the time. C++ applications have to run a diverse set up target environments, varying in OS, compilers, C/C++ standard libraries and dependency versions.

The Icinga Director configuration tool makes it easy to define monitoring objects through the web UI and deploy them to the Icinga 2 API. In this blog post, I’ll walk you through how to configure services in Icinga Director. If you haven’t used Icinga Director yet, take a look at our introduction. I assume that most of you are already familiar with Icinga 2 and have used the DSL to define objects.

Icinga DB Web Automation allows you to automate monitoring tasks and integrate them directly into your systems and workflows. It is possible to issue command actions without a browser. To do so, a form needs to be submitted by a tool such as cUrl. Every request you send follows the same permission rules and access restrictions defined in the web interface, so security and user roles still apply. Want to target specific hosts or services? Simply add filter parameters to the URL.

Monitoring with Icinga primarily focuses on servers and infrastructure. But there are also the people operating these systems from their workstations and laptops. If a server can be accessed from a machine with an outdated operating system, the patch level of the server becomes irrelevant.

Unlike menu items, dashboards in Icinga Web 2 currently can’t be shared across users. This is something we will implement in future versions, but for now users can only create dashboards for themselves. We don’t have an exact timeline for the dashboard sharing feature yet and our roadmap is already pretty packed for this year, so we won’t be tackling this until later next year.

Today is the day, we grant two products their long overdue maintenance. Maintenance always sounds boring, I hear you. But let me remind you that this also means we do and take care! And what this actually is all about: Now let’s see what each release offers!

We’re excited to share that Icinga now offers an improved way to view dependencies. With the releases of Icinga DB Web 1.2.0, Icinga DB 1.4.0, and Icinga 2.15.0 today, any dependencies you’ve set up in Icinga will now be visually represented. Additionally, we’re introducing a new enterprise feature called Icinga Dependency Views, available through an Icinga subscription. This component expands Icinga DB Web with even more powerful capabilities.

For decades, PHP has powered the web using a simple model: process a request, send a response, then shut down. This model, especially in the form of CGI and PHP-FPM, is easy to understand but increasingly inefficient for modern web demands.

In my previous blog post, I explained how to build lists using ipl-web widgets. That method will soon be deprecated due to its complexity. With the recent ipl-web release, we have introduced a simpler and more flexible approach to building lists, using a lightweight rendering interface and a single class, as described below.