I want to export health information provided by Spring Boot's health endpoint (/health) to Prometheus. Is there an easy (standard) way to do this with micrometer?

Hi thanks for the lib! I am facing a problem: I have several ExecutorServices, and want to monitor their metrics. I use code like the following:

        scheduledThreadPoolExecutor = new ScheduledThreadPoolExecutor(config.getBackForthScheduledThreadPoolCoreSize());
        scheduledThreadPoolExecutor.setRemoveOnCancelPolicy(true);

        new ExecutorServiceMetrics(scheduledThreadPoolExecutor, "ws.back.forth.executor", null)
                .bindTo(meterRegistry);

// ... have multiple executors, thus have multiple `new ExecutorServiceMetrics`

However, it throws the following error:

...
Caused by: java.lang.IllegalArgumentException: Collector already registered that provides name: executor_completed_tasks_total
	at io.prometheus.client.CollectorRegistry.register(CollectorRegistry.java:54)
	at io.prometheus.client.Collector.register(Collector.java:139)
	at io.micrometer.prometheus.PrometheusMeterRegistry.lambda$applyToCollector$16(PrometheusMeterRegistry.java:410)
	at java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1955)
	at io.micrometer.prometheus.PrometheusMeterRegistry.applyToCollector(PrometheusMeterRegistry.java:406)
	at io.micrometer.prometheus.PrometheusMeterRegistry.newFunctionCounter(PrometheusMeterRegistry.java:240)
	at io.micrometer.core.instrument.MeterRegistry$More.lambda$counter$1(MeterRegistry.java:920)
	at io.micrometer.core.instrument.MeterRegistry.lambda$registerMeterIfNecessary$5(MeterRegistry.java:561)
	at io.micrometer.core.instrument.MeterRegistry.getOrCreateMeter(MeterRegistry.java:614)
	at io.micrometer.core.instrument.MeterRegistry.registerMeterIfNecessary(MeterRegistry.java:568)
	at io.micrometer.core.instrument.MeterRegistry.registerMeterIfNecessary(MeterRegistry.java:561)
	at io.micrometer.core.instrument.MeterRegistry.access$700(MeterRegistry.java:77)
	at io.micrometer.core.instrument.MeterRegistry$More.counter(MeterRegistry.java:920)
	at io.micrometer.core.instrument.FunctionCounter$Builder.register(FunctionCounter.java:122)
	at io.micrometer.core.instrument.binder.jvm.ExecutorServiceMetrics.monitor(ExecutorServiceMetrics.java:312)
	at io.micrometer.core.instrument.binder.jvm.ExecutorServiceMetrics.bindTo(ExecutorServiceMetrics.java:275)
	at com.rzzsdxx.proj.support_modules.web_socket.back_forth.impl.WsBackForthService.<init>(WsBackForthService.java:60)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
	at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:212)

What should I do? Thanks!

Looks like the 'direct' api for 1.x will not work with 2.0. Thankfully the changes seem pretty small, for comparison 1.x write api and 2.x write api

The body remains the same (line protocol), only major change I believe is for auth (though user + password is probably also possible), instead of db query param there is org and bucket. There is also an official java client library, though I am not sure if micrometer needs all the functionality it provides.

Sorry if there is already something in place to configure micrometer so it works with influxdb 2.0 (directly), but I did not find it.

Micrometer core and micrometer-elastic version: 1.1.3

Springboot version: 2.1.3.RELEASE

Hi, Using micrometer getting metrics from springboot application using micrometer-registry-elastic

Micrometer keeps logging error messages:

ERROR [market-fetcher,,,] 8106 --- [trics-publisher] i.m.elastic.ElasticMeterRegistry : failed to send metrics to elastic:

When checking elastic index it's working, index get's updated with new values but I noticed one of the entries in there reports an error:

{"index":{"_index":"market-fetcher-metrics-2019-04","_type":"doc","_id":"XyEp_WkB2oH6K2ScUlT5","status":400,"error":{"type":"mapper_parsing_exception","reason":"failed to parse [value]","caused_by":{"type":"illegal_argument_exception","reason":"[float] supports only finite values, but got [Infinity]"}}}}

