Unified service

Dynatrace version 1.274

The service type Unified service represents services detected based on spans and is built with Cloud Native and OpenTelemetry in mind. Unified services provide agentless support for data from ingestion APIs, such as trace ingest APIs.

Unified services ingested via the ingest APIs are listed with other services and in the SmartScape® topology. After enriching your traces with topology information, relationships are mapped across your environment, providing a complete vertical and horizontal view of the topology, and easier root-cause analysis of problems.
Dynatrace calculates response time, throughput, and failure rate metrics for these services, which are available via service analysis. To learn more about unified-service metrics, see Built-in metrics.
Davis® AI analyzes for problems related to the underlying resources, with out-of-the-box baselining. Additionally, you can create custom alerts based on log information.
You can search monitored entities in Dynatrace by the span name.
You can monitor Istio services meshes.
Distributed traces, logs, and events are put into context.
You can monitor and set up alerting for automatically detected endpoints.

Before you begin

Set up service detection

Set up endpoint detection

Manage endpoint monitoring

Before you begin

If you already use the service type Span (default) service (span:service) in your environment, we recommend manually migrating your instances to the Unified service type.

Breaking change Migrating to a different service type will affect existing API metric queries, dashboards, and service and request names.

This action can be reverted, but, to ensure the high quality of your monitoring data, we recommend that you minimize switching between service types.

Set up service detection

To enable unified-service detection

In the Dynatrace menu, go to Settings.
Select Service Detection.
Select Unified services for OpenTelemetry and turn on Enable Unified services.

A Unified service is then created when Dynatrace detects API-ingested spans. When detecting a unified service, the following resource attributes are evaluated in the following order. The first matching attribute's value defines the name of the unified service. Note that masked/non-allowed attributes are ignored for service detection.

Evaluated attribute	Service name
`dt.kubernetes.workload.name`	Attribute's value ¹
`istio.canonical_service`	Attribute's value
`service.name`	Attribute's value

If the attribute k8s.namespace.name is present, a unique service is created per namespace, while maintaining the same service name. You can find the namespace in the service overview Properties and tags.

Set up endpoint detection

Endpoints are automatically created and baselined for each detected span serving as an entry point. In the case of OpenTelemetry, these are usually server or consumer spans.

The following span attributes are evaluated in the following order.

Technology	Evaluated attribute	Endpoint name
gRPC	`rpc.service` (or `rpc.method`)	Attribute's value
HTTP	`http.route` (or `http.method`)	Attribute's value
Webservers (NGINX, Apache) and Istio ingress gateways		`"/"` as single static endpoint name
Serverless functions (FaaS)		`"invoke"` as single static endpoint
Non-technology specific	`code.namespace` or `code.function` `span.name` `span.kind == server` or `span.kind == consumer`	Attribute's value

Span attribute settings influence endpoint detection. To learn more about span attributes, see Attribute redaction.

The first matching attribute's value defines the name of the endpoint. Endpoint names are usually technology-specific. The endpoint name uniquely identifies one endpoint of a particular service. Note that masked/non-allowed attributes are ignored for endpoint detection.

Manage endpoint monitoring

You can manage endpoint metrics, such as response time, throughput, and failure rate metrics, by configuring endpoint metric collection on the environment level and overrides on the service level.

Endpoint metrics consume DDUs, so changes to the following settings have billing implications.

Metric key	Name and description	Unit	Aggregations
builtin:service.request.count	Unified service request count Number of requests received by a given service. To learn how Dynatrace detects and analyzes services, see [Services](https://dt-url.net/am-services).	Count	autovalue

Metric key

Name and description

builtin:service.request.count

Unified service request count

Number of requests received by a given service. To learn how Dynatrace detects and analyzes services, see [Services](https://dt-url.net/am-services).

Count

autovalue

Metric key	Name and description	Unit	Aggregations
builtin:service.request.failure_count	Unified service failure count Number of failed requests received by a given service. To learn how Dynatrace detects and analyzes services, see [Services](https://dt-url.net/am-services).	Count	autovalue

Metric key

Name and description

builtin:service.request.failure_count

Unified service failure count

Number of failed requests received by a given service. To learn how Dynatrace detects and analyzes services, see [Services](https://dt-url.net/am-services).

Count

autovalue

Metric key	Name and description	Unit	Aggregations
builtin:service.request.response_time	Unified service request response time Response time of a service measured in ms on the server side (server side measurements do not include e.g. proxy and networking times). Response time is the time until a response is sent to a calling application, process or other service. It does not include further asynchronous processing. To learn how Dynatrace calculates service timings, see [Service analysis timings](https://dt-url.net/service-timings).	Millisecond	autocountmaxmedianminpercentile

Metric key

Name and description

builtin:service.request.response_time

Unified service request response time

Response time of a service measured in ms on the server side (server side measurements do not include e.g. proxy and networking times). Response time is the time until a response is sent to a calling application, process or other service. It does not include further asynchronous processing. To learn how Dynatrace calculates service timings, see [Service analysis timings](https://dt-url.net/service-timings).

Millisecond

autocountmaxmedianminpercentile

Environment levelService level

To manage endpoint monitoring for all unified services in your environment

In the Dynatrace menu, go to Settings.
Select Service Detection.
Select Unified services endpoint metrics and turn on/off Enable endpoint metrics.

To override endpoint monitoring for a specific unified service

In the Dynatrace menu, go to Services.
optional On the Services page, in the Service type column, select the Unified service checkbox.
Find and select the unified service for which you want to configure endpoint monitoring.
On the unified service overview page, go to More (…) > Settings.
On the Service settings page, select Endpoint metrics.
On the Unified services endpoint metrics page, turn on/off Enable endpoint metrics.

Frequently asked questions

How can I verify that the observability signals are correctly linked to the related unified service?

For Dynatrace to correctly correlate observability signals, certain attributes must be present. Make sure that

Metrics contain the service.name dimension.
Logs contain either the trace_id or trace.id attribute.

What is captured?

To comply with privacy regulations, Dynatrace only stores attribute values when the related keys are specified in the allowlist. This option gives you complete flexibility in what is captured but is based on safe defaults. This means that nothing else is recorded beyond what you allow.

Do I need to migrate opaque services?

No. Opaque services (such as outbound Python, Rust, or Ruby third-party services) are automatically migrated to the Unified service type.