Try it free

Configure service detection for OneAgent in Service Detection v2

  • Latest Dynatrace
  • How-to guide
  • 4-min read
  • Early Access

Service Detection v2 (SDv2) for OneAgent is the standard for OpenTelemetry services, generally available and the recommended default for Kubernetes and AWS Lambda services, and available as an Early Access release for all other OneAgent-monitored workloads. You need to activate it manually in the Dynatrace web UI or via the Settings API.

SDv2 for OneAgent covers three deployment scenarios, each activated separately:

  • Kubernetes: Services running in Kubernetes clusters.
  • FaaS: Serverless functions on AWS Lambda.
  • Generic workloads: Web servers and cloud-native services that run outside Kubernetes and AWS Lambda, such as Nginx, Apache, or IIS on virtual machines or bare metal.

Configuration scopes

You can activate SDv2 for Kubernetes and AWS Lambda services for the following configuration scopes:

  • Environment
  • Host group
  • Cluster
  • Namespace

You can activate SDv2 for other workloads that run outside Kubernetes for the following configuration scopes:

  • Environment
  • Host group

Things to consider

  • If you have custom services defined, note that they behave differently in SDv2: instead of creating a separate service entity, the selected class or method becomes a span on the existing service the code runs in. For details, see Custom service behavior in SDv1 and SDv2.
  • If you're moving from Service Detection v1 (SDv1) to SDv2, note that SDv2 assigns new service IDs, so update any alerts and dashboards that reference your existing SDv1 services.

Activate SDv2 for Kubernetes services

Dynatrace SaaS version 1.323+

SDv2 is available for services running in Kubernetes and monitored by OneAgent. This feature is deactivated by default, but you can activate SDv2 for your Kubernetes services in the Dynatrace web UI or via the Settings API (builtin:service-detection-v2-for-oneagent schema ID).

To activate SDv2 for Kubernetes workloads

  1. Navigate to the Service Detection v2 for OneAgent page for the required configuration scope.

    Environment

    Latest Dynatrace

    Go to Settings Settings > Process and contextualize > Services > Service Detection v2 for OneAgent.

    Dynatrace Classic

    Go to Settings > Service detection > Service Detection v2 for OneAgent.

    Host group

    Latest Dynatrace

    1. Go to Settings Settings.
    2. In the upper-left corner of the page, select Go to entity >, filter by Host group, and select the required host group.
    3. Go to Process and contextualize > Services > Service Detection v2 for OneAgent.

    Dynatrace Classic

    1. Go to Deployment Status Deployment Status > OneAgents.

    2. On the OneAgent deployment page, turn off Show new OneAgent deployments.

    3. In the Filter by field, enter Host group, and then select the host group you want to configure from the dropdown list.

      The host list is now filtered by the selected host group. Each listed host has a Host group: <group name> link, where <group name> is the name of the host group that you want to configure.

      The Host group property is not displayed when the selected host doesn't belong to any host group.

    4. Select the host group name in any row.

      As you have filtered by host group, all displayed hosts go to the same host group.

    1. Go to Service detection > Service Detection v2 for OneAgent.
    Cluster and namespace

    Latest Dynatrace

    1. Go to Kubernetes (new) Kubernetes.
    2. Find and select the required namespace or cluster.
    3. In the upper-right corner of the cluster or namespace pane, select (Actions menu) > Service detection settings. The Service detection page opens.
    4. Go to Process and contextualize > Services > Service Detection v2 for OneAgent.

    Dynatrace Classic

    1. Go to Kubernetes Kubernetes Classic.
    2. Find and select the required namespace or cluster.
    3. In the upper-right corner of the cluster or namespace overview page, select More (…) > Settings.
    4. Go to Service detection > Service Detection v2 for OneAgent.

  2. Turn on Enable Service detection v2 for Kubernetes workloads.

  3. Specify the required DQL matcher in Matching condition for Kubernetes workloads. This matching condition limits the scope of service detection by filtering Kubernetes workloads with the provided DQL matcher.

    Allowed attributes and examples

    Allowed attributes

    • Recommended Primary Grail fields. Use to scope workloads by deployment context.

    • Primary Grail tags. Use for more fine-grained or cross-cutting scoping.

      Only tags set by OneAgent are supported; tags set via OpenPipeline aren't available during service detection.

    • Resource attributes.

    • Custom attributes.

    Example: Target specific language and namespace

    Activate SDv2 only for the java language and the unguard namespace:

    dt.agent.module.type == "java" AND
    k8s.namespace.name == "unguard"

    If you're moving from SDv1 to SDv2, use the matching condition to start in lower environments first. Because SDv2 assigns new service IDs, update any alerts and dashboards that reference your existing SDv1 services.

  4. Select Save changes.

You've activated SDv2 for the services that are running in Kubernetes and monitored by OneAgent.

Activate SDv2 for AWS Lambda services

