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 might have CPU or disk usage status in addition to any link down status.

Resource status can be viewed in the Topology Viewer. An 'open' event is one with a severity other than 'clear'.

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 always has one of the following definitions:

  • clear
  • indeterminate
  • information
  • warning
  • minor
  • major
  • critical

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' to indicate an active issue that can 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 default fields of the alert used to look up resource matchTokens are resource.sourceId and resource.name. 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 as 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.

  • Note: If two different resources have the same matchTokens value, an event cannot be assigned to them unless they have been merged to become members of the same composite, or they have a parent-child partOf relationship.

Access scope

The scoping functions allows for preferential matching of IBM Cloud Pak for AIOps alerts. If similar resources and alerts in your environment exist in multiple different scopes, you can tag them with scope-specific information to allow a unique match to be made.

Such a scenario can occur (for example) under the following conditions:

  • The same applications are running in test, staging and production environments.
  • The same deployments are running in multiple namespaces in a single Kubernetes cluster.
  • The same components are running in cloned Openstack projects.
  • The same private IPs exist in multiple routing domains.

If an alert matches duplicate resources, a (case-insensitive) match of the alert scope against the resource scope is attempted.

Resource scope: Resources have an accessScopeTokens list property containing the following information:

  • The provider of the resource, as defined by the observer job
  • Optional additional scope supplied in the observer job’s Access Scope CSV string parameter
  • Scope explicitly added by some observers, such as the Kubernetes observer’s data_center and namespace job parameters

Alert scope: The alert fields to use for scope are configurable.

  • You can use the AIOPS_SCOPING_FIELDS variable defaults (accessScope, scopeId, location, cluster) to deuplicate resources when there are multiple matches on matchTokens.
  • The values of these fields are compared with the resource property accessScopeTokens , with preferential matching based on case-insensitive comparison.

Troubleshooting alert lookup failures:

  1. Check for a unique resource match at GET /resources?_filter=matchTokens:{alertFieldToLookup}
  2. If the alert is older than the resource, it might not have existed when the alert processing looked it up.