Custom topology model

The Dynatrace software intelligence platform and its Davis AI engine depend on context-rich, high-quality data that is provided by OneAgent, cloud integrations, or technology monitoring extensions.

Context-rich observability

Context-rich observability means that each incoming observation (metric, trace, log, or event) is stored with a reference to the monitored entity that it belongs to. Simple examples here are a CPU metric measurement that was observed on a given host, or a response time that was observed on a given service trace.

Built-in topology model

Using all these observations and the related entities, Dynatrace can extract and visualize the huge topological graph that we call Smartscape.

Each OneAgent that is deployed within your IT landscape sends in its own observations. Dynatrace then extracts and auto-discovers all context-relevant topology information. As a result, your Smartscape topology visualization grows in size and detail.

Smartscape, the Dynatrace built-in topological model, is entirely focused on entity types that are relevant for IT operations management, such as hosts, compute nodes, processes, web services, and more.

Topology examples

You can find examples of topological models all over Dynatrace, for example, the service deployment stack shown in Smartscape.

Another topological view is shown within Service flow, which shows the real-time call relationships of services extracted from all incoming transactions and traces.

The built-in topology model automatically detects more than a hundred entity types and their relationships, but is limited to well-known IT and software related types.

Custom topology model

Once you start to send in your own data sources—such as Telegraf metric streams, StatsD application measurements, or your own business metrics—through the metric ingest channel, you might be interested in extending the built-in model by adding your own domain-related types and relationships.

The extensibility of the topological model is especially interesting for IoT use cases, where you want to model your own device types (such as cars, ships, or vending machines) and connect them via well-defined relationships.

See the topology-related step in the WMI extension tutorial to learn more about extending the Dynatrace topology.

Custom topology model in action

Let's look at a simple example from the logistics domain that we want to model within Dynatrace.

With the above example, the company can ingest a continuous stream of observations in the form of truck and container telemetry.

Truck telemetry data

Easy Shipping LTD trucks send a continuous data stream on fuel (truck.fuel.total and truck.fuel.usage) and operation hours (operation.hours). Each measurement is sent in the context of the individual truck (trucknr) and its model (model). For example:

truck.fuel.total,trucknr=99,model=mac-granite 10234
truck.fuel.usage,trucknr=99,model=mac-granite 17
truck.operation.hours,trucknr=99,model=mac-granite 23766
truck.fuel.total,trucknr=12,model=mac-anthem 234
truck.fuel.usage,trucknr=12,model=mac-anthem 10
truck.operation.hours,trucknr=12,model=mac-anthem 13766

Container telemetry data

Smart containers carried by the company trucks send a continuous data stream on the currently measured temperature (container.temperature). Each measurement is sent in the context of the individual container (containernr) and the truck it is carried on (trucknr):

container.temperature,containernr=234321,trucknr=99 40
container.temperature.dev,containernr=234321,trucknr=99 0

container.temperature,containernr=111111,trucknr=12 39
container.temperature.dev,containernr=111111,trucknr=12 2,5

and so on.

Instances of the types truck and container and their relationship can be extracted automatically from the continuous data stream.

Benefits of custom topology

The benefit of having a domain model on top of your telemetry data is:

See Define custom topology to learn how to create a custom topology suited to your telemetry data.