Icinga Dependency Views¶
Info
A paid subscription is required for Icinga Dependency Views. Get more information on icinga.com/subscription
Introduction¶
For those familiar with Icinga, the concept of hosts and services—and how they relate—is well established. A host can have multiple services, while a service cannot exist without an associated host. When a host becomes unavailable, all its services are automatically marked as unreachable. In this case, the service check results are no longer reliable. The actual issue lies with the host—referred to as the root problem—and should be addressed first. Notifications for the affected services are automatically suppressed. This built-in behavior, known as an implicit dependency, does not require any additional setup.
UI Components¶
Info
Some of the UI components described below are available in Icinga DB Web v1.2.0 and will be enhanced by Icinga Dependency Views. Use the corresponding tab to switch between variants.
Lists¶
Still, some environments require more granular configuration. A typical example involves network equipment: a router shouldn’t be configured as a service of a switch just to suppress its alerts when the switch goes offline. Instead, defining the router as a host and explicitly linking it to the switch as a dependency is the more appropriate approach. In such explicit dependencies, the child object (i.e., the router) will also become unreachable if its parent (i.e., the switch) is down. The parent’s impact on its children is immediately visible in the UI.
Details¶
This can be extended further. Imagine a group of servers relying on the router. Now, the dependency chain spans three levels: servers depend on the router, and the router depends on the switch. If the switch goes down, it renders both the router and the servers unreachable. To help identify the core issue, Icinga displays the root cause—here, the switch—at the top of each affected object’s detail view, regardless of how deep the dependency goes.
Below is the path leading to the root problem, relative to the current child.
Users can click on the root problem to open its detail view, where the most critically affected child objects are shown prominently. This helps in quickly gauging the overall impact. Additionally, related parent and child objects are organized in separate tabs for better clarity—especially useful in environments with many interconnected systems.
This component visualizes the current location in the dependency hierarchy with context about the nearest parents and children.
A brief mention should also be made of redundancy groups. While not everyone may be familiar with them, they share similarities with Icinga Business Process Modeling using the OR operator. Redundancy groups allow the expression of high availability setups within the dependency structure. As long as one member is functioning properly, the group is considered healthy. If all members fail, their dependent objects are marked as unreachable.
The Overview Effect¶
One unique aspect of Icinga Dependency Views is the dependency map. This fully interactive visualization brings all explicit dependencies into one centralized view. It supports zooming, panning, and direct navigation to detail views. Users can search and highlight objects, adjust the layout via the group-by function, and explore related components easily. The map is accessible from the sidebar and can also be quickly focused from within any parent or child detail view.
The following video shows it in action: (Enable full screen for a better experience.)
Getting Started¶
Got curious? You can try it out yourself in the Icinga Demo.
If you want to integrate Icinga Dependency Views in your own environment, check the installation section.