Snippets · Destinations

Send to Dynatrace over OTLP (delta metrics)

Dynatrace ingests OTLP through its environment API with an API token. Its metrics ingest accepts delta temporality only, while most SDKs and receivers produce cumulative counters, so this config converts them with the cumulativetodelta processor in the metrics pipeline only.

OpenTelemetry Collector

OpenTelemetry Collector YAML

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 25
  batch:
    timeout: 5s
  # Dynatrace's OTLP metrics ingest accepts delta temporality only.
  cumulativetodelta: {}

exporters:
  otlphttp/dynatrace:
    endpoint: https://abc12345.live.dynatrace.com/api/v2/otlp
    headers:
      Authorization: Api-Token ${env:DT_API_TOKEN}
    sending_queue:
      enabled: true
      queue_size: 5000
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/dynatrace]
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/dynatrace]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, cumulativetodelta, batch]
      exporters: [otlphttp/dynatrace]

LinkMesh

LinkMesh has no built-in template for this job. Add it as a custom destination in raw mode, with otlphttp as the component type and this body - the same lines as under otlphttp/dynatrace in the collector config:

Custom destination body (otlphttp)

endpoint: https://abc12345.live.dynatrace.com/api/v2/otlp
headers:
  Authorization: Api-Token ${env:DT_API_TOKEN}
sending_queue:
  enabled: true
  queue_size: 5000
retry_on_failure:
  enabled: true
  initial_interval: 5s
  max_interval: 30s
  max_elapsed_time: 300s

How custom components are validated and rolled out: create a custom destination.

Download config.yamlValidated with otelcol-contrib v0.161.0 on 2026-10-26

Complete config files, each checked with the collector's own validate command (otelcol-contrib v0.161.0).

Before and after

Example telemetry in, and what this exact config sent out when we ran it in otelcol-contrib v0.161.0. CI re-runs it on every change and fails if the output differs. Changed values are highlighted.

1 metric in, 1 metric out (3 data points in, 2 out)

Before
metric
http.server.request.count
point 1
5 {"http.route":"/orders"}
point 2
8 {"http.route":"/orders"}
point 3
15 {"http.route":"/orders"}
resource.service.name
checkout
After
metric
http.server.request.count
point 1
3 {"http.route":"/orders"}
point 2
7 {"http.route":"/orders"}
resource.service.name
checkout

The gotcha

cumulativetodelta needs a previous value, so the first reading of every series is not exported. In our test three cumulative readings of one counter, 5, 8 and 15, arrived as two delta points, 3 and 7 - the 5 only became the baseline. Expect a gap of one collection interval per series after the collector starts.

Used in these pipelines

Prometheus counters to a delta-only backend (cumulativetodelta)

Manage this across a fleet

LinkMesh manages collector configuration across a fleet from one self-hosted control plane, so a change like this is made once rather than host by host. The first 25 Collectors are free after a no-card registration in the OpenSight Customer Portal (5 without one).

Doing this in LinkMesh: Create a custom source or destination

Install LinkMesh →See all snippets