OpenTelemetry is an observability framework for cloud-native software. It is used to instrument frameworks and components and export telemetry data (traces, metrics, and logs) for analysis to gain insights into your software's performance and behavior.
With metrics, OpenTelemetry enables you to capture measurements from within your application at runtime.
Along with a better understanding for patterns and the general capacities of your application, you can dive deep into single requests and, for example, detect unusual occurrences on CPU times, number of bytes received, and much more!
OpenTelemetry metric concepts
In OpenTelemetry, the API and SDK are separated to allow for the configuration of different SDKs at runtime. While the API is responsible for capturing the measurements, the SDK is responsible for providing functionality and extensibility (such as configuration and exporters).
For more information on these concepts, see OpenTelemetry metric concepts.
- The MeterProvider, which is the only component accessible by both the API and the SDK. It is responsible for creating Meter instances.
- The Meter, which is responsible for creating instruments. It does not hold any configuration.
- The Instruments, which are responsible for capturing raw measurements. They can only be created by a Meter.
- The View, which is responsible for customization of metrics (for example, customize aggregation or temporality).
- The MetricReader, which is responsible for collecting metrics from the SDK. It has to be connected to an exporter.
- The MetricExporter, which is responsible for sending measurements to a collector or other backend. It is always associated with a MetricReader.
Scenarios for OpenTelemetry metric ingestion
You can send metrics to Dynatrace via any of the following options:
- Via an OTLP (OpenTelemetry Protocol) metrics exporter directly to Dynatrace
- Via an OTLP (OpenTelemetry Protocol) metrics exporter to an OpenTelemetry Collector
- Via the Dynatrace OpenTelemetry metrics exporter directly to Dynatrace
- Via AWS Distro for OpenTelemetry
OpenTelemetry metrics in Dynatrace
The OpenTelemetry metrics do not necessarily map 1:1 to Dynatrace metrics. However, all OpenTelemetry default aggregations work with Dynatrace out of the box.
If you want to manually adjust aggregation or aggregation temporality, you can find more information on how OpenTelemetry instruments and metrics are received and mapped in Dynatrace on OpenTelemetry metrics in Dynatrace.
To elevate the OpenTelemetry metrics' performance, Dynatrace recommends the following:
- Compression via
gzipformat (no default is set)
- Payload size a maximum of 4MB (default limit)
- Batching through the use of a
For details on these recommendations, see Performance.
Limits and limitations
Whenever data comes from your application through the OpenTelemetry Protocol (OTLP) into Dynatrace, it has to pass certain standards before it is ingested.
For example, if you define a metric key containing invalid characters, the respective characters will be replaced by underscore characters and your key will appear altered.
If a metric key or dimension key consists of only invalid characters, the entire data point will be dropped! Make sure to check our OpenTelemetry limits and limitations.
To make instrumenting your application as easy as possible, we have prepared sample code in Java for every OpenTelemetry instrument, as well as a working sample for a handful of languages supported by OpenTelemetry metrics: