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.
Unified services are created only for traces ingested via APIs.
If you already use the Span service (span:service) type in your environment, we recommend migrating your instances to the Unified service type, by enabling unified-service detection.
Migrating to a different service type affects existing API metric queries, dashboards, and service and request names.
If you don't see this menu option, you were auto-migrated safely. Enjoy the enhanced features without any migration hassles or trade-offs.
Service and endpoint detection are based on span attribute settings. To verify your configuration, see Attribute redaction. Note that masked/blocked attributes are ignored for detection.
A Unified service is created when Dynatrace detects API-ingested spans.
The following tables represent the service detection and naming ruleset that is evaluated from left to right. The first matching rule defines the service ID and name. The service ID uniquely identifies one service.
Endpoints are automatically created and baselined for each request root span. Request root spans are typically trace root spans or spans of span kind server or consumer.
The following tables represent the endpoint detection and naming ruleset that is evaluated from left to right. The first matching rule defines the endpoint name. The endpoint name uniquely identifies one endpoint of a particular service.
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.
Changes to endpoint metric-collection settings have billing implications.
The following table lists endpoint Classic metrics; metrics that consume DDUs are billed.
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).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).Unified service request response time
Response time of a service measured in microseconds 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).The endpoint Grail metrics are dt.service.request.response_time, dt.service.request.failure_count, and dt.service.request.count and are billable. To learn more, see Metrics powered by Grail (DPS).
To manage endpoint monitoring for all unified services in your environment
To override endpoint monitoring for a specific unified service
Failure detection rules for unified services check requests on endpoints and incoming Istio services mesh proxies. The first matching attribute's value defines the failure reason.
A request is considered successfull if span.status_code is OK or no failure detection rule matches.
For Dynatrace to correctly correlate observability signals, the unified service must be detected based on spans. Make sure that logs contain either the trace_id or trace.id attribute.
To comply with privacy regulations, Dynatrace only stores attribute values when the related keys are not blocked. 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.
No. Opaque services (such as outbound Python, Rust, or Ruby third-party services) are automatically migrated to the Unified service type.
Yes, you need to review preexisting management-zone rules targeting metrics with the dimension service.name, for example, management zones based on processes or process groups. The results of a management-zone rule depend on the match between the metric's primary entity and the monitored entity in the management zone. If the primary entity of a metric does not match the monitored entity, the management-zone rule yields no results. Because unified services leverage metrics where the primary entity is adaptive, we recommend that you modify such management-zone rules to include unified services. Note that logs are not directly impacted.
In the following example, a text-based entity selector rule for an existing management zone provides access to all process groups with the aws-az-1 tag.
type("PROCESS_GROUP"),tag("aws-az-1")
To include a unified service, add another management-zone rule as follows.
type(service),fromRelationship.runsOn(type("PROCESS_GROUP"),tag("aws-az-1"))
If the issue persists, contact a Dynatrace product expert via live chat to disable unified-service detection metric ingestion for metrics where the primary entity is adaptive.