This documentation and the Cisco Observability Platform functionalities it describes are subject to change. Data saved on the platform may disappear and APIs may change without notice.

Changing the Topology Context of Template Elements

When templates are nested into composite UIs, the data for child templates usually comes from the same entity or entity set (in other words, the same topology context) as the data for the parent template. In order to bind the child template to a different topology context, you can enclose it in one of these building blocks:

  • join
  • related
  • relatedSet
  • union

join

join sets the child topology context to a join of the current topology context and related entities. The child templates can order data from both. For example:

{
  "key": "destination",
  "instanceOf": "join",
  "path": "out(common:interaction_to).to(apm:service, apm:backend)",
  "element": {
    "instanceOf": "elements",
    ...
  }
}

related sets the child topology context to a separate set of entities related to each entity of the parent topology context. For example:

{
  "instanceOf": "related",
  "path": "out.to(infra:network_interface)",
  "element": {
    "key": "hostNetworkPacketsDroppedOutByInterface",
    "instanceOf": "cartesian",
    ...
  }
}

relatedSet

relatedSet sets the child topology context to the set of all entities related to any entity of the parent topology context. For example:

{
  "instanceOf": "relatedSet",
  "path": "in.from(k8s:node)",
  "element": {
    "instanceOf": "cardinality",
    ...
  }
}

union

union sets the child topology to a union of the entity set of the parent topology context and one or more sets of related entities (as specified in the paths attribute). For example:

{
    "name": "customBackendGraph",
    "target": "apm:backend",
    "instanceOf": "union",
    "paths": [
      "in(common:interaction_to).from(apm:request)[attributes(\"interaction.context.id\") = ''].out(common:interaction_from).to(apm:service)"
    ],
    "element": {
    ...
  }
}