Status (and state)

Resources have specific statuses, and in turn each status has a state of open, clear or closed.

Status

A single status can affect multiple resources, and a single resource can have multiple different statuses. For example, a single link down event can generate the status for both the interface resource and the host resource; or a single host could have CPU or disk usage status in addition to any link down status.

Resource status can be viewed in the Topology Viewer, and can be set or retrieved via the topology service REST API. An 'open' event is one with a severity other than 'clear'.

You can access the Swagger documentation for 'status' at the following default link: https://localhost/1.0/topology/swagger/#/Status

Important: When modeling resources, you must consider Status assignment from events.

Tip: The Topology Service stores the event Severity, and nodes in the UI are colored based on severity, which is always one of the following:

clear
indeterminate
information
warning
minor
major
critical

Take a look at the severity icons in the topology viewer reference topic: Severity icons table

Status assignment

The status of a single resource can be supplied, alongside other resource properties, when creating or updating a resource. Alternatively, an event can generate the status of one or more resources.

Remember: A status always has one of the following three states:

Open: Always has a severity other than 'clear'; An active issue that may require your attention
Clear: Working as expected; Also has a severity of 'clear'
Closed: No longer active or relevant, a deleted event; Also has a severity of 'clear'

Status assignment from events

The status service receives events and tries to find matching resources in the topology service. A resource with no match tokens defined will not have events matched to it, but if found, the status of those resources is set from the event data. The assigned status depends on the following event data:

matchTokens: This property must be used to list any data that can identify (match) the resource.; Each field may be globally unique, or may be unique within the scope of a composition. In other words, a resource modeled via a composition relationship, such as partOf, can be distinguished from other children within the composition using these fields.; For example, either a globally unique and fully qualified domain name or IP address, or a locally unique interface name (that is, local within the scope of the host), can be used to identify the resource.
partOf composition relationship: The status service uses composition relationships to match fields that are unique only within the scope of a parent.; For example, an IP address can be used to find a main node, and an interface name can be used to identify an interface within that main node.