Include data in segments

Segments can logically structure and serve as convenient filters when analyzing data in different apps. Segments are constructed based on rules, called Includes. Learn how data of different types can be included in segments.

Key terms

Include

Single rule, referencing data to be included in segment. Querying for data not explicitly referenced by any include of the selected segment, will lead to empty results.

Signal

Observed data point, emmitted by a monitored entity. Available signal types in Dynatrace are logs, metrics, events, spans, and others.

Monitored entity

Logical component monitored by Dynatrace. Available entity types are dt.entity.host, dt.entity.service, dt.entity.kubernetes_cluster, and others.

Includes

Segments are constructed incrementally through includes, step by step, extending the scope of the segment. Includes reference a certain data type and are defined by a filter condition for data of that type.

In its initial state, logically speaking, a segment can be considered empty. To use a segment for filtering, data needs to be included.

Segments missing data

In the following example, two include blocks were added to include logs and metrics by the given conditions. This illustrates how includes incrementally extend the scope of a segment.

segments query

Logical conditions within a single include can of course be more complex than simple equals-matches conditions as shown above.

segments query

Conditions of segment includes are evaluated at query time, directly impacting query performance. Make sure to consider OpenPipeline OpenPipeline app (new) to process fields and simplify complex conditions.

Data types

Signals

Collecting observability signals is at the core of Dynatrace, so you need to understand their schema and build segments around how those signals are shaped.

Signals can be included in segments in a number of ways. For the better efficiency of resulting filter expressions, always try to reference them directly.

Segments: data types example: three include blocks added to include logs, metrics, and events

Configurations like the one above can also be expressed more elegantly using the All data types option:

Segments: data types example: using the "All data types" option as a more elegant solution

Since context matters, and Dynatrace's unique monitored entity model provides an alternative way to work with observability signals, there is a second option to include signals through entity-to-signal relationships.

Monitored entities

With the power of the monitored entities model, Dynatrace provides data in context. By providing a topological view on top of mass monitoring data such as logs, metrics, events, and traces, Dynatrace will always provide an overview of where those data points originate, how data flows through your infrastructure, and how all these components scale over time.

You don't need to leverage monitored entities for setting up a segment, but it's certainly good practice when aiming to model generally applicable segments that can be used in multiple different apps.

The following example shows a segment configured to include Kubernetes clusters with names starting with dtp-prod10-.

segments kubernetes cluster

Including monitored entities does not automatically include signals of those entities. These have to be included individually.

Entity-to-entity relationships

A further benefit of segments in regards to monitored entities is being able to leverage relationships between them. For instance, this enables having segments that include Kubernetes workloads or other monitored entities of higher cardinality, filtered by their related Kubernetes clusters.

segments entity relationships

Segments allow a single relationship traversal step only. However, multiple parallel relationships of the same originating entity can be configured.