Dynatrace SaaS version 1.337+

SDv2 is generally available for AWS Lambda services monitored by OneAgent. This feature is deactivated by default, but you can activate SDv2 for your AWS Lambda services in the Dynatrace web UI or via the Settings API (builtin:service-detection-v2-for-oneagent schema ID).

To activate SDv2 for AWS Lambda services

  1. Navigate to the Service Detection v2 for OneAgent page for the required configuration scope.

    Environment

    Latest Dynatrace

    Go to Settings Settings > Process and contextualize > Services > Service Detection v2 for OneAgent.

    Dynatrace Classic

    Go to Settings > Service detection > Service Detection v2 for OneAgent.

    Host group

    Latest Dynatrace

    1. Go to Settings Settings.
    2. In the upper-left corner of the page, select Go to entity >, filter by Host group, and select the required host group.
    3. Go to Process and contextualize > Services > Service Detection v2 for OneAgent.

    Dynatrace Classic

    1. Go to Deployment Status Deployment Status > OneAgents.

    2. On the OneAgent deployment page, turn off Show new OneAgent deployments.

    3. In the Filter by field, enter Host group, and then select the host group you want to configure from the dropdown list.

      The host list is now filtered by the selected host group. Each listed host has a Host group: <group name> link, where <group name> is the name of the host group that you want to configure.

      The Host group property is not displayed when the selected host doesn't belong to any host group.

    4. Select the host group name in any row.

      As you have filtered by host group, all displayed hosts go to the same host group.

    1. Go to Service detection > Service Detection v2 for OneAgent.
    Cluster and namespace

    Latest Dynatrace

    1. Go to Kubernetes (new) Kubernetes.
    2. Find and select the required namespace or cluster.
    3. In the upper-right corner of the cluster or namespace pane, select (Actions menu) > Service detection settings. The Service detection page opens.
    4. Go to Process and contextualize > Services > Service Detection v2 for OneAgent.

    Dynatrace Classic

    1. Go to Kubernetes Kubernetes Classic.
    2. Find and select the required namespace or cluster.
    3. In the upper-right corner of the cluster or namespace overview page, select More (…) > Settings.
    4. Go to Service detection > Service Detection v2 for OneAgent.

  2. Turn on Enable Service detection v2 for FaaS.

  3. Specify the required DQL matcher in Matching condition for FaaS. This matching condition limits the scope of service detection by filtering services with the provided DQL matcher.

    The default matching condition is isNotNull(aws.region) AND isNotNull(aws.account.id).

    Allowed attributes

    • Recommended Primary Grail fields. Use to scope workloads by deployment context.

    • Primary Grail tags. Use for more fine-grained or cross-cutting scoping.

      Only tags set by OneAgent are supported; tags set via OpenPipeline aren't available during service detection.

    • Resource attributes.

    • Custom attributes.

    If you're moving from SDv1 to SDv2, use the matching condition to start in lower environments first. Because SDv2 assigns new service IDs, update any alerts and dashboards that reference your existing SDv1 services.

  4. Select Save changes.

You've activated SDv2 for AWS Lambda services that are monitored by OneAgent.

SDv2 for AWS Lambda services only works when the [Built-in] FaaS name service detection rule is enabled, so check whether this rule is activated for your environment. For details, see Default service detection rules.

Activate SDv2 for generic workloads

Early Access Dynatrace SaaS version 1.343+

SDv2 brings generic workloads into the same one-service-per-process model as the rest of SDv2. It's available as an Early Access release for web servers and cloud-native services running outside Kubernetes and AWS Lambda. This includes web servers such as Nginx, Apache, and IIS on virtual machines or bare metal, and single-process cloud-native services on ECS, Cloud Run, and Azure Container Apps.

SDv2 for generic workloads works best for services that map to one service per process. For application servers that host multiple applications in one process, such as WebSphere or WebLogic, keep SDv1 for now while Dynatrace continues to test these setups. For details, see Which workloads to activate.

Dynatrace continues to expand its out-of-the-box rules to cover more setups, and you can always refine detection with your own configuration to fine-tune the results. As an Early Access release, testing on cloud and container services is ongoing. For best results, add your cloud connection first so that SDv2 can use cloud-related attributes.

You can activate SDv2 for generic workloads in the Dynatrace web UI or via the Settings API (builtin:service-detection-v2-for-oneagent schema ID). It's deactivated by default, and its matching condition is set to false, so it has no effect until you scope it to the workloads you choose.

This setting applies only to OneAgent-monitored workloads. OpenTelemetry services use SDv2 by default and are unaffected by this setting. For details, see Generic workload detection.

