Splitting a Unified Service into Multiple Services Based on OTEL Attributes

[riccardo7]

Hi everyone,

We are currently ingesting OpenTelemetry (OTEL) data through the OTEL Collector into Dynatrace, and we're using spans to create unified services.

Our goal is to understand if it's possible to split a unified service into multiple distinct services based on certain attributes present in the OTEL spans — for example, splitting services based on a specific attribute like 'scope.name', 'campaign.id', or other custom tags.

In short:

Can we break down a single service into multiple logical services based on span-level attributes?

This would help us better reflect the different functional scopes within a shared service architecture.

Has anyone tried this, or is there any recommended approach or workaround for achieving this in Dynatrace?

[marco_irmer]

After reviewing the relevant documentation for Unified Services, it seems that Dynatrace will by design use the 'service.name' attribute as it appears in the arriving OTEL spans. I am not seeing any indication that this is currently customizable in any way. Perhaps worth submitting as a product idea.

[Julius_Loman]

Yes, it's determined by the `service.name` attribute as @marco_irmer  states. You can use OpenTelemetry collector to process the data and modify the attribute (I actually never tried that, but this should work).

[mreider]

We're getting closer to exposing the Unified Services settings. Hopefully a few weeks from now I'll publish a feedback channel with instructions, screen shots, and an overview of what's to come.

The first thing I will do is introduce some new Terminology.

Service Detection v2

• Service Detection v2 is a new name for the rules we've been using for Unified Services.
  
  • Service detection / naming
  • Endpoint detection
  • Failure detection
  • Splitting
• Service Detection v2 rules are currently hardcoded and documented here.
• As the docs show, we don't refer to the rules using this "v2" terminology (yet).
• These rules only apply to OpenTelemetry and Adobe Experience Manager.

In a month or two:

• We'll update our docs and introduce this new Service Detection v2 terminology
• We'll also start referring to classic OneAgent rules as Service Detection v1 (for detection, naming, endpoint (requests), and splitting).
• We'll expose the settings for these rules, again for OpenTelemetry and Adobe Experience Manager only.

Later this year:

• Customers will be able to use Service Detection v2 rules for OneAgent based services
• Only available on SaaS tenants.
• Starts with public preview, Kubernetes only, and begin with Spring / Java workloads
• Purely "opt-in" - no need to worry about migrations unless shared OTel + OneAgent rules seem valuable.
• Related to the above, Service Detection v1 will continue to be available. No need to migrate.

Much more in the feedback channel later this month.

😊