which is probably what's causing the error log entry being generated. I guess it should instead be able to wrap / handle Infinity? Also not sure where the error is exactly from as we don't explicitly wrap any of the metrics in primitive float, still investigating that.

Find below a full entry of the log error message and pls let me know if it needs further details.

'2019-04-08 15:35:37.761 ERROR [market-fetcher,,,] 8106 --- [trics-publisher] i.m.elastic.ElasticMeterRegistry : failed to send metrics to elastic: {"took":24,"errors":true,"items":[{"index":{"_index":"market-fetcher-metrics-2019-04","_type":"doc","_id":"CCEp_WkB2oH6K2ScUlT5","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":322,"_primary_term":1,"status":201}},{"index":{"_index":"market-fetcher-metrics-2019-04","_type":"doc","_id":"CSEp_WkB2oH6K2ScUlT5","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":328,"_primary_term":1,"status":201}}, ... ,{"index":{"_index":"market-fetcher-metrics-2019-04","_type":"doc","_id":"XyEp_WkB2oH6K2ScUlT5","status":400,"error":{"type":"mapper_parsing_exception","reason":"failed to parse [value]","caused_by":{"type":"illegal_argument_exception","reason":"[float] supports only finite values, but got [Infinity]"}}}},{"index":{"_index":"market-fetcher-metrics-2019-04","_type":"doc","_id":"YCEp_WkB2oH6K2ScUlT5","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":345,"_primary_term":1,"status":201}},{"index":{"_index":"market-fetcher-metrics-2019-04","_type":"doc","_id":"YSEp_WkB2oH6K2ScUlT5","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":341,"_primary_term":1,"status":201}}, ... ,{"index":{"_index":"market-fetcher-metrics-2019-04","_type":"doc","_id":"EiEp_WkB2oH6K2ScUlX6","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":383,"_primary_term":1,"status":201}}]}'

Describe the bug I can't get remote baggage fields to propagate using spring boot 3 and micrometer tracing.

Environment Local machine

• Micrometer version: 1.0.0
• Micrometer registry : N/A
• OS: macOS
• Java version: 19.0.1

To Reproduce How to reproduce the bug:

1. See project: https://github.com/eitansuez/dtrace-boot3-example which contains an automated test that fails, or..
2. ..Use the micrometer sample module "baggage consumer" https://github.com/micrometer-metrics/micrometer-samples/tree/main/baggage-consumer as follows: start the app (gradle bootRun), then curl the endpoint at localhost:7200/ with the header "myremotefield" and value "my-remote-field-value" and note how the RemoteFieldsTestChecker returns an error.

Expected behavior If i define a baggage remote-field to propagate, i expect that field to show up in http requests to upstream services.

Additional context Slack thread: https://micrometer-metrics.slack.com/archives/C662HUJC9/p1670600358434289

I am looking into sending a counter meter data from my application and calculate SLO out of it in Stackdriver. Stackdriver is allowing to send two kinds of metrics: GAUGE and CUMULATIVE and Micrometer's Stackdriver registry is using GAUGE for all the meters. The problem is that Stackdriver can't calculate, so called, request-based SLO out of a GAUGE metric, because it is conceptually a discrete sample of state and for request-based SLO, full information is required. I think sending CUMULATIVE data for a Counter meter would not only solve my problem, but also would be a better representation of what it is doing. I prepared my proposed implementation and would also try to submit it as a pull request.

Resolves #2773

Micrometer version: 1.1.2

Publishing metrics with statsD micrometer occasionally throws the following exception:

