Micrometer is an open source instrumentation framework for JVM-based application metrics. It's used by Spring Boot to record a wide range of metrics. You can ingest Micrometer and Spring Boot metrics and analyze them with Dynatrace Davis® AI end to end in the context of your trace, log, and diagnostics data. With Dynatrace, you get intelligent AI-based observability and automatic root cause analysis for Spring Boot, 15+ pre-instrumented JVM-based frameworks and servers, and custom metrics.
You can use Micrometer in Dynatrace to:
Metrics ingested from Micrometer consume DDUs for custom metrics.
There are two ways of using Micrometer:
Micrometer version 1.8.0+
optional Spring Boot version 2.6.0+
The registry dependency must be added to your project:
implementation 'io.micrometer:micrometer-registry-dynatrace:latest.release'
Replace {micrometer.version}
with the latest version of Micrometer or a specific version that you want to use.
A list of released versions is available on Maven Central.
We recommend that you use the latest version.
<dependency><groupId>io.micrometer</groupId><artifactId>micrometer-registry-dynatrace</artifactId><version>{micrometer.version}</version></dependency>
You can use one of the following ingestion channels to send your Micrometer metrics:
Micrometer uses the concept of a registry to export metrics to monitoring systems.
Micrometer can be configured via a .properties
or .yaml
file used for Spring Boot configuration.
Spring Boot automatically binds properties with the management.dynatrace.metrics.export
prefix to the Dynatrace configuration object.
All configuration should be made through the property files. Manually creating a Micrometer MeterRegistry
breaks the auto-configuration.
Property names for binding attributes from Spring Boot have changed in Spring Boot version 3.0.0. If you use a Spring Boot version before 3.0.0, use management.metrics.export.dynatrace
instead of management.dynatrace.metrics.export
.
OneAgent on Kubernetes nodes does not support the ingestion of Micrometer metrics directly. See Sending Metrics from Kubernetes for more details. If you're using Dynatrace on Kubernetes, we recommend using Dynatrace Operator, which provides autoconfiguration.
For hosts that are monitored by OneAgent, automatic configuration is available. You don't need to specify the API endpoint to ingest the metric—if the uri parameter is not set in the configuration, the metric will be ingested via the OneAgent metric API.
management.dynatrace.metrics.export:v2:metric-key-prefix: "service.component"enrich-with-dynatrace-metadata: truedefault-dimensions:stack: "prod"region: "us-east-1"
management.dynatrace.metrics.export.v2.metric-key-prefix=service.componentmanagement.dynatrace.metrics.export.v2.enrich-with-dynatrace-metadata=truemanagement.dynatrace.metrics.export.v2.default-dimensions.stack=prodmanagement.dynatrace.metrics.export.v2.default-dimensions.region=us-east-1
For hosts that are monitored by OneAgent, automatic configuration is available. You don't need to specify the API endpoint to ingest the metric—if the uri parameter is not set in the configuration, the metric will be ingested via the OneAgent metric API.
DynatraceConfig dynatraceConfig = new DynatraceConfig() {@Override@Nullablepublic String get(String k) {// This method can be used for retrieving arbitrary config items;// null means accepting the defaults defined in DynatraceConfigreturn null;}};DynatraceMeterRegistry registry = DynatraceMeterRegistry.builder(config).build();
After you have sent your metrics, verify the data in the Data Explorer or query them in Grail.
To set up the Dynatrace Micrometer registry, you can use the Dynatrace configuration object (DynatraceConfig
). The object contains the parameters of metric ingestion and is used to construct the Dynatrace registry (DynatraceMeterRegistry
), which is registered with Micrometer to ingest metrics to Dynatrace. You can set the following parameters:
When using Spring Boot, entries in your application.properties
or application.yaml
files will be mapped to the DynatraceConfig
object automatically.
Property
Description
Required
api-version
The version of the Dynatrace API to ingest data to Dynatrace:
V2
(default): Metrics API v2.V1
: Timeseries API v1optional
uri
The ingestion endpoint of the API.
optional
metric-key-prefix
The prefix to be added to all ingested metric keys (for example, a namespace).
optional
enrich-with-dynatrace-metadata
Enrich (true
) or do not enrich (false
) ingested metrics with additional metadata.
If not set, true
is used.
optional
default-dimensions
A list of dimensions to be added to the ingested metrics.
Dimensions are defined as key-value pairs.
optional
use-dynatrace-summary-instruments
Micrometer versions 1.9.x+ Ignore the Dynatrace-specific implementation for summary instruments (Timer
and DistributionSummary
).
The default (true
) uses the new Instruments. Use false
to fall back to 1.8.x behavior.
optional
export-meter-metadata
Micrometer versions 1.12.x+ Turn meter metadata export (unit & description) on or off.
The default (true
) configures the registry to export meter metadata. Use false
to turn off metadata exporting.
optional
All metrics are transformed to follow the Metric ingestion protocol types used by Dynatrace.
Micrometer instrument
Dynatrace metric type
Gauge
gauge,X
Counter
count,delta=X
Timer
gauge,min=X,max=Y,sum=Z,count=N
DistributionSummary
gauge,min=X,max=Y,sum=Z,count=N
LongTaskTimer
gauge,min=X,max=Y,sum=Z,count=N
TimeGauge
gauge,X
FunctionCounter
count,delta=X
FunctionTimer
gauge,min=X,max=Y,sum=Z,count=N
Note that the count
for LongTaskTimers can be misleading as it is likely to double-count depending on the export frequency. In case you require the current number of active tasks, exporting a separate Gauge is more reliable.
Starting with version 1.12.0 of the Dynatrace Micrometer registry, meter metadata (unit and description) is automatically exported to Dynatrace. No code changes are required to start exporting metadata. To turn off metadata export, use the following configuration:
management:metrics:export:dynatrace:v2:export-meter-metadata: false # default: true
management.dynatrace.metrics.export.v2.export-meter-metadata=false
Meter metadata was introduced with Micrometer 1.12.0, which was first included in Spring Boot 3.2.0. The toggles described above are therefore available from Spring Boot 3.2.0.
For previous versions of Micrometer, metadata needs to be specified manually using either the Dynatrace API or web UI. For more information, see Custom metric metadata.
OneAgent cannot be used for Micrometer metric ingestion on Kubernetes nodes. You can configure your Micrometer setup to push metrics directly to Dynatrace using the Metrics API.
By default, JVM metrics are turned off when running Micrometer without Spring Boot. To learn how to enable them, see the Micrometer documentation. After they are enabled and registered with the Dynatrace registry (DynatraceMeterRegistry
), JVM metrics are recorded and sent to Dynatrace automatically.
On hosts that are monitored by OneAgent, these metrics might already be captured by OneAgent.
When running Micrometer in Spring Boot, many metrics are automatically created and sent to Dynatrace, including JVM, process, and disk metrics.
To see all metrics created by your Spring Boot application, navigate to the actuator endpoint on your Spring Boot app (/actuator/metrics
). Some of these metrics might already be captured by OneAgent.
Metrics can be disabled based on their prefix in the Spring Boot configuration. To find out which metrics can be excluded, check your Spring Boot applications actuator endpoint. Be sure to exclude your custom metric key prefix (if any, see metric-key-prefix
) when using this feature.
management.metrics.enable:# disable jvm.memory metricsjvm.memory: false# disable all jvm metrics:jvm: false
# disable jvm.memory metricsmanagement.metrics.enable.jvm.memory=false# disable all jvm metricsmanagement.metrics.enable.jvm=false
It is also possible to disable all metrics first and then only re-enable the desired ones:
management.metrics.enable:# disable all metricsall: false# re-enable only jvm.* metricsjvm: true
# disable all metricsmanagement.metrics.enable.all=false# re-enable jvm.* metricsmanagement.metrics.enable.jvm=true
Micrometer provides meter filters to disable metrics based on a variety of conditions. Meter filters can also be configured via Spring Boot with the @Configuration
annotation.
@Configuration(proxyBeanMethods = false)public class MyMeterRegistryConfiguration {@Beanpublic MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {return registry -> registry.config().meterFilter(MeterFilter.denyNameStartsWith("jvm.gc"));}}
The metric prefix configured for the Dynatrace registry will be applied after filtering, so properties to enable or disable metrics have to be specified using the original metric key without this prefix.
Register MeterFilters before creating or turning on additional metrics, as the MeterFilter
will only be evaluated when the metric is added to the MeterRegistry
.
Spring handles the logging when using Micrometer in the Spring Boot context. The log level for the Micrometer Dynatrace registry can be set via configuration properties.
logging.level.io.micrometer.dynatrace: DEBUG
logging.level.io.micrometer.dynatrace=DEBUG
Starting with Micrometer version 1.9.x, specialized instruments are used in the Dynatrace meter registry for certain summary instruments (DynatraceTimer
and DynatraceDistributionSummary
). Their purpose is to get around a peculiarity in how Micrometer records metrics, which, in some cases, led to metrics being rejected by Dynatrace for having an invalid format. The specialized instruments, tailored to Dynatrace metrics ingestion, prevent the creation of invalid metrics.
useDynatraceSummaryInstruments
toggle to false
.If the apiVersion property is set to V1
, the registry sends data via the Timeseries API v1. For backward compatibility, it defaults to V1
if a deviceId is specified, because this property is required in V1
and is not used in V2
.
Existing setups will continue to work when updating to newer versions of Micrometer. The reported metrics will be assigned to custom devices in Dynatrace.
For the V1
API, you only need to specify the base URL of your environment (for example, https://mySampleEnv.live.dynatrace.com
).
management.dynatrace.metrics.export:# For v1 export, do not append a path to the endpoint URL. For example:# For SaaS: https://{your-environment-id}.live.dynatrace.com# For Managed deployments: https://{your-domain}/e/{your-environment-id}uri: https://{your-environment-id}.live.dynatrace.com# Should be read from a secure sourceapi-token: MY_TOKEN# When setting the device id, metrics will be exported to the v1 timeseries endpoint# Using just device-id (without the v1 prefix) is deprecated, but will work to maintain backwards compatibility.v1:device-id: sample# To disable Dynatrace publishing (for example, in a local development profile), use:# enabled: false# The interval at which metrics are sent to Dynatrace. The default is 1 minute.step: 1m
DynatraceConfig dynatraceConfig = new DynatraceConfig() {@Overridepublic String uri() {// The Dynatrace environment URI without any path. For example:// https://{your-environment-id}.live.dynatrace.comreturn MY_DYNATRACE_URI;}@Overridepublic String apiToken() {// Should be read from a secure sourcereturn MY_TOKEN;}@Overridepublic String deviceId() {return MY_DEVICE_ID;}@Override@Nullablepublic String get(String k) {return null;}};DynatraceMeterRegistry registry = DynatraceMeterRegistry.builder(config).build();// Add the Dynatrace registry to Micrometers global registry.Metrics.addRegistry(registry);