Composite Status

Combine the state of several monitored objects into a single status, using critical, redundant or influential groups - and nest those statuses to describe a whole service.

Composite Status is an atlas node representing an aggregated state of the group of other status objects. The status depends on group type, which can be critical, redundant, or influential.

Although the above statement is perfectly valid and exactly describes how the Composite Status, it doesn't answer why and when you might need it.

Because the names of object states are different, we need to clarify them.

error is a synonym for Down or Critical.
success is a synonym for OK.

Let's start with an example.

As the user, I want to see the internal system's status, which depends on two internet connections, DNS, AD, and the web server. Internet connections are redundant, but all other elements are critical to the system.

You might decide to create a Business Status Node and add each element to the appropriate group in such a case. As the node can be part of another Business Status, you can even build up a tree of statuses.

Besides placing such status on the dashboard map and alerting, you can document logical dependencies of process elements.

The overall status of a composite is calculated from the objects you add to it, according to an Aggregation Mode you choose. The order of statuses is Unknown OK Warning Error.

Aggregation Modes

The mode decides how the individual states combine. Four are available.

Worst status wins: The composite follows the worst state of any object. One object down or critical makes the composite down/critical. Tick Critical only to ignore warning states entirely, so that nothing short of down/critical counts.
Redundant availability: The composite shows Warning if any object is in warning or down/critical, and becomes down/critical only when every object is down/critical. Use it where a single failure is not fatal.
Advisory only: Objects can raise the composite to Warning but never to down/critical. Use it for dependencies that matter but should not decide availability. Tick Critical only to raise that warning solely when an object is down/critical.
Advanced rules: Assign each object independently to Critical, Redundancy or Advisory. Each group then behaves as its matching mode above, and the composite takes the worst result across the three. Use it when one service has both must-not-fail parts and redundant ones.

Weighting a Redundant Group

Under Redundant availability, tick Use Importance & thresholds to let objects count unequally. Each object contributes according to its Impact weight, so the composite is driven by how much of the total weight is down rather than by how many objects are down.

Two settings then control the result — Warning at and Critical at, both expressed as percentage degradation. Only down/critical states are measured in this mode; warnings are ignored.

The two threshold lists are built from the weights actually present on the list, so they offer only percentages that a real combination of failures can produce. Where nothing has been weighted yet they fall back to 25%, 50%, 75% and 100%.

composite-elements

What Can Be an Element

A group is not limited to whole nodes. Anything NetCrunch tracks a status for can be added as an element, which is what lets a composite describe a service at the granularity the service actually has — a single interface on a router, one sensor on a server, one active alert.

The Add button offers seven kinds directly, with three more grouped under Advanced.

Node: The overall status of a monitored node.
Network Service: A single monitored service on a node, such as HTTP or DNS.
Sensor: A monitoring sensor on a node.
Monitoring Pack: The aggregate status of a monitoring pack applied to a node.
Network Interface: One network interface, rather than the whole device carrying it.
Composite or Group Status: Another composite status. This is what builds the tree — a composite for a service can be assembled from composites for the subsystems it depends on.
Active Alert (Alarm): Whether one specific alert on a node is currently open. You pick the alert out of that node's own alert policy and it brings its severity with it, shown beside each entry in the list. Only alerts that can actually become active are offered, and correlated secondary alerts are left out.

Under Advanced:

IP SLA/NQA Sensor: The status of an IP SLA or NQA sensor.
Sensor Status Object: An individual object reported by a sensor, where the sensor tracks many — a single scope on a DHCP server, one tunnel on a firewall.
SNMP Value: A value read over SNMP, including the status counters whose numeric values map to named states.

A composite cannot depend on itself, directly or indirectly. Adding the node's own composite status is refused outright, and so is any addition that would close a loop further up the chain — the check follows the whole dependency graph, not just the immediate parent.

When picking elements you can filter the node list — by status, template and similar — which matters on a large atlas where the object you want is one of many thousands.

Building a Tree

Because a composite status can be an element of another composite status, services compose. A Customer Portal composite can depend on Database Cluster, Authentication and Web Front End composites, each with its own elements and its own group logic, and each independently useful on a map or as an alert source.

That tree is also what a Business Service View draws. See Business Service Views.

NetCrunch Monitoring Objects
Everything NetCrunch monitors is an object with a state - nodes, interfaces, services, sensors, alerts, and the statuses calculated from them. Knowing which object you are looking at tells you what you can alert on, put on a dashboard, and roll up into a service status.

businessbusiness statuscompositeservice treestatus element