i.m.s.i.n.u.ResourceLeakDetector: LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 
Created at:
    io.micrometer.shaded.io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:349)
    io.micrometer.shaded.io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187)
    io.micrometer.shaded.io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:173)
    io.micrometer.shaded.io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:107)
    io.micrometer.shaded.reactor.netty.NettyOutbound.lambda$sendString$5(NettyOutbound.java:300)
    io.micrometer.shaded.reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:100)
    io.micrometer.shaded.reactor.core.publisher.FluxOnBackpressureLatest$LatestSubscriber.drain(FluxOnBackpressureLatest.java:176)
    io.micrometer.shaded.reactor.core.publisher.FluxOnBackpressureLatest$LatestSubscriber.onNext(FluxOnBackpressureLatest.java:127)
    io.micrometer.shaded.reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:114)
    io.micrometer.shaded.reactor.core.publisher.FluxBufferPredicate$BufferPredicateSubscriber.onNextNewBuffer(FluxBufferPredicate.java:277)
    io.micrometer.shaded.reactor.core.publisher.FluxBufferPredicate$BufferPredicateSubscriber.tryOnNext(FluxBufferPredicate.java:224)
    io.micrometer.shaded.reactor.core.publisher.FluxBufferPredicate$BufferPredicateSubscriber.onNext(FluxBufferPredicate.java:194)
    io.micrometer.shaded.reactor.core.publisher.FluxFlatMap$FlatMapMain.tryEmit(FluxFlatMap.java:530)
    io.micrometer.shaded.reactor.core.publisher.FluxFlatMap$FlatMapInner.onNext(FluxFlatMap.java:972)
    io.micrometer.shaded.reactor.core.publisher.FluxPeek$PeekSubscriber.onNext(FluxPeek.java:192)
    io.micrometer.shaded.reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
    io.micrometer.shaded.reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
    io.micrometer.shaded.reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
    io.micrometer.shaded.reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
    io.micrometer.statsd.StatsdDistributionSummary.recordNonNegative(StatsdDistributionSummary.java:52)
    io.micrometer.core.instrument.AbstractDistributionSummary.record(AbstractDistributionSummary.java:49)
    io.micrometer.core.instrument.composite.CompositeDistributionSummary.lambda$record$0(CompositeDistributionSummary.java:38)
    java.base/java.lang.Iterable.forEach(Iterable.java:75)
    io.micrometer.core.instrument.composite.AbstractCompositeMeter.forEachChild(AbstractCompositeMeter.java:47)
    io.micrometer.core.instrument.composite.CompositeDistributionSummary.record(CompositeDistributionSummary.java:38)

Hi, I tried to create a list of gauge from the result of a query and i didn't find any way to do that.

I have the following query which return the size of elements in database (postgres) :

SELECT N.nspname || '.' || C.relname AS "relation", CASE WHEN reltype = 0 THEN pg_total_relation_size(C.oid) ELSE pg_total_relation_size(C.oid) END AS "size" FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) LEFT JOIN pg_tables T ON (T.tablename = C.relname) LEFT JOIN pg_indexes I ON (I.indexname = C.relname) WHERE nspname NOT IN ('pg_catalog','pg_toast','information_schema');

My idea was to create a list of gauge with : id : 'db.relation.size' with tag 'relation' and value 'size'.

So that why i wanted to create a single function that perform the sql call and that allow me to create a list of gauge.

Maybe I'm wrong and that's not the right way of doing that or maybe this is contrary to the philosophy of Micrometer.

Thanks in advance of your help.

I foresee two primary modules in this project. The Spring aspect that leverages actuator, etc makes sense being called spring-metrics, however the other aspect is similar to slf4j and really is just a metrics-facade.

I would love to be able to encourage all Java project to leverage the facade benefits, even if they aren't using Spring and I wouldn't want the name to drive them away.

Ideas:

• metrics-interface (maybe shortened to mi4j, but then it looks like leet speak 'miaj'), also is pretty generic,
• meterize - Memorable and unique, also leverages the 'meter' terminology well
• dendro - Out in left field, but 'dendrochronology' is the science of measuring tree growth via rings. (trees grows a lot during the 'Spring') ... yeah a stretch.

I realize that optional deps can keep the modules flexible, but it does feel like if the 2 concerns are made explicit it could save confusion in the long run.

I favor meterize, and spring-metrics, even though the names aren't parallel.

I don't think this is urgent, just wanted to make sure we had this conversation.

Micrometer version: 1.1.0 Spring boot version: 5.1.0 JDK version: 11

There seem to be multiple issues with the Stackdriver integration of Micrometer:

1. Metrics are created, but are not under the Global resource it seems. (The ones with global were created using our current solution) See also the screenshot below.
2. When debugging, the StackdriverMeterRegistry#publish call is just done once. With the LoggingMeterRegistry, the publish-method is called every interval.
3. Any way of using Spring integration with actuator?
4. Feature request: Can we use the prefix for the custom metric, so instead of custom/jvm/buffer/etc something like custom/{prefix}/jvm/buffer/etc? This makes it much easier to distinguish between services running in the same project.
5. I'm also missing the documentation right now. ;-)

See also the demo zip I have added for my sample code. monitoringdemo.zip

Describe the bug When using KafkaStreamsMetrics the heap-usage seems to be ever-increasing for objects of type io.micrometer.core.instrument.ImmutableTag.

Internally in KafkaMetrics theres a Set holding "registeredMeters":

private final Set<Meter> registeredMeters = ConcurrentHashMap.newKeySet();

https://github.com/micrometer-metrics/micrometer/blob/1.7.x/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/kafka/KafkaMetrics.java#L92

Every minute a scheduler runs KafkaMetrics#checkAndBindMetrics, which retrieves all metrics from the metric-supplier (KafkaStreams#metrics) and checks if currentMeters.equals(metrics.keySet()). If false the metrics returned from the metric-supplier are passed to KafkaMetrics#bindMeter which registers a new meter and add the meter to the registeredMeters set (https://github.com/micrometer-metrics/micrometer/blob/1.7.x/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/kafka/KafkaMetrics.java#L221). Any existing meter with the same name/tags is not removed, so every time this is done, the set will increase.

This would not be a problem if the metric-supplier (KafkaStreams#metrics) returned the same metrics on each call, but this can actually vary a lot. After rebalances for example, KafkaStreams#Metrics returns "consumer-fetch-manager" metrics for a while. Every time the call differs from the previous, all kafka-streams metrics (~3-4000 metrics) are added to the set.

Here is a heap-dump of an app which has been running for a couple of days and gone through a lot of rebalances and broker restarts. It eventually OOM's:

I guess the fix here would be to clean the existing registeredMeters set before adding new ones. It was introduced in this issue: https://github.com/micrometer-metrics/micrometer/issues/2018 https://github.com/micrometer-metrics/micrometer/commit/603264632e3be5336902f65d42abbf2ed6769d45

Environment

• Micrometer version: 1.7.5
• Micrometer registry: prometheus
• OS: macOS, ubuntu
• Java version: openjdk version "1.8.0_302"

To Reproduce Added sample app. Run multiple instances, restart one instance to trigger rebalances, watch the io.micrometer.core.instrument.binder.kafka.KafkaMetrics.registeredMeters increase after scheduled calls to "checkAndBindMetrics" https://github.com/JorgenRingen/micrometer_1_7_5_high_heap_usage

Expected behavior HEAP-usage should not gradually increase when return from KafkaStreams#metrics changes over time, but remain stable.

Any additional context Don't know why we're suddenly experiencing this issue, we have been using KafkaStreamsMetrics for some time, but an upgrade to kafka-streams 2.8.x and more variance between calls to KafkaStreams#metrics might be the cause.

Bumps com.gradle.enterprise from 3.12 to 3.12.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Describe the bug Calling MeterRegistry#clear from multiple threads causes weird bugs with missing/incorrect metrics

Environment

• Micrometer version: 1.10.2
• Micrometer registry: Prometheus
• OS: Linux
• Java version: openjdk version "17.0.5" 2022-10-18

To Reproduce How to reproduce the bug:

Minimal repro application: https://github.com/perlun/micrometer-registration-unregistration-issue

Expected behavior The tests should work consistently.

Actual behavior The MicrometerRegistrationTest fails around 30% of the time:

Here is one of the failures:

Expected size: 1 but was: 0 in:
[]
java.lang.AssertionError: 
Expected size: 1 but was: 0 in:
[]
	at micrometer.registration.unregistration.issue.MicrometerRegistrationTest.recorder_job_metric_is_published_using_expected_name(MicrometerRegistrationTest.java:68)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
	at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
	at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
	at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
	at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
	at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestTemplateMethod(TimeoutExtension.java:94)
	at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
	at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
	at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
	at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
	at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
	at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
	at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
	at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
	at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
	at org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
	at org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.submit(ForkJoinPoolHierarchicalTestExecutorService.java:118)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask$DefaultDynamicTestExecutor.execute(NodeTestTask.java:226)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask$DefaultDynamicTestExecutor.execute(NodeTestTask.java:204)
	at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:142)
	at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.lambda$execute$2(TestTemplateTestDescriptor.java:110)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
	at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	at java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180)
	at java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104)
	at java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:711)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
	at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:276)
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
	at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:110)
	at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:44)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
	at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
	at org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
	at org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.invokeAll(ForkJoinPoolHierarchicalTestExecutorService.java:129)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
	at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
	at org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
	at java.base/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:194)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)

