# Migrating from the Dynatrace OTel metrics exporter to standard OTLP metrics exporter **URL:** \ **Category:** OpenTelemetry\ **Tags:** opentelemetry\ **Created:** [September 29, 2025, 2:41pm UTC](https://community.dynatrace.com/t/migrating-from-the-dynatrace-otel-metrics-exporter-to-standard-otlp-metrics-exporter/53553 "2025-09-29T14:41:37Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![mreider](https://dub1.discourse-cdn.com/dynatrace/user_avatar/community.dynatrace.com/mreider/32/14971_2.png) [@mreider](https://community.dynatrace.com/u/mreider)\ **Post date:** [September 29, 2025, 2:41pm UTC](https://community.dynatrace.com/t/migrating-from-the-dynatrace-otel-metrics-exporter-to-standard-otlp-metrics-exporter/53553/1 "2025-09-29T14:41:37Z")
I’m asking this question on behalf of anyone who is I still using the deprecated Dynatrace OTel Metric Exporter, and would like to use the standard OTLP metric exporter instead. How does that work? ---
**Author:** ![mreider](https://dub1.discourse-cdn.com/dynatrace/user_avatar/community.dynatrace.com/mreider/32/14971_2.png) [@mreider](https://community.dynatrace.com/u/mreider)\ **Post date:** [September 29, 2025, 2:43pm UTC](https://community.dynatrace.com/t/migrating-from-the-dynatrace-otel-metrics-exporter-to-standard-otlp-metrics-exporter/53553/2 "2025-09-29T14:43:01Z")
## How do I migrate from the deprecated Dynatrace OpenTelemetry metrics exporter to the OTLP exporter? **TL;DR:** The Dynatrace OpenTelemetry metric exporters are deprecated. Migrate by replacing them with the standard **OTLP HTTP exporter** , sending metrics to the Dynatrace OTLP endpoint, and authenticating with an access token. Now that the OpenTelemetry metrics signal is stable and Dynatrace supports native OTLP ingest for traces, metrics, and logs, the custom Dynatrace exporters are no longer needed. _Applies to: OpenTelemetry metrics ingest._ The following sections describe how to migrate from the Dynatrace OpenTelemetry metrics exporter (now deprecated) to the OTLP HTTP exporter and highlight their differences and how to address them. ## Why migrate to the OTLP HTTP exporter ### Background When the OpenTelemetry metrics signal was not yet stable, Dynatrace made it possible to ingest OpenTelemetry metrics by offering its own metric exporters in [several programming languages](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest#dynatrace-opentelemetry-metrics-exporter). These exporters, which rely on the consolidated Dynatrace [metric ingestion protocol](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/extend-dynatrace/extend-metrics/reference/metric-ingestion-protocol), bridged the gap while the OpenTelemetry components were being stabilized. Since then, the OpenTelemetry metrics signal [has been declared stable](https://opentelemetry.io/blog/2022/metrics-announcement/) and Dynatrace has added support for native OpenTelemetry protocol (OTLP) ingest for traces, metrics, and logs, making the Dynatrace custom metric exporters no longer needed. Advantages of switching to the official OTLP HTTP exporter: - You can send metrics from all OpenTelemetry-supported programming languages, which wasn’t possible before, as the Dynatrace metrics exporter wasn’t available in all of them. - The complexity of your OpenTelemetry Collector configuration/pipelines is reduced. With a single OTLP HTTP exporter configuration, you can send all the signals to Dynatrace. ### What is changing With the stabilization of the OpenTelemetry metrics signal and the release of the Dynatrace OTLP metrics ingest API, the Dynatrace custom metrics exporters are now obsolete. As all language SDKs offer an OTLP exporter, it is no longer necessary to use the Dynatrace OpenTelemetry metrics exporter. As a result: - The Dynatrace OpenTelemetry metrics exporters are deprecated and no longer recommended. - The exporters are still available but, after the end of 2023, no support, updates, or compatibility with newer OTel versions will be provided. ### Recommendation If you are using the Dynatrace OpenTelemetry metrics exporter, we recommend that you switch to the official OTLP HTTP exporter available from the OpenTelemetry project. - If you’re using the Dynatrace OpenTelemetry metrics exporter in your applications, go to [Migrate applications](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest/migration-guide-otlp-exporter#migrate-applications) for instructions. - If you’re using the Dynatrace OpenTelemetry metrics exporter in the OpenTelemetry Collector, go to [Migrate collector configuration](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest/migration-guide-otlp-exporter#migrate-collector-configuration) for instructions. ## Get the new ingest URL Before you start the migration, see [OpenTelemetry metrics ingest API](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/otlp-export) to get the URL for the OTLP metrics ingest API. You can use the same token for the OTLP metrics ingest API. The required scope is still  **Ingest metrics**  (`metrics.ingest`). ## Migration steps: This section describes how to migrate your applications from the Dynatrace OpenTelemetry metrics exporter to the OTLP HTTP exporter. ### 1. Install and configure the OTLP HTTP exporter Install the `OTLP HTTP exporter` package in your application. You can use the [OpenTelemetry Registry](https://opentelemetry.io/ecosystem/registry/?s=OTLP&component=exporter&language=) to discover the packages. After installing the exporter package, check the [OpenTelemetry Integration walk-throughs](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/walkthroughs) for instructions on how to configure the OTLP HTTP exporter. You can now uninstall the Dynatrace OpenTelemetry metrics exporter from your application. ### 2. Configure the endpoint and token Apart from configuring the endpoint and token directly via code (as seen in the samples), the OTLP exporter can also be configured via [environment variables](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/). Although the environment variables are the same for all OpenTelemetry SDK languages, the way they are consumed and configured in the SDKs changes. Consult the SDK documentation of your programming language to learn how to configure the OTLP exporter using environment variables. #### Endpoint - When using the signal-agnostic environment variable, `OTEL_EXPORTER_OTLP_ENDPOINT`, use the [OTLP metrics ingest API URL](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest/migration-guide-otlp-exporter#get-the-dynatrace-api-url) without the `/v1/metrics` suffix. - When using the metric-specific environment variable, `OTEL_EXPORTER_OTLP_METRICS_ENDPOINT`, use the full [OTLP metrics ingest API URL](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest/migration-guide-otlp-exporter#get-the-dynatrace-api-url). #### Token The Dynatrace token is transmitted via the `Authorization` HTTP header. Like the endpoint, the OpenTelemetry specification defines one environment variable that is signal-agnostic (`OTEL_EXPORTER_OTLP_HEADERS`) and one that is specific to metrics (`OTEL_EXPORTER_OTLP_METRICS_HEADERS`). A benefit of using the metric-specific environment variable is that you isolate the tokens and reduce the required scope to the specific signal. Regardless of the header environment variable you choose, you can set the value as in this example: `Authorization=Api-Token dt0c01.abc123.abcdefghij1234567890` For details on setting headers via the environment variable, see the [OpenTelemetry documentation](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/#header-configuration). If your language supports configuring the OTLP exporter completely from environment variables (for example, Java), you also need to set the `OTEL_EXPORTER_OTLP_PROTOCOL` to `http/protobuf`, as Dynatrace only supports ingesting OTLP/protobuf data via HTTP. ### 3. Configure the exporter to generate metrics with `delta` aggregation temporality Dynatrace only supports ingesting metrics with `delta` aggregation temporality. To learn more about metric aggregation temporality and how to configure the OTLP exporter to produce `delta` metrics, see [Aggregation temporality](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#temporality). ### 4. Attribute type support When using the Dynatrace OpenTelemetry metrics exporter, only attributes of type `string` are sent to Dynatrace. With the Dynatrace OTLP metrics ingest API, apart from `string` attributes, you can now also send attributes of type `boolean` and `integer`. Attributes of type `double`, `bytes`, `array`, and `map` are currently not supported by Dynatrace and are dropped upon ingest. ### Additional features The following sections describe how to migrate the additional features available in the Dynatrace OpenTelemetry metrics exporter to the OTLP exporter. #### Automatic endpoint and token configuration When using the Dynatrace OpenTelemetry metrics exporter together with Dynatrace OneAgent, the endpoint and token were automatically detected and configured. This is a Dynatrace-specific feature and is not available in the OTLP exporter. See [Configure the endpoint and token](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest/migration-guide-otlp-exporter#configure-endpoint-token) to learn how to configure the endpoint and token. #### Histogram support Dynatrace version 1.300+ Starting with Dynatrace version 1.300, histograms ingestion is supported directly via OTLP ingest API. For Exponential Histogram, Dynatrace ingests the histogram’s `min|max|sum|count` but doesn’t ingest the buckets. #### Metric Key Prefix The automatic metric prefix is a Dynatrace-specific feature and is not available in the OTLP exporter. In this case, you need to modify your metric definitions and add the prefix to them explicitly. If you are using the OpenTelemetry Collector, an alternative is to use the [Metrics Transform Processor](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest/migration-guide-otlp-exporter#collector-key-prefix) to add the prefix to your metrics. #### Default Dimensions Although this feature does not exist in the OTLP exporter, the same result can be achieved in different ways: - Configure the default dimensions as resource or instrumentation scope attributes. - Configure the default dimensions via the [`OTEL_RESOURCE_ATTRIBUTES`](https://opentelemetry.io/docs/languages/sdk-configuration/general/#otel_resource_attributes) environment variable. - Configure the default dimensions in the OpenTelemetry Collector [Metrics Transform Processor](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest/migration-guide-otlp-exporter#collector-default-dimensions). #### Automatically enrich metrics with Dynatrace OneAgent metadata When using the Dynatrace OpenTelemetry metrics exporter together with Dynatrace OneAgent, metrics are automatically enriched with Dynatrace OneAgent metadata. This is a Dynatrace-specific feature and is not available in the OTLP exporter. However, you can get the same result by accessing the OneAgent metadata and adding them as resource attributes. See [Enrich ingested data with Dynatrace-specific dimensions](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/extend-dynatrace/extend-data) for instructions on how to enrich ingested metrics with Dynatrace-specific dimensions. ## Migrate Collector configuration This section describes how to migrate your Collector configuration from the Dynatrace OpenTelemetry metrics exporter to the OTLP HTTP exporter. ### 1. Configure the OTLP HTTP exporter The [OTLP HTTP exporter](https://github.com/open-telemetry/opentelemetry-collector/tree/release/v0.80.x/exporter/otlphttpexporter) is part of the core OpenTelemetry Collector distribution, so there is no need to install any extra modules. The OTLP HTTP exporter in the Collector can be used to send all signals (traces, metrics, and logs). ### 2. Configure the endpoint and token The endpoint and token are required when using the OTLP HTTP exporter in the Collector. #### Endpoint The endpoint can be configured using two different properties: - Property `endpoint` - Property `metrics_endpoint` #### Token The Dynatrace token is transmitted via the `Authorization` HTTP header. The OTLP HTTP exporter in the collector offers a key-value list property that can be used to configure the Dynatrace token: exporters:otlphttp:endpoint: "https://{your-environment-id}.live.dynatrace.com/api/v2/otlp"headers:Authorization: “Api-Token dt0c01.abc123.abcdefghij1234567890” Only one Dynatrace API token can be specified in the OTLP HTTP exporter in the Collector. Be sure to generate a token with all the scopes necessary for all signals you are exporting. For the full list of available settings in the OTLP HTTP exporter, see the [configuration sample](https://github.com/open-telemetry/opentelemetry-collector/blob/release/v0.80.x/exporter/otlphttpexporter/testdata/config.yaml) in the OpenTelemetry Collector repository. ### 3. Make sure metrics have `delta` aggregation temporality Dynatrace only supports ingesting metrics with `delta` aggregation temporality. If your applications are already producing metrics with `delta` temporality (as explained in [Configure the exporter to generate metrics with `delta` aggregation temporality](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest/migration-guide-otlp-exporter#apps-delta-temporality)), you don’t need to do anything in your Collector configuration. An alternative is to use the [Cumulative to Delta processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.80.0/processor/cumulativetodeltaprocessor) as part of your Collector pipeline. Caution: To be able to convert cumulative metrics to delta, the Collector needs to keep the previous values of metrics. In a multiple-instance Collector deployment, this conversion can produce inconsistent data unless it can be guaranteed that metrics from the same source are always processed by the same Collector instance. For this reason, we recommend that you [configure the OTLP exporter](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest/migration-guide-otlp-exporter#apps-delta-temporality) in your applications to output `delta` metrics to the Collector. ### 4. Attribute type support When using the Dynatrace OpenTelemetry metrics exporter in the Collector, all attributes were converted to `string` by using the Collector’s internal transformation logic. This logic transformed the attribute types as follows: - `boolean`, `integer`, `double`: converted to their string representation - `bytes`: converted to a base64 string - `array` and `map`: converted to a JSON string If you are recording attributes of type `double`, `bytes`, `array`, or `map`, when migrating to the OTLP exporter in the Collector you must use the [Attributes Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.80.0/processor/attributesprocessor) in your pipeline so the attributes continue to be exported to Dynatrace as before. processors:attributes/convert:actions:- key: my.double.attributeaction: convertconverted\_type: string- key: my.byte.attributeaction: convertconverted\_type: string- key: my.array.attributeaction: convertconverted\_type: string- key: my.map.attributeaction: convertconverted\_type: string Attributes of types `double`, `bytes`, `array`, and `map` are currently not supported by Dynatrace. If you are recording attributes of these types and you don’t configure the attributes processor in your Collector pipeline, these attributes are dropped upon ingest. ### Additional features The following sections describe how to migrate the additional features available in the Dynatrace OpenTelemetry metrics exporter to the OTLP exporter. #### Automatic Endpoint and Token configuration When using the Dynatrace OpenTelemetry metrics exporter together with Dynatrace OneAgent, the endpoint and token were automatically detected and configured. This is a Dynatrace-specific feature and is not available in the OTLP exporter. See [Configure the endpoint and token](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/ingest/migration-guide-otlp-exporter#configure-collector-endpoint-token) to learn how to configure the endpoint and token in the Collector. #### Histogram support Dynatrace version 1.300+ Starting with Dynatrace version 1.300, histograms ingestion is supported directly via OTLP ingest API. For Exponential Histogram, Dynatrace ingests the histogram’s `min|max|sum|count` but doesn’t ingest the buckets. #### Metric key prefix The metric key prefix feature in the Dynatrace OpenTelemetry metrics exporter can be replaced by the [Metrics Transform Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/metricstransformprocessor#metrics-transform-processor) in the Collector by using the “rename metric” feature: # Add a prefix “myprefix” to a “system.cpu.usage” metricinclude: system.cpu.usageaction: updatenew\_name: myprefix.system.cpu.usage\_time You can also rename multiple metrics by using a combination of regex/substitution. See the [Rename multiple metrics using Substitution](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.80.0/processor/metricstransformprocessor#rename-multiple-metrics-using-substitution) sample in the Collector repository for an example. #### Default dimensions The default dimensions feature in the Dynatrace OpenTelemetry metrics exporter can be replaced by the [Metrics Transform Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/metricstransformprocessor#metrics-transform-processor) in the Collector by using the “add label” feature: # Add a label `my.label` with value `my.value` to the ‘system.cpu.usage’ metricinclude: system.cpu.usageaction: updateoperations:- action: add\_labelnew\_label: my.labelnew\_value: my.value You can also add labels to multiple metrics by using a regex to select the metrics. See the [Add a label to multiple metrics](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/metricstransformprocessor#add-a-label-to-multiple-metrics) sample in the Collector repository for an example. #### Resource to telemetry conversion Although this feature does not exist in the OTLP exporter, the Dynatrace OTLP metrics ingest API enables you to define a list of allowed resource and instrumentation scope attributes that are then automatically added as dimensions to all ingested metrics. For details, see [Configure resource and scope attributes to be added as dimensions](https://docs.spine-dev.internal.dynatracelabs.com/preview/dynatrace-docs/pr-6256/docs/ingest-from/opentelemetry/send-data/monitor-ingest/metrics/configuration#allow-list).