Customize service splitting in Service Detection v2

  • Latest Dynatrace
  • How-to guide
  • 2-min read

Service Detection v2 (SDv2) lets you split your detected services based on resource attributes. You can use the default Dynatrace detection rules and also define your own custom rules. These rules are applied globally to all detected services.

Aim and context

This page describes service splitting for SDv2, how to use default splitting rules, and how to create your own custom rules.

Service splitting is particularly useful when:

  • You need to compare the same service across different environments.
  • You want to isolate performance issues to specific deployment regions.
  • You need to track behavior differences between service versions.
  • You're troubleshooting environment-specific issues.

Service splitting rules

  • Rules are evaluated in order, from top to bottom.
  • Custom rules are always evaluated before default rules.
  • Only the first matching rule is applied.

Default splitting rules

Dynatrace provides default service splitting rules as described in the table below. Additionally, custom rules can be created as described in Create new rule.

PriorityRule nameMatching conditionResource attribute keysStatus

1

[Built-in] Split Adobe Experience Manager (AEM) services by process group

isNotNull(adobe.em.tier) AND isNotNull(adobe.em.env_type) AND isNotNull(adobe.em.program)

dt.entity.process_group

Enabled

2

Split services by k8s cluster and namespace

isNotNull(k8s.namespace.name)

k8s.namespace.name AND k8s.cluster.uid

Enabled1

3

[Built-in] Split services by k8s namespace (deprecated)

isNotNull(k8s.namespace.name)

k8s.namespace.name

Disabled2

4

[Built-in] Split services by host group and primary cloud fields

None (rule applies to all services)

dt.host_group.id, aws.account.id, aws.region, azure.subscription, azure.resource.group, azure.location, and gcp.project.id

Enabled3

1

The [Built-in] Split services by k8s cluster and namespace rule is enabled for the environments created in Dynatrace SaaS version 1.317+ and is disabled for the environments created in Dynatrace SaaS version 1.316 and earlier.

2

The [Built-in] Split services by k8s namespace (deprecated) rule is disabled for the environments created in Dynatrace SaaS version 1.317+ and is enabled for the environments created in Dynatrace SaaS version 1.316 and earlier.

3

The [Built-in] Split services by host group and primary cloud fields rule is enabled for the environments created in Dynatrace SaaS version 1.337+ and is disabled for the environments created in Dynatrace SaaS version 1.336 and earlier.

Steps

Service splitting rules are customized in Settings Settings > Process and contextualize > Services > Service splitting.

Create new rule

  1. In Service splitting, select Add rule.
  2. Fill in the following optional and required fields:

    • Rule name: Required A user-defined name for the rule.

    • Description: Optional A human-readable description of the rule.

    • Matching condition: Required ADQL matcher. If the matching condition applies, the rule is evaluated.

    • Split service by resource attribute: Optional Spans will be separated into services according to the resource attribute(s) defined here. Consists of one or more resource attributes specified without curly braces, e.g. dt.entity.process_group or k8s.namespace.name.

      To add a resource attribute, select Add item and enter the Attribute key.

      Up to 10 resource attributes can be configured.

  3. To save, select Save changes.

Edit custom rules

You can re-order custom rules to affect the order of precedence.

You can also edit a custom rule.

  1. Navigate to the rule and select Details > .
  2. Edit the field(s) as appropriate.
  3. Select Save changes.

It's not possible to re-order or edit built-in rules.

Delete custom rules

You can delete a custom rule.

  1. Navigate to the rule and select Delete > .
  2. Select Save changes to permanently delete the rule, or Discard changes to keep the rule.

It's not possible to delete built-in rules, however you can deactivate built-in rules.

Best practices for splitting services

  • Start with broader splitting rules before adding more specific ones.
  • Don't over-split services as this can cause you to receive the same alert spread across many different services.
  • Choose attributes that provide meaningful insights for your specific use case.
  • Regularly review splitting rules as your application architecture evolves.

Related topics

Related tags
Application Observability