Skip to content

Custom Topology#

The topology model is extensible and based on template configurations.

Configure topology ingestion from a source that is not yet covered out-of-the-box is done directly from the configuration UI.


The source can be the Unryo database (if you ingested data to Unryo) or an external system (if the data is not in Unryo).

Integration with external systems#

There are several ways of integrating the topology map with external systems.

Import your data#

The first is to import your data into Unryo, either by pulling it from your external system or pushing it to Unryo.

Unryo accepts data from multiple sources (e.g. TCP and HTTP) and in multiple formats, including:

  • Binary
  • Collectd
  • CSV
  • Graphite
  • Grok
  • InfluxDB Line Protocol
  • JSON
  • Nagios
  • Prometheus
  • XPath

Following Unryo data model#

Timeseries data that is gathered or received continuously and which follows a clear parent-child hierarchy is amenable to being integrated with Unryo's hierarchical data. Such data can simply be pushed to InfluxDB in Unryo with the following mandatory tags: resource, resource_type, resource_parent, resource_parent_type; and a single mandatory field: resource_availability, whose value is typically 0 (the resource in question is unavailable) or 1 (the resource is available).

Using your own data model#

The Unryo topology backend can also be configured to accommodate other arbitrary data models. You can push your data to InfluxDB. Each InfluxDB Line Protocol line must encode one or more relationships between neighbours. The topology backend can then be configured such that it is able to properly retrieve the data.

Handling log/event data#

In Unryo, log data is typically pulled or received by fluentd, and then written in Opensearch. For the purposes of the topology map, the data is then aggregated and written in InfluxDB by using the Unryo Opensearch Query Telegraf plugin to select a subset of log fields.

Expose your data#

You may also expose your data via a REST API with four endpoints that mirror our APIs endpoints:

  • An endpoint that allows searching for nodes
  • An endpoint that allows retrieving the details about a specific node
  • An endpoint that allows retrieving the details about a specific edge
  • An endpoint that returns the neighbours of a given node on a given layer

This option allows the topology backend to forward requests it receives to external systems and to include data from those external systems in the topology map.

If you have custom metrics, you can extend the model by adding your own topology configuration(s).


Unryo provides flexible configuration files made to retrieve topology data from Prometheus. We bundle many such configuration files to graph entire Kubernetes topologies, from clusters all the way to containers, using the metrics created by kube-state-metrics.