Building custom topology

Edit online

Custom topology can be added to the system by using the two SDK observers, File and REST. These resources can be merged with data from the other observers.

Topology model

The basic topology model consists of the following items:

  • Resources can be used to represent anything, such as network elements, software, and people.

  • Edges are the relationships between resources.

  • Groups collect resources to allow them to be easily viewed and to provide topological correlation.

  • Applications or services are a collection of groups.

  • Status indicates that alarms are mapped to a resource.

Topology model partOf edges

The partOf composition edge from child resources to parents is a special case. This edge is not visible in the resource management view and associated configuration. The edge is used for Host to host and Element to host resource management views. The edge is considered when you match the alerts to resources. An alert that is matched against a part of the child is also seen against the parent.

The partOf edges have the following limitations:

  • A partOf relationship is a relationship from many children to a single parent.

    • A child cannot have multiple parents.

  • A parent cannot be partOf another parent.

Resource lifecycle

Each resource or group within the scope of a provider has a lifecycle that is managed by the job that modeled it. Load jobs are expected to take snapshots of the entire system. If a load job finds the resources X, Y, and Z on one run, and the next run finds resources A, B, and X, then Y and Z are deleted. The listen jobs need to explicitly delete resources.

Resource lifecycle APIs:

  • The insertReplace PUT method removes any properties that are not listed.

    • The exception is a placeholder with only uniqueId and _references properties.

  • The insertUpdate POST method adds to the existing properties of the Topology model.

Edge lifecycle

To maintain the edge lifecycle, keep the following items in mind:
  • Model edges by using _references nested within a resource.
  • Always use insertReplace PUT method semantics.
  • Model edges in a consistent direction.
  • Edge type and direction per resource provides the replace scope.
  • With the insertReplace PUT method, all the edges of the same edgeType and direction are replaced.
  • Direction is implied by _toUniqueId or _fromUniqueId, or use using _direction to remove all edges.
  • The edge lifecycle can be maintained independently of properties by using a payload with only the uniqueId and _references properties.

Edge deletion

Edges can be deleted in multiple ways.

For example, if a resource X is defined with an outgoing uses edge to another:
"_references":[{"_edgeType":"uses","_toUniqueId":"Y"}]}
This edge is deleted if:
  • Either end – X or Y – is deleted.
  • X is replaced with:
    "_references":[{"_edgeType":"uses","_toUniqueId":"not Y"}]
  • Y is replaced with:
    "_references":[{"_edgeType":"uses","_fromUniqueId":"not X"}]
  • X is replaced with:
    "_references":[{"_edgeType":"uses",”_direction":"out"}]
  • Y is replaced with
    "_references":[{"_edgeType":"uses",”_direction":”in"}]
Note: The last two examples show the syntax to remove all the edges of that type and direction.