Add deprecation note to Dynatrace metrics exporter

.chloggen/add-deprecation-note-dynatrace-exporter.yaml

@@ -0,0 +1,20 @@
+# Use this changelog template to create an entry for release notes.
+# If your change doesn't affect end users, such as a test fix or a tooling change,
+# you should instead start your pull request title with [chore] or use the "Skip Changelog" label.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: 'deprecation'
+
+# The name of the component, or a single word describing the area of concern, (e.g. filelogreceiver)
+component: dynatraceexporter
+
+# A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Add deprecation note to Dynatrace metrics exporter
+
+# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
+issues: [23992]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext:

exporter/dynatraceexporter/README.md

@@ -1,24 +1,29 @@
-[Dynatrace](https://www.dynatrace.com/integrations/opentelemetry/) can receive OpenTelemetry metrics in the following ways:
+# Dynatrace
 
-- Using OTLP/HTTP (OpenTelemetry Protocol) metrics exporter (recommended)
-- Using Dynatrace OpenTelemetry metrics exporter described below
+[Dynatrace](https://www.dynatrace.com/integrations/opentelemetry) supports native
+OpenTelemetry protocol (OTLP) ingest for traces, metrics and logs.
+All signals can be sent directly to Dynatrace via **OTLP protobuf over HTTP**
+using the built-in OTLP/HTTP Exporter available in the collector.
+More information on using the collector with Dynatrace can be found in the
+[Dynatrace documentation](https://www.dynatrace.com/support/help/shortlink/opentelemetry-collector-explanation#configuration).
 
-More information on exporting metrics to Dynatrace can be found in the
-[Dynatrace documentation for OpenTelemetry metrics](https://www.dynatrace.com/support/help/shortlink/opentelemetry-metrics).
+## Dynatrace Metrics Exporter
 
-For ingesting traces (spans) into Dynatrace, use the generic OTLP/HTTP exporter shipped with the Collector.  
-More information on exporting traces to Dynatrace can be found in the
-[Dynatrace documentation for OpenTelemetry traces](https://www.dynatrace.com/support/help/extend-dynatrace/opentelemetry/opentelemetry-traces/opentelemetry-ingest).
-
-# Dynatrace Exporter
+> **Warning**
+> Dynatrace supports native OpenTelemetry protocol (OTLP) ingest for traces, metrics and logs.
+> Therefore, the proprietary Dynatrace OpenTelemetry metrics exporter is deprecated in favor of exporting via OTLP/HTTP.
+> 
+> The exporter is still available but after the end of 2023, no support, updates, or compatibility with newer OTel versions will be provided.
+>
+> Check out the [migration guide](https://www.dynatrace.com/support/help/shortlink/migrating-dynatrace-metrics-exporter-otlp-exporter#migrate-collector-configuration) to learn how to migrate to the OTLP HTTP exporter. For a collector configuration example, please refer to the [collector configuration](https://www.dynatrace.com/support/help/shortlink/opentelemetry-collector-explanation#collector-configuration) page in the Dynatrace documentation.
 
 <!-- status autogenerated section -->
 | Status        |           |
 | ------------- |-----------|
-| Stability     | [beta]: metrics   |
+| Stability     | [deprecated]: metrics   |
 | Distributions | [contrib], [aws], [observiq] |
 
-[beta]: https://github.com/open-telemetry/opentelemetry-collector#beta
+[deprecated]: https://github.com/open-telemetry/opentelemetry-collector#deprecated
 [contrib]: https://github.com/open-telemetry/opentelemetry-collector-releases/tree/main/distributions/otelcol-contrib
 [aws]: https://github.com/aws-observability/aws-otel-collector
 [observiq]: https://github.com/observIQ/observiq-otel-collector
@@ -33,14 +38,14 @@ using the [metrics ingestion protocol](https://www.dynatrace.com/support/help/ho
 > which contains recommendations on securing sensitive information such as the
 > API key required by this exporter.
 
-## Requirements
+### Requirements
 
 You will either need a Dynatrace OneAgent (version 1.201 or higher) installed on the same host as the Collector; or a Dynatrace environment with version 1.202 or higher.
 
 - Collector contrib minimum version: 0.18.0
 
 
-## Getting Started
+### Getting Started
 
 The Dynatrace exporter is enabled by adding a `dynatrace` entry to the `exporters` section of your config file.
 All configurations are optional, but if an `endpoint` other than the OneAgent metric ingestion endpoint is specified then an `api_token` is required.
@@ -50,7 +55,7 @@ To see all available options, see [Advanced Configuration](#advanced-configurati
 > with DELTA temporality. If you are exporting Sum or Histogram metrics with CUMULATIVE temporality, read
 > about possible limitations of this exporter [below](#considerations-when-exporting-cumulative-data-points).
 
-### Running alongside Dynatrace OneAgent (preferred)
+#### Running alongside Dynatrace OneAgent (preferred)
 
 If you run the Collector on a host or VM that is monitored by the Dynatrace OneAgent then you only need to enable the exporter. No further configurations needed. The Dynatrace exporter will send all metrics to the OneAgent which will use its secure and load balanced connection to send the metrics to your Dynatrace SaaS or Managed environment.
 Depending on your environment, you might have to enable metrics ingestion on the OneAgent first as described in the [Dynatrace documentation](https://www.dynatrace.com/support/help/how-to-use-dynatrace/metrics/metric-ingestion/ingestion-methods/opentelemetry/).
@@ -63,7 +68,7 @@ exporters:
     ## No options are required. By default, metrics will be exported via the OneAgent on the local host.
 ```
 
-### Running standalone
+#### Running standalone
 
 If you run the Collector on a host or VM without a OneAgent you will need to configure the Metrics v2 API endpoint of your Dynatrace environment to send the metrics to as well as an API token.
 
@@ -91,7 +96,7 @@ exporters:
 
 You can learn more about how to use the Dynatrace API [here](https://www.dynatrace.com/support/help/dynatrace-api/).
 
-### Metric Batching
+#### Metric Batching
 
 Dynatrace recommends the use of the batch processor with a maximum batch size of 1000 metrics and a timeout between 10 and 60 seconds. Batches with more than 1000 metrics may be throttled by Dynatrace.
 
@@ -137,7 +142,7 @@ service:
 
  ```
 
-## Advanced Configuration
+### Advanced Configuration
 
 Several helper files are leveraged to provide additional capabilities automatically:
 
@@ -184,34 +189,34 @@ service:
       exporters: [dynatrace]
 ```
 
-### default_dimensions (Optional)
+#### default_dimensions (Optional)
 
 `default_dimensions` are included as dimensions on all exported metrics unless that metric already has a dimension with the same key.
 `default_dimensions` is specified as a map of string key-value pairs.
 
-### prefix (Optional)
+#### prefix (Optional)
 
 Prefix is a string which will be used as the first part of a dot-separated metric key.
 For example, if a metric with name `request_count` is prefixed with `my_service`, the resulting
 metric key is `my_service.request_count`.
 
-### headers (Optional)
+#### headers (Optional)
 
 Additional headers to be included with every outgoing http request.
 
-### read_buffer_size (Optional)
+#### read_buffer_size (Optional)
 
 Defines the buffer size to allocate to the HTTP client for reading the response.
 
 Default: `4096`
 
-### write_buffer_size (Optional)
+#### write_buffer_size (Optional)
 
 Defines the buffer size to allocate to the HTTP client for writing the payload
 
 Default: `4096`
 
-### timeout (Optional)
+#### timeout (Optional)
 
 Timeout specifies a time limit for requests made by this
 Client. The timeout includes connection time, any
@@ -223,7 +228,7 @@ https://golang.org/pkg/net/http/#Client
 
 Default: `0`
 
-### tls.insecure_skip_verify (Optional)
+#### tls.insecure_skip_verify (Optional)
 
 Additionally you can configure TLS to be enabled but skip verifying the server's certificate chain.
 This cannot be combined with `insecure` since `insecure` won't use TLS at all.
@@ -232,39 +237,39 @@ More details can be found in the collector readme for
 
 Default: `false`
 
-### retry_on_failure.enabled (Optional)
+#### retry_on_failure.enabled (Optional)
 
 Default: `true`
 
-### retry_on_failure.initial_interval (Optional)
+#### retry_on_failure.initial_interval (Optional)
 
 Time to wait after the first failure before retrying; ignored if enabled is false.
 
 Default: `5s`
 
-### retry_on_failure.max_interval (Optional)
+#### retry_on_failure.max_interval (Optional)
 
 The upper bound on backoff; ignored if enabled is false
 
 Default: `30s`
 
-### retry_on_failure.max_elapsed_time (Optional)
+#### retry_on_failure.max_elapsed_time (Optional)
 
 The maximum amount of time spent trying to send a batch; ignored if enabled is false.
 
 Default: `120s`
 
-### sending_queue.enabled (Optional)
+#### sending_queue.enabled (Optional)
 
 Default: `true`
 
-### sending_queue.num_consumers (Optional)
+#### sending_queue.num_consumers (Optional)
 
 Number of consumers that dequeue batches; ignored if enabled is false.
 
 Default: `10`
 
-### sending_queue.queue_size (Optional)
+#### sending_queue.queue_size (Optional)
 
 Maximum number of batches kept in memory before data; ignored if enabled is false;
 User should calculate this as `num_seconds * requests_per_second` where:
@@ -274,7 +279,7 @@ User should calculate this as `num_seconds * requests_per_second` where:
 
 Default: `1000`
 
-### resource_to_telemetry_conversion (Optional)
+#### resource_to_telemetry_conversion (Optional)
 
 When `resource_to_telemetry_conversion.enabled` is set to `true`, all resource
 attributes will be included as metric dimensions in Dynatrace in addition to the
@@ -314,11 +319,11 @@ service:
       exporters: [dynatrace]
 ```
 
-### tags (Deprecated, Optional)
+#### tags (Deprecated, Optional)
 
 **Deprecated: Please use [default_dimensions](#default_dimensions-optional) instead**
 
-# Temporality
+### Temporality
 
 If possible when configuring your SDK, use DELTA temporality for Counter, Asynchronous Counter, and Histogram metrics.
 Use CUMULATIVE temporality for UpDownCounter and Asynchronous UpDownCounter metrics.
@@ -330,21 +335,21 @@ if you are unsure if the SDK you are using supports this configuration.
 You can read more about this and other configurations at
 [OpenTelemetry Metrics Exporter - OTLP](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk_exporters/otlp.md#additional-configuration).
 
-## Considerations when exporting Cumulative Data Points
+#### Considerations when exporting Cumulative Data Points
 
 Histogram metrics with CUMULATIVE temporality are NOT SUPPORTED and will NOT be exported.
 
 When possible, Sum metrics should use DELTA temporality.
 When receiving Sum metrics with CUMULATIVE temporality, this exporter performs CUMULATIVE to DELTA conversion.
 This conversion can lead to missing or inconsistent data, as described below:
 
-### First Data Points are dropped
+##### First Data Points are dropped
 
 Due to the conversion, the exporter will drop the first received data point
 after a counter is created or reset as there is no previous data point to compare it to.
 This can be circumvented by configuring the OpenTelemetry SDK to export DELTA values.
 
-## Multi-instance collector deployment
+#### Multi-instance collector deployment
 
 In a multiple-instance deployment of the OpenTelemetry Collector, the conversion 
 can produce inconsistent data unless it can be guaranteed that metrics from the 

exporter/dynatraceexporter/metadata.yaml

@@ -3,5 +3,5 @@ type: dynatrace
 status:
   class: exporter
   stability:
-    beta: [metrics]
+    deprecated: [metrics]
   distributions: [contrib, aws, observiq]