To activate SDv2 for generic workloads

  1. Navigate to the Service Detection v2 for OneAgent page for the required configuration scope.

    Environment

    Latest Dynatrace

    Go to Settings Settings > Process and contextualize > Services > Service Detection v2 for OneAgent.

    Dynatrace Classic

    Go to Settings > Service detection > Service Detection v2 for OneAgent.

    Host group

    Latest Dynatrace

    1. Go to Settings Settings.
    2. In the upper-left corner of the page, select Go to entity >, filter by Host group, and select the required host group.
    3. Go to Process and contextualize > Services > Service Detection v2 for OneAgent.

    Dynatrace Classic

    1. Go to Deployment Status Deployment Status > OneAgents.

    2. On the OneAgent deployment page, turn off Show new OneAgent deployments.

    3. In the Filter by field, enter Host group, and then select the host group you want to configure from the dropdown list.

      The host list is now filtered by the selected host group. Each listed host has a Host group: <group name> link, where <group name> is the name of the host group that you want to configure.

      The Host group property is not displayed when the selected host doesn't belong to any host group.

    4. Select the host group name in any row.

      As you have filtered by host group, all displayed hosts go to the same host group.

    1. Go to Service detection > Service Detection v2 for OneAgent.

  2. Turn on Enable Service detection v2 for generic workloads.

  3. In Matching condition for generic workloads, replace the default false with a DQL condition that selects which workloads within the current configuration scope (environment or host group) activate SDv2.

    The default false matches no workloads or host groups, so activating SDv2 for generic workloads takes effect only once you provide a matching condition, which lets you opt in gradually.

    Allowed attributes and examples

    Allowed attributes

    • Recommended Primary Grail fields. Use to scope workloads by deployment context.

    • Primary Grail tags. Use for more fine-grained or cross-cutting scoping.

      Only tags set by OneAgent are supported; tags set via OpenPipeline aren't available during service detection.

    • Resource attributes.

    • Custom attributes.

    Example 1: Target a host group

    Opt in every supported workload running in one host group:

    dt.host_group.id == "orders-demo-vm"

    Example 2: Target a single workload

    Bring SDv2 to one process group and leave the rest on SDv1:

    dt.process_group.detected_name == "SpringBoot orders-demo com.dynatrace.ordersdemo.OrdersDemoApplication"

    If you're moving from SDv1 to SDv2, use the matching condition to start in lower environments first. Because SDv2 assigns new service IDs, update any alerts and dashboards that reference your existing SDv1 services.

  4. Select Save changes.

You've activated SDv2 for generic workloads.

Generic workload detection

SDv2 for generic workloads does not provide a built-in matching condition. As there's no namespace or cloud account to scope this feature automatically, you should define a DQL matcher using the attributes that are present on the workload's data, and then scope the setting to a host group or the whole environment.

When the condition matches, OneAgent processes that workload's trace data with the SDv2 service and endpoint detection. Existing request attributes continue to work, and SDv1 custom services are ignored, so their spans are grouped into the SDv2 service instead. For details, see Things to consider.

Which workloads to activate

SDv2 works best for workloads that map cleanly to one service per process:

  • Web servers and reverse proxies running outside containers, such as Nginx, Apache, and IIS.

    For services that don't set http.route, Dynatrace derives a fallback route based on the URL path, so your services get descriptive names. For details, see Automatic naming for services without http.route and Endpoint naming.

  • Single-service application processes with one application service per process.

Keep the following workloads on SDv1 for now:

  • Application servers and multi-service processes where a single process hosts more than one logical service, such as WebSphere, WebLogic, J2EE multi-context JVMs, or multi-context ColdFusion.

    SDv2 groups these into one service per process, so SDv1 keeps the per-application separation they need.

  • Background or scheduled workloads with no inbound request (timer-, cron-, or thread-triggered).

    SDv2 detection is built around inbound request spans.

Example: Services in SDv1 vs SDv2

The following example shows how the orders-demo-vm host group appears in Services Services before and after you activate SDv2 for generic workloads. The example uses one VM running a single Spring Boot application behind an Nginx reverse proxy.

SDv1

Under SDv1, the host group shows four fragments for this single VM:

  • orders-demo - InventoryController service.
  • orders-demo - OrderController service.
  • :80 web server.
  • OrderEventsListener Kafka consumer.
"orders-demo-vm" host group showing four fragments for single VM in the Service app)
"orders-demo-vm" host group showing four fragments for single VM in the Service app)

SDv2

After activating SDv2 for generic workloads, the same host group shows two clean SDv2 services, one per process:

  • orders-demo service (Spring Boot application).
  • nginx service (web server).

Database and messaging activity has moved onto the calling service instead of separate entities; the information is available on the dedicated tabs within the service details pane.

"orders-demo-vm" host group showing two SDv2 services in the Service app
"orders-demo-vm" host group showing two SDv2 services in the Service app

Next steps

After activation, your services appear in Services Services. To fine-tune results, leverage service detection rules, endpoint detection rules, and URL pattern matching.

Related topics

  • Customize service detection in Service Detection v2
Related tags
Application Observability