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.