Overview
Inferred services improve how Datadog represents service dependencies. This document explains the changes and how to adapt your configuration.
Before inferred services
Datadog used to change service names of client spans (span.kind:client
) to represent databases, queues, and third-party dependencies. For example, a client call from service A
to a PostgreSQL database would be tagged as service:postgres
or service:A-postgres
. Changing the service name of spans is referred to as a service override in the rest of this guide. The initial service name is referred to as the base service.
In this approach, a span representing a client call from a service auth-dotnet
to a PostgreSQL database would be tagged with service:auth-dotnet-postgres
. In service maps, these dependencies were represented as separate services, as shown below:
With inferred services
Dependencies are automatically inferred from span attributes collected on client spans (for example, db.system
, db.name
). The client span retains the base service name, and the database is inferred using other attributes. As a result, there’s no need to change the service
attribute on the client span anymore.
Using the previous example, the client span would now be tagged with the base service name auth-dotnet
, and the database would be inferred from attributes like db.name:user-db
and db.system:postgres
. The service map representation would look like this:
Impact on service overrides
With inferred service dependencies, service overrides might pollute service lists and maps. In service maps, you would see the following nodes in order:
- The base service node, for example:
auth-dotnet
. - The service override node, for example:
auth-dotnet-postgres
. - The new inferred service node, for example:
user-db
.
The service override (auth-dotnet-postgres
) breaks the direct connection between the base service and the inferred service. It is not useful anymore as the database dependency is now properly represented by the inferred service.
How service overrides are set
Integration service overrides
Datadog tracing libraries automatically set different service names on client spans to represent databases, queues, or third-party service dependencies in integrations. These types of service overrides are referred to as integration service overrides in the rest of the guide.
Custom service overrides
Service names can also be set manually by users, for instance to gain visibility on specific components of the service (shared libraries, middleware layers). These types of service overrides are referred to as custom service overrides in the rest of the guide.
How service overrides are represented in Datadog
To give less importance to service overrides, these are treated differently visually speaking in various APM product pages.
In service and resource pages
Services that are service overrides are flagged as such in the service page header. On hover, find the list of base services where the service name is overriden, in a custom way, or as the default setting of the integration.
In service maps
In service maps, service overrides are represented as part of the edge going from the base service and the inferred service.
In traces
In the trace side panel, the client span header represents the call going from the base service to the inferred service. The top of the overview section also shows information about the base service name, the overriden service name, and the inferred entity name.
Remove service overrides
To remove integration service overrides, set the environment variable:
DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED=true
This ensures the service
attribute always uses the base service name instead of appending the integration name (for example,*-postgres
, *-http-client
).
Removing service overrides is a breaking change. Metrics, monitors, or dashboard queries based on the overridden service name will stop matching.
It is recommended to remove service overrides progressively, proceeding service by service, to ensure that no critical assets (such as dashboards, monitors, retention filters, and so on) are affected by the change. Follow the detailed instructions to ensure a smooth transition to the new model.
Examples
For example:
- .NET tags gRPC calls as
service:<DD_SERVICE>-grpc-client
- Python tags gRPC calls as
service:grpc-client
With the DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED
option set to true
, all supported tracing libraries tag client spans capturing the call to the downstream service with the calling service’s name, service:<DD_SERVICE>
. This ensures all spans are always tagged with the default service name emitting the span; peer.*
attributes are used to describe the called dependency (for example, database or queue).
Scenario | Service Name | Additional peer.* Attributes |
---|
Without inferred services and with service overrides | service:my-service-grpc-client or service:grpc-client | No peer.* attributes set |
With inferred services and without service overrides | service:myservice | @peer.service:otherservice (where otherservice is the name of the remote service being called with gRPC) |
Similarly, for a span representing a call to a mySQL database:
Scenario | Service Name | Additional peer.* Attributes |
---|
Without inferred services and with service overrides | service:my-service-mysql or service:mysql | No peer.* tags set |
With inferred services and without service overrides | service:myservice | @peer.db.name:user-db , @peer.db.system:mysql |
Remove service overrides progressively
- Identify the service override you want to remove and navigate to its service page.
- Hover over the service override pill in the page header and note the underlying base service names. These are the original services emitting spans with overrides. You need to update the configuration for these instrumented services.
Scan through your existing assets that might contain queries using the override service name:
Update these queries to use the base service name (service:<DD_SERVICE>
). This allows queries to continue to match when you remove service overrides
Set DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED=true
for integration service overrides.
Note: The configuration above only removes integration service overrides. Custom service overrides must be removed directly in the code.
Glossary
Service override
A service name set for a span which differs from the default DD_SERVICE
name. It can be set automatically by some Datadog integrations, or manually by users.
Base service
The default DD_SERVICE
name.
Further reading
Additional helpful documentation, links, and articles: