Best practices for OpenTelemetry metrics
There are various guidelines and recommendations to keep in mind when working with OpenTelemetry, as with almost any other area of software engineering.
For OpenTelemetry metrics, we recommend following these best practices.
Check our samples
We provide you with working instrumentation samples in selected languages as well as sample code in Java for all the OpenTelemetry instruments.
For more information, see OpenTelemetry metrics.
Use descriptive names
Use descriptive names for instruments, keys, and dimensions. Descriptive names enhance observability, especially in case of an error, making root cause analysis more efficient.
For more information, check the OpenTelemetry documentation on metrics semantic conventions.
Use gzip compression
We recommend using gzip compression.
For more information, see Performance.
Use an OTLP metrics exporter
Dynatrace recommends using an OTLP (OpenTelemetry Protocol) metrics exporter.
With the exporter, you can send data directly to Dynatrace from your applications or from an OpenTelemetry collector.
The OTLP exporter is available for all languages supported by OpenTelemetry Metrics.
For more information, see OTLP metrics exporters.
Limit payload size
We recommend a maximum payload size of 4MB.
For more information, see Performance.
Refer to limits and limitations
Data points can be dropped if, for example, their keys do not match the expected syntax.
For more information, see OpenTelemetry Metrics Limitations.
Use a collector
A collector is an exceptional vendor-agnostic tool for handling telemetry data.
- It can receive data in numerous formats, process it, and send it out to various backends, including Dynatrace.
- Every collector component can be defined and enabled with a single YAML file, which reduces the code that has to be maintained.
However, in an application instrumented through the standardized OTLP format, there is no need for a collector.
For more information about collectors, see OpenTelemetry Collector
Use a batch processor when using a collector
We recommend using a batch processor. Batching helps to compress the data and reduce the number of outgoing connections required to transmit data, which helps you avoid being rate limited.
For more information, see Performance.
Use dimensions
Dimensions are used in Dynatrace to help distinguish what is being measured in a specific data point.
For example, if you're measuring the number of requests an endpoint has received, you can use dimensions to split that metric into requests that went through (status code 200) and requests that failed (status code 500).
Your dimensions should be well-annotated (recognizable, readable, understandable), have a descriptive name, and provide good information.
In OpenTelemetry, dimensions are called attributes.
Use the default aggregation
Not all aggregation temporalities are suitable for every instrument.
In most cases, the default aggregation recommended by OpenTelemetry will be the best match, so we recommend using the default aggregation. All OpenTelemetry default aggregations work with Dynatrace out of the box.
It is possible to adjust aggregation and aggregation temporality. However, we recommend using the delta aggregation temporality.
For more information on how OpenTelemetry instruments and metrics are received and mapped in Dynatrace, see OpenTelemetry metrics in Dynatrace.