Choosing Between OneAgent SDK and OpenTelemetry for Custom Metrics in Dynatrace

Decision: native SDK speed vs vendor-neutral OTel for custom metrics

Adding custom application metrics to Dynatrace forces a choice between the OneAgent SDK and OpenTelemetry ingestion. The constraint is host coverage: OneAgent must be present for SDK hand-off, while OTel needs a collector or direct API access. Pick the SDK for fastest time-to-value with automatic entity mapping on Java, .NET and Go. Pick OTel when architecture requires vendor-agnostic instrumentation and multi-backend export.

Comparison of ingestion methods

The following table compares the technical trade-offs between the OneAgent SDK and OpenTelemetry for metric ingestion.

Trade-offs

OneAgent SDK: path of least resistance

The OneAgent SDK leverages the existing OneAgent process on the host. Metrics are handed to the local agent instead of sent over the network to a remote endpoint. This reduces network jitter and avoids managing API tokens in application code.

Key advantage is automatic metadata enrichment. Metrics are natively linked to host, process and service entities, so dashboards update automatically as infrastructure scales.

OpenTelemetry: future-proof approach

OpenTelemetry separates instrumentation from export. The same metric stream can be sent to Dynatrace and another backend simultaneously without changing application code.

Key advantage is ecosystem flexibility. You avoid hard-coding observability into a single vendor, which is often required for enterprise architecture standards.

Implementation example: custom metric via OneAgent SDK Java

To implement a custom metric using the OneAgent SDK, include the SDK library in project dependencies. The example records a business metric such as order processing.

// Ensure the dynatrace-oneagent-sdk dependency is added to pom.xml or build.gradle
import com.dynatrace.oneagent.sdk.metrics.MetricRegistry;
import com.dynatrace.oneagent.sdk.metrics.Counter;

public class OrderService {
    private final Counter orderCounter = MetricRegistry.getRegistry()
        .counter("app.orders.processed", "Number of orders processed successfully");

    public void processOrder(Order order) {
        try {
            doProcess(order);
            orderCounter.increment();
        } catch (Exception e) {
            // Handle error
        }
    }
}

Execution and permissions

• Where to run: within the application runtime where OneAgent is installed and active.
• Permissions: the application process must be able to communicate with the local OneAgent socket.
• Risk: high-cardinality dimensions, e.g., adding a unique OrderID as a dimension, can cause metric explosion, increased costs and degraded platform performance.

Validation

Verify ingestion with these checks.

1. Metrics Browser: open Metrics in Dynatrace and search for the metric key used in code, e.g., app.orders.processed. If absent after a few minutes, check OneAgent is running in Full Stack mode.
2. OTel intake logs: for OpenTelemetry, open Settings > Integration > OpenTelemetry to monitor intake logs for mapping failures.
3. Resource check: compare CPU and RAM of the application process with SDK versus OTel Collector memory usage to ensure no bottleneck.

Limitations

Both methods are optimized for metrics as aggregates. For deep request-level visibility, use Distributed Tracing rather than pushing high-volume event data through a custom metric pipeline. Over-instrumenting high-cardinality dimensions in either method leads to performance overhead and increased data costs.