Unified services
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
If you already use the Span service (span:service) type in your environment, we recommend migrating your instances to the Unified service type. To automatically migrate your instances, 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.
Migrating to a different service type will affect existing API metric queries, dashboards, and service and request names.
This action can be reverted, however, to ensure the high quality of your monitoring data, we recommend that you minimize switching between service types.
Unified-service detection rules
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 |
|---|---|
| Attribute's value 1 |
| Attribute's value |
| 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.
Endpoint detection rules
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 |
| Attribute's value |
HTTP |
| Attribute's value |
Webservers (NGINX, Apache) and Istio ingress gateways |
| |
| ||
Non-technology specific |
| Attribute's value |
HTTP |
| Attribute's value |
Non-technology specific |
| 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.
When endpoint metrics consume DDUs, changes to endpoint metric-collection settings have billing implications.
| Metric key | Name and description | Unit | Aggregations | Monitoring consumption |
|---|---|---|---|---|
| builtin:service | 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 | DDUs |
| builtin:service | 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 | Host units |
| builtin:service | 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 | DDUs |
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.
Frequently asked questions
For Dynatrace to correctly correlate observability signals, certain attributes must be present. Make sure that
- Metrics contain the
service.namedimension. - Logs contain either the
trace_idortrace.idattribute.
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.
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.
1type("PROCESS_GROUP"),tag("aws-az-1")
To include a unified service, add another management-zone rule as follows.
1type(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.