Here's another test failure:

expected: "centre_job_recorder_programs_total{type="processed",} 42.0"
 but was: "centre_job_recorder_programs_total{type="processed",} 0.0"
org.opentest4j.AssertionFailedError: 
expected: "centre_job_recorder_programs_total{type="processed",} 42.0"
 but was: "centre_job_recorder_programs_total{type="processed",} 0.0"
	at [email protected]/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at [email protected]/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
	at [email protected]/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at [email protected]/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at app//micrometer.registration.unregistration.issue.MicrometerRegistrationTest.recorder_job_metric_is_published_using_expected_name(MicrometerRegistrationTest.java:70)
	at [email protected]/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at [email protected]/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at [email protected]/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at [email protected]/java.lang.reflect.Method.invoke(Method.java:568)
	at app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
	at app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
	at app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
	at app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
	at app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
	at app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestTemplateMethod(TimeoutExtension.java:94)
	at app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
	at app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
	at app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
	at app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
	at app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
	at app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
	at app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
	at app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
	at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
	at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
	at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
	at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
	at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
	at app//org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
	at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
	at app//org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
	at app//org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.submit(ForkJoinPoolHierarchicalTestExecutorService.java:118)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask$DefaultDynamicTestExecutor.execute(NodeTestTask.java:226)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask$DefaultDynamicTestExecutor.execute(NodeTestTask.java:204)
	at app//org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:142)
	at app//org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.lambda$execute$2(TestTemplateTestDescriptor.java:110)
	at [email protected]/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	at [email protected]/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
	at [email protected]/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
	at [email protected]/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
	at [email protected]/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	at [email protected]/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180)
	at [email protected]/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104)
	at [email protected]/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:711)
	at [email protected]/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at [email protected]/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at [email protected]/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at [email protected]/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at [email protected]/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at [email protected]/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
	at [email protected]/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:276)
	at [email protected]/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
	at [email protected]/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at [email protected]/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at [email protected]/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at [email protected]/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at [email protected]/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at [email protected]/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
	at app//org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:110)
	at app//org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:44)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
	at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
	at app//org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
	at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
	at app//org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
	at app//org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.invokeAll(ForkJoinPoolHierarchicalTestExecutorService.java:129)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
	at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
	at app//org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
	at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
	at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
	at app//org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
	at [email protected]/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:194)
	at [email protected]/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
	at [email protected]/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
	at [email protected]/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
	at [email protected]/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
	at [email protected]/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)

Additional context We have a wrapper class on top of MeterRegistry which is called MicrometerRegistryFactory. This has historical reasons since we used to support Dropwizard and Micrometer as separate metrics implementations in our platform.

It also serves an important job (which isn't fully illustrated in the repro): it creates a CompositeRegistry, to which the Micrometer global registry gets added (see MicrometerRegistryFactory#getOrCreateMeterRegistry). This is likely to be part of the problem. The reason for this is that we need this approach for to reasons:

• For custom JMX naming (not seen in the repro, but it exists in the real production code)
• To be able to make the PrometheusPublisher class access these metrics, so they can be properly exposed via HTTP.

Workaround Right now, we have @AfterEach hooks in place which clears all metric registries which have been used by a test. This is necessary to avoid metrics "leaking out" from one test to another. However, if I remove this cleanup code the tests works consistently. :thinking:

commit e166926857579442b59b97cb7131c214c260aa11
Author: Per Lundberg <[email protected]>
Date:   Mon Dec 19 11:39:50 2022 +0200

    WIP: Remove removeAllMetrics call

diff --git lib/src/test/java/micrometer/registration/unregistration/issue/MetricRegistryWrapperTest.java lib/src/test/java/micrometer/registration/unregistration/issue/MetricRegistryWrapperTest.java
index a86b849..8e00db1 100644
--- lib/src/test/java/micrometer/registration/unregistration/issue/MetricRegistryWrapperTest.java
+++ lib/src/test/java/micrometer/registration/unregistration/issue/MetricRegistryWrapperTest.java
@@ -1,7 +1,5 @@
 package micrometer.registration.unregistration.issue;
 
-import static micrometer.registration.unregistration.issue.MicrometerRegistrationTest.removeAllMetrics;
-
 import org.junit.jupiter.api.AfterEach;
 import org.junit.jupiter.api.BeforeEach;
 import org.junit.jupiter.api.RepeatedTest;
@@ -23,9 +21,6 @@ public class MetricRegistryWrapperTest {
     @AfterEach
     public void tearDown() {
         registryFactory.close();
-
-        // This is required to avoid leaking state to other tests.
-        removeAllMetrics( registryFactory );
     }
 
     @RepeatedTest( 250 )
diff --git lib/src/test/java/micrometer/registration/unregistration/issue/MicrometerRegistrationTest.java lib/src/test/java/micrometer/registration/unregistration/issue/MicrometerRegistrationTest.java
index 15805f7..8ebee6b 100644
--- lib/src/test/java/micrometer/registration/unregistration/issue/MicrometerRegistrationTest.java
+++ lib/src/test/java/micrometer/registration/unregistration/issue/MicrometerRegistrationTest.java
@@ -7,7 +7,6 @@ import static org.assertj.core.api.Fail.fail;
 import java.io.IOException;
 import java.net.SocketException;
 import java.net.URL;
-import java.util.Collection;
 import java.util.List;
 import java.util.Map;
 
@@ -42,9 +41,6 @@ class MicrometerRegistrationTest {
     @AfterEach
     void tearDown() {
         registryFactory.close();
-
-        // This is required to avoid leaking state to other tests.
-        removeAllMetrics( registryFactory );
     }
 
     @RepeatedTest( 150 )
@@ -87,16 +83,6 @@ class MicrometerRegistrationTest {
         return Pair.of( registryFactory, prometheusHost + ":" + registryFactory.getPrometheusPort() );
     }
 
-    public static void removeAllMetrics( MicrometerRegistryFactory factory ) {
-        Collection<MeterRegistry> meterRegistries = factory.getMeterRegistries();
-
-        for ( MeterRegistry meterRegistry : meterRegistries ) {
-            meterRegistry.clear();
-        }
-
-        meterRegistries.clear();
-    }
-
     public static List<String> getPrometheusMetrics( String prometheusHost, String metricName ) throws IOException {
         List<String> responseLines = getAllPrometheusMetrics( prometheusHost );
 

Describe the bug The micrometer client does not reconnect to the statsd server (Datadog agent) when the agent is restarted.

Environment

• Micrometer version - 1.9.5
• Micrometer registry - statsd, Datadog flavor
• OS: Linux
• Java version: 11.0.14

To Reproduce How to reproduce the bug: Restart the statsd server (datadog-agent)

Expected behavior A clear and concise description of what you expected to happen.

The micrometer client re-establishes a connection to the statsd server on port 8125 when the daemon is back up.

Additional context Add any other context about the problem here, e.g. related issues.

• generate a metric for total Threads started since the JVM start time. This is extremely useful to understand how an application is doing on thread creation and also understand the creation patterns. The existing metrics give the current status of threads but nothing about whether the threads are created newly or are existing ones. This metric will aid in such scenarios by taking deltas.

Describe the bug Currently, the JVM class unloading metric is being registered as a Function counter. The description says "The total number of classes unloaded since the Java virtual machine has started execution" which will not be true when this metric is used in a Step Meter Registry.

Environment

• Micrometer version - Any version
• Micrometer registry - Any Step Registry can be used
• OS: Any
• Java version: Any

To Reproduce How to reproduce the bug: Start the java application with the micrometer JVM binder enabled. Use any step registry to register these metrics. After one step is completed, the unloaded class becomes zero.

Expected behavior jvm.classes.unloaded - should represent the total number of classes unloaded since the Java virtual machine has started execution

Describe the bug Dynatrace exporter prints a lot of WARNs with Could not serialize meter kafka.xxx: Value was NaN meters.

Environment

I added micrometer-registry-dynatrace to my Spring Boot application to have the additional metrics exported to Dynatrace.

The pod is instrumented by the OneAgent and the exporter is able to detect that:

13:03:03.317  INFO 1 --- [           main] i.m.dynatrace.DynatraceMeterRegistry     : Exporting to Dynatrace metrics API v2
13:03:03.321  INFO 1 --- [           main] i.m.dynatrace.v2.DynatraceExporterV2     : Exporting to endpoint https://xxx.yyy/zzz/www/api/v2/metrics/ingest
13:03:03.385  INFO 1 --- [           main] i.m.c.instrument.push.PushMeterRegistry  : publishing metrics for DynatraceMeterRegistry every 1m

However, later on, after the Kafka consumer initialization, I see:

13:04:00.034  WARN 1 --- [trics-publisher] i.m.dynatrace.v2.DynatraceExporterV2     : Could not serialize meter kafka.consumer.coordinator.partition.lost.latency.max: Value was NaN.
13:04:00.036  WARN 1 --- [trics-publisher] i.m.dynatrace.v2.DynatraceExporterV2     : Could not serialize meter kafka.consumer.coordinator.partition.lost.latency.avg: Value was NaN.
13:04:00.049  WARN 1 --- [trics-publisher] i.m.dynatrace.v2.DynatraceExporterV2     : Could not serialize meter kafka.consumer.reauthentication.latency.avg: Value was NaN.
13:04:00.049  WARN 1 --- [trics-publisher] i.m.dynatrace.v2.DynatraceExporterV2     : Could not serialize meter kafka.consumer.reauthentication.latency.max: Value was NaN.
13:04:00.078  WARN 1 --- [trics-publisher] i.m.dynatrace.v2.DynatraceExporterV2     : Could not serialize meter kafka.consumer.coordinator.partition.lost.latency.max: Value was NaN.
13:04:00.081  WARN 1 --- [trics-publisher] i.m.dynatrace.v2.DynatraceExporterV2     : Could not serialize meter kafka.consumer.coordinator.partition.lost.latency.avg: Value was NaN.
13:04:00.099  WARN 1 --- [trics-publisher] i.m.dynatrace.v2.DynatraceExporterV2     : Could not serialize meter kafka.consumer.coordinator.commit.latency.avg: Value was NaN.
13:04:00.101  WARN 1 --- [trics-publisher] i.m.dynatrace.v2.DynatraceExporterV2     : Could not serialize meter kafka.consumer.reauthentication.latency.max: Value was NaN.
13:04:00.105  WARN 1 --- [trics-publisher] i.m.dynatrace.v2.DynatraceExporterV2     : Could not serialize meter kafka.consumer.coordinator.commit.latency.max: Value was NaN.
13:04:00.106  WARN 1 --- [trics-publisher] i.m.dynatrace.v2.DynatraceExporterV2     : Could not serialize meter kafka.consumer.reauthentication.latency.max: Value was NaN.

After a while I see a lot of that kind of message repeated (all Kafka-related).

I use Spring Boot 2.7.3 with Micrometer 1.10.2 running JDK 17 on Kubernetes. The pod is instrumented by the OneAgent (and it seems to work fine in general as the generic metrics from JVM are gathered). The problem is similar to https://github.com/micrometer-metrics/micrometer/issues/1343, but it was fixed years ago. Do you have an idea why it is problematic with those Kafka meters?

To Reproduce See above description.

Expected behavior The metrics are exported to Dynatrace without any errors

Additional context Related issue: https://github.com/micrometer-metrics/micrometer/issues/1343