profile
viewpoint

micrometer-metrics/micrometer 2354

An application metrics facade for the most popular monitoring tools. Think SLF4J, but for metrics.

openzipkin-attic/zipkin-sparkstreaming 72

A streaming alternative to Zipkin's collector

shakuzen/aggregate-child-update-sample 0

Spring Data REST issue repro project

shakuzen/ansible-modules-core 0

Ansible modules - these modules ship with ansible

shakuzen/app-autoscaler 0

Auto Scaling for CF Applications

shakuzen/b3-propagation 0

Repository that describes and sometimes implements B3 propagation

shakuzen/bitbucket-branch-source-plugin 0

Bitbucket Branch Source Plugin

shakuzen/bobobot 0

bobobot

pull request commentspring-projects/spring-boot

Map NewRelicProperties Connect and Read Timeouts To NewRelicConfig

@snicoll Looks good to me. Thanks.

neiljpowell

comment created time in a day

push eventmicrometer-metrics/micrometer-docs

Tommy Ludwig

commit sha 510fb4b02db6605bb16ce5663a8572eb1d1cb6cd

Update Slack invite link Slack now has the feature to generate invite links. This means we no longer need to run a Slack invite app. This generated link is non-expiring.

view details

push time in a day

issue commentmicrometer-metrics/micrometer

Remove v1 CloudWatch module

Looking at the list of unimplemented features for parity in the v2 AWS SDK, I'm starting to think deprecating our v1 version may have been premature. It might even make sense to remove deprecation until AWS gives some indication they're moving away from supporting v1 of the SDK.

Maybe a good lesson for the future, we should keep V2 registry implementations in the same module and use Gradle feature variants or something instead.

If we could cleanly do that without complicating configuration or breaking compatibility, it would be nice. That's a big IF a lot of times, though.

I looked through the documentation on Gradle feature variants, but I don't understand how it would improve the situation. I suppose we'd copy the source files from the v2 module into the original module in a different source set, which seems hardly different from a maintenance/organization perspective. For consumers, if we're publishing Gradle metadata (we don't currently) and they're using Gradle (a version that supports the metadata), they'd have to consume the cloudwatch module in a different way (requireCapability) than up until now. I worry about the support burden this will generate. For Maven users, consuming feature variants seems to use artifact classifier, which is also not very different than just using a different artifact ID.

Would we leave the coordinates micrometer-registry-cloudwatch2 or dual publish the V2 module to micrometer-registry-cloudwatch?

I think leaving the coordinates cloudwatch2 will be least surprising for users. Maybe in Micrometer 2.0 we could reclaim the original artifact name with the v2 implementation, but it depends on the state of the AWS SDK, which seems like its v1 will be around and in use for quite a while.

shakuzen

comment created time in 2 days

issue closedmicrometer-metrics/micrometer

Metrics' eviction

Probably I overlooked it while reading the documentation, even so, I have to ask. I would like to know if micrometer supports something like cache eviction functionality (I am aware about cache metrics support, but it is not that I want). I mean support for the following workflow:

  1. new metric added to the registry
  2. it is updated after a while
  3. if the metric does not updated after specified amount of time the metric will be removed from the registry

Does micrometer support that?

closed time in 2 days

Sic4Parvis9Magna

issue commentmicrometer-metrics/micrometer

Metrics' eviction

Duplicate of #1114

Sic4Parvis9Magna

comment created time in 2 days

issue commentopenzipkin/zipkin

RabbitMQ integration test fails on Travis

Sorry for the lack of reply. We'd have to see if the latest versions of things (testcontainers, rabbitmq, travis) have magically fixed the problem or if more investigation is needed. It's not high priority though since we can use the travis service in the meantime.

adriancole

comment created time in 2 days

pull request commentmicrometer-metrics/micrometer

Prevent StringIndexOutOfBoundsException in Datadog statsD on empty tag value

Thanks for reporting this and providing a pull request. I don't think Datadog accepts empty/blank tag values like that. From https://docs.datadoghq.com/tagging/

Note: A tag cannot end with a colon, for example tag:

If I'm understanding the example here, a tag without a value (shell in the example) should be sent without a colon at all. I don't think we've ever supported this since Micrometer tags have values, even if they're blank. But it seems like the right thing to do here is interpret an empty tag value as being a valueless tag in dogstatsd.

We'll want to fix this in 1.1.x so we can fix it in upcoming patch versions. Would you be willing to update the pull request to interpret empty tag values as valueless tags in DogstatsdLineBuidler?

agarbayo

comment created time in 2 days

issue closedmicrometer-metrics/micrometer

java.lang.NoClassDefFoundError: org/LatencyUtils/IntervalEstimator in Springboot 2.3.0

See https://github.com/spring-projects/spring-boot/issues/21538

closed time in 2 days

yuanpli

issue commentmicrometer-metrics/micrometer

java.lang.NoClassDefFoundError: org/LatencyUtils/IntervalEstimator in Springboot 2.3.0

Have you seen the comment from @izeye https://github.com/spring-projects/spring-boot/issues/21538#issuecomment-632639800? This is most likely the issue. Please take a look.

yuanpli

comment created time in 2 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 2a0478a97d931ef52216be43697f1a87903e1474

Fix NPE in MongoMetricsConnectionPoolListener.registerGauge() (#2118) Closes gh-2117

view details

Tommy Ludwig

commit sha b2a679dd4fae23f097a6d58698c5427eaa2f0e92

Merge branch '1.3.x' into 1.5.x

view details

Tommy Ludwig

commit sha 07701bd311af40419964a54add6ae60b3cfdf29b

Merge branch '1.5.x'

view details

push time in 2 days

issue closedmicrometer-metrics/micrometer

NPE in `MongoMetricsConnectionPoolListener`

Today we observed the following on a shutdown thread:

java.lang.NullPointerException: null
    at io.micrometer.core.instrument.binder.mongodb.MongoMetricsConnectionPoolListener.lambda$registerGauge$0(MongoMetricsConnectionPoolListener.java:122)
    at io.micrometer.core.instrument.internal.DefaultGauge.value(DefaultGauge.java:54)
    ...

Looking at the code, what seems to have happened is the following:

  1. #connectionPoolOpened registers gauges for some server ID. This adds an entry to each of the four ConcurrentHashMaps and the gauges have a callback function which unconditionally assumes that the server ID is a key in these maps.
  2. At some point #connectionPoolClosed is called. This removes the server ID entry from each of the maps.
  3. At this point the gauges are still registered, and the next time they are read out an NPE results.

closed time in 2 days

Stephan202

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 2a0478a97d931ef52216be43697f1a87903e1474

Fix NPE in MongoMetricsConnectionPoolListener.registerGauge() (#2118) Closes gh-2117

view details

Tommy Ludwig

commit sha b2a679dd4fae23f097a6d58698c5427eaa2f0e92

Merge branch '1.3.x' into 1.5.x

view details

push time in 2 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 2a0478a97d931ef52216be43697f1a87903e1474

Fix NPE in MongoMetricsConnectionPoolListener.registerGauge() (#2118) Closes gh-2117

view details

push time in 2 days

PR merged micrometer-metrics/micrometer

Fix NPE in MongoMetricsConnectionPoolListener.registerGauge()

This PR fixes a posssible NPE in MongoMetricsConnectionPoolListener.registerGauge().

Closes gh-2117

+3 -2

0 comment

1 changed file

izeye

pr closed time in 2 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 5b686910ffd6330032188920482951c6ad5ef297

Polish timer builder changes (#2115)

view details

push time in 2 days

PR merged micrometer-metrics/micrometer

Polish timer builder changes polish

This PR polishes timer builder changes.

  • Is the name Timer.ResourceSample as bad as I feel it is?

While doing this, I was wondering if Timer.AutoCloseableSample or Timer.AutoCloseableBuilder might be easier to understand. I didn't do so as I wasn't sure.

+13 -5

1 comment

3 changed files

izeye

pr closed time in 2 days

delete branch openzipkin-contrib/brave-opentracing

delete branch : brave-5.12

delete time in 6 days

issue commentmicrometer-metrics/micrometer

Interpretation: What does http_server_requests_seconds_max measure

Since this issue was opened, a note has been added to the documentation under the Timer section. See the NOTE in section "10. Timers" https://micrometer.io/docs/concepts#_timers

Max for basic Timer implementations such as CumulativeTimer, StepTimer is a time window max (TimeWindowMax). It means that its value is the maximum value during a time window. If no new values are recorded for the time window length, the max will be reset to 0 as a new time window starts. Time window size will be the step size of the meter registry unless expiry in DistributionStatisticConfig is set to other value explicitly. The reason why a time window max is used is to capture max latency in a subsequent interval after heavy resource pressure triggers the latency and prevents metrics from being published.

@tarunrathor-pro and @tkgregory could you take a look at that and let us know if you think additional clarification is warranted. If so, what is lacking or confusing?

tarunrathor-pro

comment created time in 6 days

issue commentmicrometer-metrics/micrometer

Expose per-region statistics for Hibernate 2 cache

I'm not familiar with L2 cache regions. Are these static or dynamic? Will we know at binding time what all the regions are, or could they change?

kennymacleod

comment created time in 7 days

pull request commentspring-cloud/spring-cloud-gateway

Fix dashboard panels datasource

When importing the dashboard into Grafana, it will ask you to select a Prometheus type datasource from the currently configured datasources. It will replace the variable with the selected datasource name on import.

neetkee

comment created time in 7 days

push eventmicrometer-metrics/micrometer

Tommy Ludwig

commit sha 977b18a3c0b2064e06de549a1b5558360fcfe515

Polish CommonsObjectPool2Metrics

view details

push time in 7 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 6b1687e32882fc99f23c98d25374c2083ccfae90

Register NotificationListener unconditionally in CommonsObjectPool2Metrics (#2111) This commit also polishes it, and the changes are purely cosmetic or obvious.

view details

push time in 7 days

PR merged micrometer-metrics/micrometer

Register NotificationListener unconditionally in CommonsObjectPool2Metrics polish

This PR changes to register NotificationListener unconditionally in CommonsObjectPool2Metrics as it seems to intend to do so based on the Javadoc.

This PR also polishes it along the way.

+50 -30

0 comment

2 changed files

izeye

pr closed time in 7 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha a4c9d65b49ca47b9b3f5db61642f4020cbd5f53d

Make MicrometerCollector implement Collector.Describable (#2103) Closes gh-2087

view details

Tommy Ludwig

commit sha 22700b3696e5a8ce182e54d966e4bfd4efccf314

Merge branch '1.5.x' # Conflicts: # implementations/micrometer-registry-prometheus/src/test/java/io/micrometer/prometheus/PrometheusMeterRegistryTest.java

view details

push time in 7 days

issue closedmicrometer-metrics/micrometer

Deadlock due to ConcurrentHashMap.compute in PrometheusMeterRegistry

We just tried to upgrade a relatively large application to spring boot 2.3.0.RC1 which includes micrometer 1.5.0. The application relies on redis and we have included various metrics for lettuce (redis).

PrometheusMeterRegistry has been modified to use ConcurrentHashMap.compute() at https://github.com/micrometer-metrics/micrometer/blob/93375782923415f1c947f477557ec8b49354f8eb/implementations/micrometer-registry-prometheus/src/main/java/io/micrometer/prometheus/PrometheusMeterRegistry.java#L415.

I believe this causing a deadlock for us now in that getting the value of a particular gauge (spring boot health - https://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#howto-map-health-indicators-to-metrics) ends up (in different threads) trying to register other timers in the registry which deadlocks.

This doesn't seem like too uncommon of a use-case where getting the value of one meter might trigger initialization of another meter. It does seem a bit strange to me that registering a meter would trigger getting its value, but, I'm not sure if that changed.

"main@1" prio=5 tid=0x1 nid=NA waiting
  java.lang.Thread.State: WAITING
	 blocks lettuce-kqueueEventLoop-16-1@19158
	 blocks lettuce-kqueueEventLoop-17-1@19751
	  at jdk.internal.misc.Unsafe.park(Unsafe.java:-1)
	  at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
	  at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1798)
	  at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3128)
	  at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1868)
	  at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
	  at io.lettuce.core.protocol.AsyncCommand.await(AsyncCommand.java:83)
	  at io.lettuce.core.LettuceFutures.awaitOrCancel(LettuceFutures.java:118)
	  at io.lettuce.core.FutureSyncInvocationHandler.handleInvocation(FutureSyncInvocationHandler.java:69)
	  at io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
	  at com.sun.proxy.$Proxy315.info(Unknown Source:-1)
	  at org.springframework.data.redis.connection.lettuce.LettuceServerCommands.info(LettuceServerCommands.java:213)
	  at org.springframework.data.redis.connection.DefaultedRedisConnection.info(DefaultedRedisConnection.java:1345)
	  at org.springframework.boot.actuate.redis.RedisHealthIndicator.doHealthCheck(RedisHealthIndicator.java:64)
	  at org.springframework.boot.actuate.health.AbstractHealthIndicator.health(AbstractHealthIndicator.java:82)
	  at org.springframework.boot.actuate.health.HealthIndicator.getHealth(HealthIndicator.java:37)
	  at org.springframework.boot.actuate.health.HealthEndpoint.getHealth(HealthEndpoint.java:71)
	  at org.springframework.boot.actuate.health.HealthEndpoint.getHealth(HealthEndpoint.java:39)
	  at org.springframework.boot.actuate.health.HealthEndpointSupport.getContribution(HealthEndpointSupport.java:99)
	  at org.springframework.boot.actuate.health.HealthEndpointSupport.getAggregateHealth(HealthEndpointSupport.java:110)
	  at org.springframework.boot.actuate.health.HealthEndpointSupport.getContribution(HealthEndpointSupport.java:96)
	  at org.springframework.boot.actuate.health.HealthEndpointSupport.getAggregateHealth(HealthEndpointSupport.java:110)
	  at org.springframework.boot.actuate.health.HealthEndpointSupport.getContribution(HealthEndpointSupport.java:96)
	  at org.springframework.boot.actuate.health.HealthEndpointSupport.getHealth(HealthEndpointSupport.java:74)
	  at org.springframework.boot.actuate.health.HealthEndpointSupport.getHealth(HealthEndpointSupport.java:61)
	  at org.springframework.boot.actuate.health.HealthEndpoint.health(HealthEndpoint.java:65)
	  at org.springframework.boot.actuate.health.HealthEndpoint.health(HealthEndpoint.java:55)
	  at com.acme.app.metrics.HealthMetricsConfig.getStatusCode(HealthMetricsConfig.java:38)
	  at com.acme.app.metrics.HealthMetricsConfig$$Lambda$1576.1532832113.applyAsDouble(Unknown Source:-1)
	  at io.micrometer.core.instrument.StrongReferenceGaugeFunction.applyAsDouble(StrongReferenceGaugeFunction.java:47)
	  at io.micrometer.core.instrument.internal.DefaultGauge.value(DefaultGauge.java:54)
	  at io.micrometer.prometheus.PrometheusMeterRegistry.lambda$newGauge$5(PrometheusMeterRegistry.java:210)
	  at io.micrometer.prometheus.PrometheusMeterRegistry$$Lambda$1081.927793961.samples(Unknown Source:-1)
	  at io.micrometer.prometheus.MicrometerCollector.collect(MicrometerCollector.java:69)
	  at io.prometheus.client.CollectorRegistry.collectorNames(CollectorRegistry.java:100)
	  at io.prometheus.client.CollectorRegistry.register(CollectorRegistry.java:50)
	  at io.prometheus.client.Collector.register(Collector.java:139)
	  at io.micrometer.prometheus.PrometheusMeterRegistry.lambda$applyToCollector$17(PrometheusMeterRegistry.java:417)
	  at io.micrometer.prometheus.PrometheusMeterRegistry$$Lambda$1078.840907656.apply(Unknown Source:-1)
	  at java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1947)
	  - locked <0x50e3> (a java.util.concurrent.ConcurrentHashMap$Node)
	  at io.micrometer.prometheus.PrometheusMeterRegistry.applyToCollector(PrometheusMeterRegistry.java:413)
	  at io.micrometer.prometheus.PrometheusMeterRegistry.newGauge(PrometheusMeterRegistry.java:207)
	  at io.micrometer.core.instrument.MeterRegistry.lambda$gauge$1(MeterRegistry.java:295)
	  at io.micrometer.core.instrument.MeterRegistry$$Lambda$1062.593058251.apply(Unknown Source:-1)
	  at io.micrometer.core.instrument.MeterRegistry.lambda$registerMeterIfNecessary$5(MeterRegistry.java:559)
	  at io.micrometer.core.instrument.MeterRegistry$$Lambda$1064.592248212.apply(Unknown Source:-1)
	  at io.micrometer.core.instrument.MeterRegistry.getOrCreateMeter(MeterRegistry.java:612)
	  - locked <0x50e4> (a java.lang.Object)
	  at io.micrometer.core.instrument.MeterRegistry.registerMeterIfNecessary(MeterRegistry.java:566)
	  at io.micrometer.core.instrument.MeterRegistry.registerMeterIfNecessary(MeterRegistry.java:559)
	  at io.micrometer.core.instrument.MeterRegistry.gauge(MeterRegistry.java:295)
	  at io.micrometer.core.instrument.Gauge$Builder.register(Gauge.java:190)
	  at io.micrometer.core.instrument.composite.CompositeGauge.registerNewMeter(CompositeGauge.java:58)
	  at io.micrometer.core.instrument.composite.CompositeGauge.registerNewMeter(CompositeGauge.java:27)
	  at io.micrometer.core.instrument.composite.AbstractCompositeMeter.add(AbstractCompositeMeter.java:66)
	  at io.micrometer.core.instrument.composite.CompositeMeterRegistry$$Lambda$1067.482729490.accept(Unknown Source:-1)
	  at java.lang.Iterable.forEach(Iterable.java:75)
	  at java.util.Collections$SetFromMap.forEach(Collections.java:5581)
	  at io.micrometer.core.instrument.composite.CompositeMeterRegistry.lambda$new$0(CompositeMeterRegistry.java:65)
	  at io.micrometer.core.instrument.composite.CompositeMeterRegistry$$Lambda$1066.1535995916.run(Unknown Source:-1)
	  at io.micrometer.core.instrument.composite.CompositeMeterRegistry.lock(CompositeMeterRegistry.java:184)
	  at io.micrometer.core.instrument.composite.CompositeMeterRegistry.lambda$new$1(CompositeMeterRegistry.java:65)
	  at io.micrometer.core.instrument.composite.CompositeMeterRegistry$$Lambda$1031.891077813.accept(Unknown Source:-1)
	  at io.micrometer.core.instrument.MeterRegistry.getOrCreateMeter(MeterRegistry.java:622)
	  - locked <0x50e5> (a java.lang.Object)
	  at io.micrometer.core.instrument.MeterRegistry.registerMeterIfNecessary(MeterRegistry.java:566)
	  at io.micrometer.core.instrument.MeterRegistry.registerMeterIfNecessary(MeterRegistry.java:559)
	  at io.micrometer.core.instrument.MeterRegistry.gauge(MeterRegistry.java:295)
	  at io.micrometer.core.instrument.Gauge$Builder.register(Gauge.java:190)
	  at com.acme.app.metrics.HealthMetricsConfig.init(HealthMetricsConfig.java:34)
	  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
	  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	  at java.lang.reflect.Method.invoke(Method.java:566)
	  at org.springframework.context.event.ApplicationListenerMethodAdapter.doInvoke(ApplicationListenerMethodAdapter.java:305)
	  at org.springframework.context.event.ApplicationListenerMethodAdapter.processEvent(ApplicationListenerMethodAdapter.java:190)
	  at org.springframework.context.event.ApplicationListenerMethodAdapter.onApplicationEvent(ApplicationListenerMethodAdapter.java:153)
	  at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
	  at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
	  at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
	  at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:403)
	  at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:360)
	  at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:897)
	  at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.finishRefresh(ServletWebServerApplicationContext.java:164)
	  at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:553)
	  - locked <0x50e6> (a java.lang.Object)
	  at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:143)
	  at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:758)
	  at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:750)
	  at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:397)
	  at org.springframework.boot.SpringApplication.run(SpringApplication.java:315)
	  at com.acme.AcmeUserWeb.main(AcmeUserWeb.java:48)`

lettuce-kqueueEventLoop-16-1@19158" daemon prio=5 tid=0x200 nid=NA waiting for monitor entry
  java.lang.Thread.State: BLOCKED
	 waiting for main@1 to release lock on <0x50e5> (a java.lang.Object)
	  at io.micrometer.core.instrument.MeterRegistry.getOrCreateMeter(MeterRegistry.java:596)
	  at io.micrometer.core.instrument.MeterRegistry.registerMeterIfNecessary(MeterRegistry.java:566)
	  at io.micrometer.core.instrument.MeterRegistry.timer(MeterRegistry.java:306)
	  at io.micrometer.core.instrument.Timer$Builder.register(Timer.java:538)
	  at com.acme.redis.appmetrics.LettuceMetrics.lambda$recordCommandLatency$2(LettuceMetrics.java:61)
	  at com.acme.redis.appmetrics.LettuceMetrics$$Lambda$1433.570540964.apply(Unknown Source:-1)
	  at com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$14(BoundedLocalCache.java:2380)
	  at com.github.benmanes.caffeine.cache.BoundedLocalCache$$Lambda$1434.2007041160.apply(Unknown Source:-1)
	  at java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
	  - locked <0x50ec> (a java.util.concurrent.ConcurrentHashMap$ReservationNode)
	  at com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2378)
	  at com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2361)
	  at com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:108)
	  at com.github.benmanes.caffeine.cache.LocalManualCache.get(LocalManualCache.java:62)
	  at com.acme.redis.appmetrics.LettuceMetrics.recordCommandLatency(LettuceMetrics.java:57)
	  at io.lettuce.core.protocol.CommandHandler.recordLatency(CommandHandler.java:787)
	  at io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:670)
	  at io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:596)
	  at io.lettuce.core.protocol.CommandHandler.channelRead(CommandHandler.java:565)
	  at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	  at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	  at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	  at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1421)
	  at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	  at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	  at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930)
	  at io.netty.channel.kqueue.AbstractKQueueStreamChannel$KQueueStreamUnsafe.readReady(AbstractKQueueStreamChannel.java:544)
	  at io.netty.channel.kqueue.AbstractKQueueChannel$AbstractKQueueUnsafe.readReady(AbstractKQueueChannel.java:376)
	  at io.netty.channel.kqueue.KQueueEventLoop.processReady(KQueueEventLoop.java:211)
	  at io.netty.channel.kqueue.KQueueEventLoop.run(KQueueEventLoop.java:289)
	  at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918)
	  at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	  at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	  at java.lang.Thread.run(Thread.java:834)
public class LettuceMetrics implements CommandLatencyCollector {

    private String redisName;
    private MeterRegistry meterRegistry;

    /**
     * Keyed by protocol keyword name.
     */
    private Cache<String, Timer> firstResponseTimers = Caffeine.newBuilder().expireAfterAccess(1, TimeUnit.DAYS)
        .removalListener((String key, Timer timer, RemovalCause cause) -> {
            if (null != timer) {
                meterRegistry.remove(timer);
            }
        }).build();

    private Cache<String, Timer> completionResponseTimers = Caffeine.newBuilder().expireAfterAccess(1, TimeUnit.DAYS)
        .removalListener((String key, Timer timer, RemovalCause cause) -> {
            if (null != timer) {
                meterRegistry.remove(timer);
            }
        }).build();

    public LettuceMetrics(MeterRegistry meterRegistry, String redisName) {
        this.redisName = redisName;
        this.meterRegistry = meterRegistry;
    }

    public LettuceMetrics(MeterRegistry meterRegistry) {
        this.redisName = "unnamed";
        this.meterRegistry = meterRegistry;
    }

    @Override
    public void recordCommandLatency(SocketAddress local, SocketAddress remote, ProtocolKeyword protocolKeyword,
                                     long firstResponseLatency, long completionLatency) {

        if (null != meterRegistry) {
            firstResponseTimers.get(protocolKeyword.name(), (key) ->
                Timer.builder("lettuce.first.response.latency")
                    .description("Latency between command send and first response (first response received)")
                    .tags("command", key, "redisName", redisName)
                    .register(meterRegistry))
                .record(firstResponseLatency, TimeUnit.NANOSECONDS);

            completionResponseTimers.get(protocolKeyword.name(), (key) ->
                Timer.builder("lettuce.completion.latency")
                    .description("Latency between command send and command completion (complete response received)")
                    .tags("command", key, "redisName", redisName)
                    .register(meterRegistry))
                .record(completionLatency, TimeUnit.NANOSECONDS);
        }

    }

    @Override
    public void shutdown() {
        // noop
    }

    @Override
    public Map<CommandLatencyId, CommandMetrics> retrieveMetrics() {
        return Collections.emptyMap();
    }

    @Override
    public boolean isEnabled() {
        return true;
    }
}

closed time in 7 days

krm1312

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha a4c9d65b49ca47b9b3f5db61642f4020cbd5f53d

Make MicrometerCollector implement Collector.Describable (#2103) Closes gh-2087

view details

push time in 7 days

PR merged micrometer-metrics/micrometer

Make MicrometerCollector implement Collector.Describable

This PR changes to make MicrometerCollector implement Collector.Describable.

Closes gh-2087

+156 -8

1 comment

2 changed files

izeye

pr closed time in 7 days

issue closedmicrometer-metrics/micrometer

Broken graphite metrics names with tags

Graphite tags always generate broken names due to DropWizard behavior.

From DropWizard, GraphiteReporter [1]: graphite.send(prefix(name, type.getCode()), format(value), timestamp); where name="my.metric;tag=value" type.getCode() = "p99"

final string sent to graphite: "my.metric;tag=valuep99"

From graphite logs 08/05/2020 08:21:00 :: [tagdb] Tagging component.api.setStatus;host=mail.example.com.mean, component.api.sendTextMessage;host=mail.example.com.p95, component.api.join_meeting;host=mail.example.com.m1_rate, component.api.getConversations;host=mail.example.com.mean

Unless we patch DropWizard side i can't see how this code may work

[1] https://github.com/dropwizard/metrics/blob/v4.1.7/metrics-graphite/src/main/java/com/codahale/metrics/graphite/GraphiteReporter.java#L351

closed time in 8 days

workless

issue commentmicrometer-metrics/micrometer

Broken graphite metrics names with tags

With the method added to the metrics-graphite library in 4.1.8, a workaround is now available for uses wishing to use the Graphite tag support. Namely, they should upgrade metrics-graphite to 4.1.8 or later and provide a GraphiteReporter with the new option set, such as will be done in the default GraphiteReporter in Micrometer 1.6.0:

GraphiteReporter.forRegistry(metricRegistry)
    .withClock(new DropwizardClock(clock))
    .convertRatesTo(config.rateUnits())
    .convertDurationsTo(config.durationUnits())
    .addMetricAttributesAsTags(config.graphiteTagsEnabled()) // this fixes #2069
    .build(getGraphiteSender(config));

I will note the above in the release notes for 1.5.2. As for migrating the implementation to not depend on Dropwizard, please feel free to open a separate issue to track that @workless.

workless

comment created time in 8 days

push eventmicrometer-metrics/micrometer

Andrew Fitzgerald

commit sha bbcca7cb0244b1940c4465f5b1e53bbc1c0b7b88

Prevent Graphite reporter from modifying user tags (#2083) Make sure that Graphite reporter uses tag format when appropriate. This requires the Dropwizard `metrics-graphite` dependency to be version 4.1.8 or later, as that is when the method this uses was added.

view details

push time in 8 days

PR merged micrometer-metrics/micrometer

Prevent Graphite reporter from modifying user tags registry: graphite

Context

As noted in #2069, the recently added Graphite tag support doesn't work for most metric types due to the way that the Dropwizard reporter appends metric attributes (min, max, p95, etc).

A metric that is reported this way using the traditional format: my.timer.host.foo.max Is currently reported like this using the tag format: my.timer;host=foo.max

https://github.com/dropwizard/metrics/pull/1576 was recently merged on the reporter side, adding a new flag to the reporter which would cause it to report the example used above as my.timer;host=foo;metricattribute=max.

What this PR does now

This PR adds a failing test to the end to end GraphiteMeterRegistryTest showing what the modified graphite output will eventually be.

It may also serve as a discussion starter around if the upstream changes to the Dropwizard metrics library are appropriate, or if more changes are required/desirable (is a metricattribute tag? Does it need to be more configurable?).

What this PR should do before merging

Pull in a Dropwizard metrics release containing https://github.com/dropwizard/metrics/pull/1576 and ensure that the Graphite reporter is configured to use the tag format when appropriate.

+71 -0

3 comments

2 changed files

fitzoh

pr closed time in 8 days

pull request commentmicrometer-metrics/micrometer

Prevent Graphite reporter from modifying user tags

On further consideration, due to the hard requirement on a recent patch version, it would likely cause more support issues to merge this into 1.5.x. I will make a release note that lets users know how they can work around the issue by providing their own reporter with this property set rather than deferring to the default one we create.

fitzoh

comment created time in 8 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 9d568a2aa0f51979ecf2c5c6cecfea4a1fe66a47

Relax assertion for tomcat.threads.busy in TomcatMetricsTest (#2106)

view details

Tommy Ludwig

commit sha 9595f72a7862a90ee2fd86234dabe0b27c7cfa69

Polish port handling TomcatMetricsTest

view details

Tommy Ludwig

commit sha f1d09b4183271937b14d94454cf0b38695750c5d

Fix imports

view details

Tommy Ludwig

commit sha 1675086e78241be18f60a04c74ea4c2b6fe95b0a

Merge branch '1.1.x' into 1.3.x

view details

Tommy Ludwig

commit sha 842eb112edbc0aa00970bed228034a27198a17d4

Merge branch '1.3.x' into 1.5.x

view details

Tommy Ludwig

commit sha 10a53e31e6f53cd5394160c80f1aaf04117c9dd0

Merge branch '1.5.x'

view details

push time in 9 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 9d568a2aa0f51979ecf2c5c6cecfea4a1fe66a47

Relax assertion for tomcat.threads.busy in TomcatMetricsTest (#2106)

view details

Tommy Ludwig

commit sha 9595f72a7862a90ee2fd86234dabe0b27c7cfa69

Polish port handling TomcatMetricsTest

view details

Tommy Ludwig

commit sha f1d09b4183271937b14d94454cf0b38695750c5d

Fix imports

view details

Tommy Ludwig

commit sha 1675086e78241be18f60a04c74ea4c2b6fe95b0a

Merge branch '1.1.x' into 1.3.x

view details

Tommy Ludwig

commit sha 842eb112edbc0aa00970bed228034a27198a17d4

Merge branch '1.3.x' into 1.5.x

view details

push time in 9 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 9d568a2aa0f51979ecf2c5c6cecfea4a1fe66a47

Relax assertion for tomcat.threads.busy in TomcatMetricsTest (#2106)

view details

Tommy Ludwig

commit sha 9595f72a7862a90ee2fd86234dabe0b27c7cfa69

Polish port handling TomcatMetricsTest

view details

Tommy Ludwig

commit sha f1d09b4183271937b14d94454cf0b38695750c5d

Fix imports

view details

Tommy Ludwig

commit sha 1675086e78241be18f60a04c74ea4c2b6fe95b0a

Merge branch '1.1.x' into 1.3.x

view details

push time in 9 days

push eventmicrometer-metrics/micrometer

Tommy Ludwig

commit sha f1d09b4183271937b14d94454cf0b38695750c5d

Fix imports

view details

push time in 9 days

push eventmicrometer-metrics/micrometer

Tommy Ludwig

commit sha 9595f72a7862a90ee2fd86234dabe0b27c7cfa69

Polish port handling TomcatMetricsTest

view details

push time in 9 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 9d568a2aa0f51979ecf2c5c6cecfea4a1fe66a47

Relax assertion for tomcat.threads.busy in TomcatMetricsTest (#2106)

view details

push time in 9 days

PR merged micrometer-metrics/micrometer

Relax assertion for tomcat.threads.busy in TomcatMetricsTest type: task

This PR relaxes assertion for tomcat.threads.busy in TomcatMetricsTest as its value seems to be possible to be greater than 0 somehow as follows:

TomcatMetricsTest > mbeansAvailableAfterBinder() FAILED
    org.opentest4j.AssertionFailedError: 
    Expecting:
     <1.0>
    to be equal to:
     <0.0>
    but was not.
        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 io.micrometer.core.instrument.binder.tomcat.TomcatMetricsTest.checkMbeansInitialState(TomcatMetricsTest.java:240)
        at io.micrometer.core.instrument.binder.tomcat.TomcatMetricsTest.lambda$mbeansAvailableAfterBinder$1(TomcatMetricsTest.java:157)
        at io.micrometer.core.instrument.binder.tomcat.TomcatMetricsTest.runTomcat(TomcatMetricsTest.java:223)
        at io.micrometer.core.instrument.binder.tomcat.TomcatMetricsTest.mbeansAvailableAfterBinder(TomcatMetricsTest.java:154)

See https://app.circleci.com/pipelines/github/micrometer-metrics/micrometer/557/workflows/597ccf5a-8d48-46fb-95de-d88e98cba5a6/jobs/6885/steps

+1 -1

0 comment

1 changed file

izeye

pr closed time in 9 days

Pull request review commentmicrometer-metrics/micrometer

Relax assertion for tomcat.threads.busy in TomcatMetricsTest

 private void checkMbeansInitialState() {         assertThat(registry.get("tomcat.global.request").functionTimer().totalTime(TimeUnit.MILLISECONDS)).isEqualTo(0.0);         assertThat(registry.get("tomcat.global.request.max").timeGauge().value(TimeUnit.MILLISECONDS)).isEqualTo(0.0);         assertThat(registry.get("tomcat.threads.config.max").gauge().value()).isGreaterThan(0.0);-        assertThat(registry.get("tomcat.threads.busy").gauge().value()).isEqualTo(0.0);+        assertThat(registry.get("tomcat.threads.busy").gauge().value()).isGreaterThanOrEqualTo(0.0);

This is a bit curious. I'm wondering why there would be a tomcat thread busy before any request has been sent. I guess maybe something asynchronously done as part of startup doesn't always finish before this check.

izeye

comment created time in 9 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 831ee8ba868549e0569e1ae2c0a194d6deb5f251

Fix Javadoc errors (#2098)

view details

Johnny Lim

commit sha 7bf1bf17dc882416a7a52f44d9c41e9b04391b4a

Retry failing assertion in TomcatMetricsTest (#2099)

view details

Tommy Ludwig

commit sha 53fa619712f26790e73da35a214d545d83d9a9ec

Merge branch '1.1.x' into 1.3.x

view details

Tommy Ludwig

commit sha 1b87515080ffefc4b42c9f062d59ced637c722c3

Add hamcrest to lockfiles due to transitive dependency from awaitility

view details

Tommy Ludwig

commit sha 2981d87ce9398be0d63d2e152dc357ad430d34ff

Merge branch '1.3.x' into 1.5.x # Conflicts: # micrometer-core/build.gradle # micrometer-core/gradle/dependency-locks/testCompile.lockfile # micrometer-core/gradle/dependency-locks/testCompileClasspath.lockfile # micrometer-core/gradle/dependency-locks/testRuntime.lockfile # micrometer-core/gradle/dependency-locks/testRuntimeClasspath.lockfile

view details

Tommy Ludwig

commit sha c23d07345f97d7ba67835984f3ff795f46c3e724

Merge branch '1.5.x' # Conflicts: # micrometer-core/gradle/dependency-locks/testCompileClasspath.lockfile # micrometer-core/gradle/dependency-locks/testRuntimeClasspath.lockfile

view details

push time in 9 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 7bf1bf17dc882416a7a52f44d9c41e9b04391b4a

Retry failing assertion in TomcatMetricsTest (#2099)

view details

Tommy Ludwig

commit sha 53fa619712f26790e73da35a214d545d83d9a9ec

Merge branch '1.1.x' into 1.3.x

view details

Tommy Ludwig

commit sha 1b87515080ffefc4b42c9f062d59ced637c722c3

Add hamcrest to lockfiles due to transitive dependency from awaitility

view details

Tommy Ludwig

commit sha 2981d87ce9398be0d63d2e152dc357ad430d34ff

Merge branch '1.3.x' into 1.5.x # Conflicts: # micrometer-core/build.gradle # micrometer-core/gradle/dependency-locks/testCompile.lockfile # micrometer-core/gradle/dependency-locks/testCompileClasspath.lockfile # micrometer-core/gradle/dependency-locks/testRuntime.lockfile # micrometer-core/gradle/dependency-locks/testRuntimeClasspath.lockfile

view details

push time in 9 days

push eventmicrometer-metrics/micrometer

Tommy Ludwig

commit sha 1b87515080ffefc4b42c9f062d59ced637c722c3

Add hamcrest to lockfiles due to transitive dependency from awaitility

view details

push time in 9 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 7bf1bf17dc882416a7a52f44d9c41e9b04391b4a

Retry failing assertion in TomcatMetricsTest (#2099)

view details

Tommy Ludwig

commit sha 53fa619712f26790e73da35a214d545d83d9a9ec

Merge branch '1.1.x' into 1.3.x

view details

push time in 9 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 7bf1bf17dc882416a7a52f44d9c41e9b04391b4a

Retry failing assertion in TomcatMetricsTest (#2099)

view details

push time in 9 days

PR merged micrometer-metrics/micrometer

Retry failing assertion in TomcatMetricsTest type: task

This PR changes to retry a failing assertion in TomcatMetricsTest as it fails intermittently. I didn't look into it, but It seems to be possible to be out of sync. It rarely happens, but retrying seems to work.

See https://app.circleci.com/pipelines/github/izeye/micrometer/502/workflows/3b1a35c7-8705-4b05-a14e-53654d39f2a2/jobs/850/steps

+12 -1

0 comment

6 changed files

izeye

pr closed time in 9 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha da79fc9c4d9beb16a34b63b345a0f58ee2290074

Polish build scripts for Spring Boot samples (#2107)

view details

push time in 9 days

PR merged micrometer-metrics/micrometer

Polish build scripts for Spring Boot samples build polish

This PR upgrades to Spring Boot 2.3.0.RELEASE for samples.

This PR also polishes build scripts for Spring Boot samples.

+7 -28

4 comments

3 changed files

izeye

pr closed time in 9 days

pull request commentmicrometer-metrics/micrometer

Polish build scripts for Spring Boot samples

So there's an issue with building the samples against Spring Boot 2.3 still (at least on CI)? If so, let's create an issue so we can track that. I'll get this merged in the meantime.

izeye

comment created time in 9 days

Pull request review commentmicrometer-metrics/micrometer

Make MicrometerCollector implement Collector.Describable

 public boolean isEmpty() {                 .collect(toList());     } +    @Override+    public List<MetricFamilySamples> describe() {+        switch (id.getType()) {+            case COUNTER:+                return Collections.singletonList(+                        new MetricFamilySamples(conventionName, Type.COUNTER, help, Collections.emptyList()));++            case GAUGE:+                return Collections.singletonList(+                        new MetricFamilySamples(conventionName, Type.GAUGE, help, Collections.emptyList()));++            case TIMER:+                return Collections.singletonList(+                        new MetricFamilySamples(conventionName, Type.HISTOGRAM, help, Collections.emptyList()));

We should increase test cases for filtering by time series name to ensure we're not missing any like this. For example, with a Timer named my.timer and attempting to filter by my_timer_duration_seconds_max (PrometheusMeterRegistryTest uses the PrometheusDurationNamingConvention by default) does not work as is right now.

izeye

comment created time in 9 days

Pull request review commentmicrometer-metrics/micrometer

Make MicrometerCollector implement Collector.Describable

 public boolean isEmpty() {                 .collect(toList());     } +    @Override+    public List<MetricFamilySamples> describe() {+        switch (id.getType()) {+            case COUNTER:+                return Collections.singletonList(+                        new MetricFamilySamples(conventionName, Type.COUNTER, help, Collections.emptyList()));++            case GAUGE:+                return Collections.singletonList(+                        new MetricFamilySamples(conventionName, Type.GAUGE, help, Collections.emptyList()));++            case TIMER:+                return Collections.singletonList(+                        new MetricFamilySamples(conventionName, Type.HISTOGRAM, help, Collections.emptyList()));

Also need the max GAUGE like the distribution summary

izeye

comment created time in 9 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 831ee8ba868549e0569e1ae2c0a194d6deb5f251

Fix Javadoc errors (#2098)

view details

push time in 9 days

PR merged micrometer-metrics/micrometer

Fix Javadoc errors type: task

Since 1.4.1, Javadoc doesn't seem to have been published to the Maven Central properly due to Javadoc errors with Java 14 as follows:

> Task :micrometer-core:javadoc2s]
/Users/user/IdeaProjects/micrometer/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/db/MetricsDSLContext.java:133: error: reference to Record is ambiguous
    public <R extends Record> Table<R> map(Table<R> table) {
                      ^
  both interface org.jooq.Record in org.jooq and class java.lang.Record in java.lang match
/Users/user/IdeaProjects/micrometer/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/db/MetricsDSLContext.java:379: error: reference to Record is ambiguous
    public <R extends Record> LoaderOptionsStep<R> loadInto(Table<R> table) {
...
  both interface org.jooq.Record in org.jooq and class java.lang.Record in java.lang match
100 errors

This PR fixes the errors in addition to the following error:

> Task :micrometer-core:javadoc
/Users/user/IdeaProjects/micrometer/micrometer-core/src/main/java/io/micrometer/core/instrument/util/StringEscapeUtils.java:23: error: heading used out of sequence: <H3>, compared to implicit preceding heading: <H1>
 * <h3>Implementation Approach</h3>
   ^
+2 -3

0 comment

2 changed files

izeye

pr closed time in 9 days

pull request commentmicrometer-metrics/micrometer

Add readTimeout and connectTimeout to NewRelicConfig from PushRegistryConfig

I want to confirm my understanding that nothing is broken right now - Spring Boot users can still configure the timeouts via configuration properties - it just means deprecated methods will be used under the hood. That's something we want to fix but the urgency on fixing it is lower and gives us time to make sure we're making the right change.

I think part of @jkschneider's point was that we don't necessarily need a corresponding Config method for there to be a Spring Boot property. Non-Boot Micrometer users are already instantiating various things themselves: the Config, the Registry - so instantiating an HttpSender how one wants is reasonable. Spring Boot, on the other hand, auto-configures such things typically, so having properties for it that aren't in Micrometer seems reasonable to me. It provides the HttpSender for other registries that take an HttpSender in the corresponding auto-configuration already.

The tricky part here (for the NewRelicMeterRegistry since 1.4) is that the HttpSender should only be provided in a certain combination of configuration. Spring Boot knowing about this specific combination seems like a code smell that could easily break. Perhaps there is a way to work around this without bringing back the timeout methods in a Config class. I'm not sure whether this is more confusing, but one thought I had that is we could remove the fail fast logic here: https://github.com/micrometer-metrics/micrometer/blob/3e1b71d62256f45fcf01f56ad5ab310586277358/implementations/micrometer-registry-new-relic/src/main/java/io/micrometer/newrelic/NewRelicMeterRegistry.java#L169-L172 Unless we're constructing a NewRelicInsightsApiClientProvider when building we ignore the HttpSender configured on the builder . We'd have to un-deprecate the Builder's httpClient method and update the JavaDoc to mention when the HttpSender is used or not. This would allow Spring Boot to simplify its logic and always provide a default HttpSender based on configuration properties, and whether that HttpSender is used or not is part of Micrometer's logic.

neiljpowell

comment created time in 14 days

issue openedCircleCI-Public/cimg-openjdk

EA images

OpenJDK has Early Access (EA) builds available at jdk.java.net (e.g. currently JDK 15: https://jdk.java.net/15/). Having a CircleCI image available for those EA builds would allow us to more easily run our build on the EA version and give feedback before the final release.

created time in 15 days

PR opened micrometer-metrics/micrometer-docs

Document CloudWatch registry

An initial attempt to document the CloudWatch registry. We can build on this by adding additional pertinent information in subsequent pull requests.

Fixes #49

+50 -1

0 comment

3 changed files

pr created time in 15 days

create barnchmicrometer-metrics/micrometer-docs

branch : cloudwatch

created branch time in 15 days

issue commentmicrometer-metrics/micrometer

Jetty metrics binding

Are you using the TimedHandler to time your Jetty server requests? It looks like we don't have an implementation currently to get the templated path. This is important to avoid tag explosion. If the path were /{id} for example and we tagged with the resolved path, this would result in unbounded cardinality explosion. If there is a way to get the path with the template, we could update the implementation. You can also provide your own HttpServletRequestTagsProvider instance.

asad-awadia

comment created time in 15 days

issue commentmicrometer-metrics/micrometer

Support Shenandoah GC in JvmGcMetrics

@asad-awadia Could you open a separate issue for that? I did not know OpenJ9 had its own garbage collector.

IRus

comment created time in 15 days

Pull request review commentspring-projects/spring-boot

WebMvc/WebFlux metrics uri tag for empty path should be 'root'

 void uriTagValueIsBestMatchingPatternWhenAvailable() { 		assertThat(tag.getValue()).isEqualTo("/spring/"); 	} +	@Test+	void uriTagValueIsRootWhenBestMatchingPatternIsEmpty() {+		this.request.setAttribute(HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE, "");+		this.response.setStatus(301);+		Tag tag = WebMvcTags.uri(this.request, this.response);+		assertThat(tag.getValue()).isEqualTo("ROOT");

Should be root instead of ROOT?

jkschneider

comment created time in 16 days

issue commentmicrometer-metrics/micrometer

Broken graphite metrics names with tags

@workless Thanks for the offer to allow supporting Graphite in Micrometer without Dropwizard passthrough. I'm in favor of the change going forward, but it might be a bit tricky compatibility-wise, since Dropwizard is part of the public API for our current Graphite registry. We would have to figure out how to deal with this so we don't break users while allowing an upgrade path.

workless

comment created time in 16 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 462627fe267008397ff677ec81671aefa0edddb1

Share cumulative histogram counts variant for LongTaskTimer (#2076)

view details

Johnny Lim

commit sha 40ec7d1f596afe22bf3ddf57dade110a938c4b3b

Polish TimeWindowMax (#1641)

view details

Tommy Ludwig

commit sha 7cd96e45f2c2304b0741afaab50bc5dacf5b79da

Merge branch '1.1.x' into 1.3.x

view details

Tommy Ludwig

commit sha f52de36ba4c491538ec8be739d482437ea8c8efc

Merge branch '1.3.x' into 1.5.x

view details

Tommy Ludwig

commit sha 93375782923415f1c947f477557ec8b49354f8eb

Merge branch '1.5.x'

view details

push time in 16 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 40ec7d1f596afe22bf3ddf57dade110a938c4b3b

Polish TimeWindowMax (#1641)

view details

Tommy Ludwig

commit sha 7cd96e45f2c2304b0741afaab50bc5dacf5b79da

Merge branch '1.1.x' into 1.3.x

view details

Tommy Ludwig

commit sha f52de36ba4c491538ec8be739d482437ea8c8efc

Merge branch '1.3.x' into 1.5.x

view details

push time in 16 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 40ec7d1f596afe22bf3ddf57dade110a938c4b3b

Polish TimeWindowMax (#1641)

view details

Tommy Ludwig

commit sha 7cd96e45f2c2304b0741afaab50bc5dacf5b79da

Merge branch '1.1.x' into 1.3.x

view details

push time in 16 days

issue commentreactor/reactor-core

Using custom tags for metrics with Prometheus forces the same tags on all publishers in the system

in light of recent issues around meter explosion (see reactor-netty)

Sorry if I've missed a notification. What's happened?

I wonder if the proposition of adding the flux .name() to the meters names makes sense

Again, this depends on expectations. Should metrics for different publishers be separate, or is there value in aggregating across all of them? Looking at, for example, the reactor.subscribed Counter, would a user ever want to sum this for all publishers to get a count subscribed for all publishers? Or would it only be used on a per-publisher basis?

alexandrelasouza

comment created time in 16 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 40ec7d1f596afe22bf3ddf57dade110a938c4b3b

Polish TimeWindowMax (#1641)

view details

push time in 16 days

PR merged micrometer-metrics/micrometer

Polish TimeWindowMax polish

This PR polishes TimeWindowMax.

+19 -17

4 comments

1 changed file

izeye

pr closed time in 16 days

pull request commentmicrometer-metrics/micrometer

Polish TimeWindowMax

It's hard to remember at this point what I was thinking (sorry I wasn't more specific), but I think my concern was about the addition of lambdas with variable capture on our "hot path" for recording metrics. I'm not sure there's any per-invocation cost associated with that like I must have been thinking. I wrote a JMH test locally to benchmark the changes and didn't notice a significant difference either.

izeye

comment created time in 16 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 9d8b1a80bc4abec29c473d3ead16c21842273cf5

Ensure clean-up in StatsdMeterRegistryTest (#2080)

view details

Tommy Ludwig

commit sha 4120b3512090f92f6049122984fecc34a69859de

Merge branch '1.5.x'

view details

push time in 17 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 9d8b1a80bc4abec29c473d3ead16c21842273cf5

Ensure clean-up in StatsdMeterRegistryTest (#2080)

view details

push time in 17 days

PR merged micrometer-metrics/micrometer

Ensure clean-up in StatsdMeterRegistryTest

This PR is a follow-up of https://github.com/micrometer-metrics/micrometer/pull/2079 for 1.5.x branch.

+1 -1

0 comment

1 changed file

izeye

pr closed time in 17 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 2f66f8f7ff6f8012d8b8650167613dc014e49967

Remove unused DelegatingDropwizardLongGauge (#2074)

view details

Tommy Ludwig

commit sha 5ff6acee598d99ff28d633a927f8219af7860d0c

Merge branch '1.1.x' into 1.3.x

view details

Johnny Lim

commit sha 4e5d0f0d4d9b89bab276e76a983f4aff66f1ea8a

Fix ClassCastException in OpenTSDBMeterRegistry.writeLongTaskTimer() (#2075) This commit also changes as follows: - Use snapshot for histogram counts in writeTimer() - Use Prometheus variant for LongTaskTimer implementation

view details

Tommy Ludwig

commit sha 03c551e919c49e65d79c56c8a2d2b3c9c30103cd

Merge branch '1.3.x' into 1.5.x

view details

Johnny Lim

commit sha 2bba7e530e70d0a8d0b0bf22689c50b813aa9788

Use strong reference for NewRelicMeterRegistryTest.publishWithApiClientProvider() (#2077)

view details

Johnny Lim

commit sha cba21899806743f4a5afe6c4979a8403a616b07e

Use consistent value for active tasks in LongTaskTimer.mean() (#2078)

view details

Johnny Lim

commit sha 7001208f12b4b23df9b6ede97aa0d3aa7ba76fa1

Ensure clean-up in StatsdMeterRegistryTest (#2079)

view details

Tommy Ludwig

commit sha 81d9c308f15e6bb955f633ed92f39a1401a9efd4

Merge branch '1.1.x' into 1.3.x

view details

Tommy Ludwig

commit sha 64d16dcdabb10e56f246333d78e5d8e978ead524

Merge branch '1.3.x' into 1.5.x

view details

Tommy Ludwig

commit sha 21f86963aa5bd0e6f4a311d0476305a9f57e87db

Merge branch '1.5.x'

view details

push time in 17 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 7001208f12b4b23df9b6ede97aa0d3aa7ba76fa1

Ensure clean-up in StatsdMeterRegistryTest (#2079)

view details

Tommy Ludwig

commit sha 81d9c308f15e6bb955f633ed92f39a1401a9efd4

Merge branch '1.1.x' into 1.3.x

view details

Tommy Ludwig

commit sha 64d16dcdabb10e56f246333d78e5d8e978ead524

Merge branch '1.3.x' into 1.5.x

view details

push time in 17 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 7001208f12b4b23df9b6ede97aa0d3aa7ba76fa1

Ensure clean-up in StatsdMeterRegistryTest (#2079)

view details

Tommy Ludwig

commit sha 81d9c308f15e6bb955f633ed92f39a1401a9efd4

Merge branch '1.1.x' into 1.3.x

view details

push time in 17 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 7001208f12b4b23df9b6ede97aa0d3aa7ba76fa1

Ensure clean-up in StatsdMeterRegistryTest (#2079)

view details

push time in 17 days

PR merged micrometer-metrics/micrometer

Ensure clean-up in StatsdMeterRegistryTest type: task

This PR changes to ensure clean-up in StatsdMeterRegistryTest.

+26 -16

0 comment

1 changed file

izeye

pr closed time in 17 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha cba21899806743f4a5afe6c4979a8403a616b07e

Use consistent value for active tasks in LongTaskTimer.mean() (#2078)

view details

push time in 17 days

PR merged micrometer-metrics/micrometer

Use consistent value for active tasks in LongTaskTimer.mean() bug

This PR changes to use consistent value for active tasks in LongTaskTimer.mean().

+3 -2

0 comment

2 changed files

izeye

pr closed time in 17 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 2bba7e530e70d0a8d0b0bf22689c50b813aa9788

Use strong reference for NewRelicMeterRegistryTest.publishWithApiClientProvider() (#2077)

view details

push time in 17 days

PR merged micrometer-metrics/micrometer

Use strong reference for NewRelicMeterRegistryTest.publishWithApiClientProvider() type: task

This PR changes to use strong references for gauges in NewRelicMeterRegistryTest.publishWithApiClientProvider() as it's flaky due to garbage collection as follows:

NewRelicMeterRegistryTest > publishWithApiClientProvider() FAILED
    java.lang.AssertionError: 
    Expecting:
     <"[]">
    to contain:
     <"[{"eventType":"MicrometerSample","value":2,"metricName":"otherGauge","metricType":"GAUGE"},{"eventType":"MicrometerSample","value":1,"metricName":"myGauge","metricType":"GAUGE","theTag":"theValue"}]"> 
        at io.micrometer.newrelic.NewRelicMeterRegistryTest.publishWithApiClientProvider(NewRelicMeterRegistryTest.java:694)

See https://circleci.com/gh/izeye/micrometer/826

+2 -2

0 comment

1 changed file

izeye

pr closed time in 17 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 2f66f8f7ff6f8012d8b8650167613dc014e49967

Remove unused DelegatingDropwizardLongGauge (#2074)

view details

Tommy Ludwig

commit sha 5ff6acee598d99ff28d633a927f8219af7860d0c

Merge branch '1.1.x' into 1.3.x

view details

Tommy Ludwig

commit sha 03c551e919c49e65d79c56c8a2d2b3c9c30103cd

Merge branch '1.3.x' into 1.5.x

view details

push time in 18 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 4e5d0f0d4d9b89bab276e76a983f4aff66f1ea8a

Fix ClassCastException in OpenTSDBMeterRegistry.writeLongTaskTimer() (#2075) This commit also changes as follows: - Use snapshot for histogram counts in writeTimer() - Use Prometheus variant for LongTaskTimer implementation

view details

push time in 18 days

PR merged micrometer-metrics/micrometer

Fix ClassCastException in OpenTSDBMeterRegistry.writeLongTaskTimer() bug registry: opentsdb

This PR fixes ClassCastException in OpenTSDBMeterRegistry.writeLongTaskTimer().

This PR also changes as follows:

  • Use snapshot for histogram counts in writeTimer()
  • Use Prometheus variant for LongTaskTimer implementation
+87 -6

0 comment

3 changed files

izeye

pr closed time in 18 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 2f66f8f7ff6f8012d8b8650167613dc014e49967

Remove unused DelegatingDropwizardLongGauge (#2074)

view details

Tommy Ludwig

commit sha 5ff6acee598d99ff28d633a927f8219af7860d0c

Merge branch '1.1.x' into 1.3.x

view details

push time in 18 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 2f66f8f7ff6f8012d8b8650167613dc014e49967

Remove unused DelegatingDropwizardLongGauge (#2074)

view details

push time in 18 days

PR merged micrometer-metrics/micrometer

Remove unused DelegatingDropwizardLongGauge type: task

This PR removes unused DelegatingDropwizardLongGauge.

+0 -37

0 comment

1 changed file

izeye

pr closed time in 18 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 5295608e009240eaaff1516a279729a52eb7e5bf

Ensure clean-up in StatsdMeterRegistryPublishTest (#2073)

view details

Tommy Ludwig

commit sha adb3434d7c354b72b0adb21637f0e4daced465ae

Merge branch '1.5.x'

view details

push time in 18 days

push eventmicrometer-metrics/micrometer

Johnny Lim

commit sha 5295608e009240eaaff1516a279729a52eb7e5bf

Ensure clean-up in StatsdMeterRegistryPublishTest (#2073)

view details

push time in 18 days

PR merged micrometer-metrics/micrometer

Ensure clean-up in StatsdMeterRegistryPublishTest polish

I noticed that server isn't cleaned up in whenRegistryStopped_doNotConnectToBackend().

This PR changes to ensure clean-up in StatsdMeterRegistryPublishTest.

+18 -17

0 comment

1 changed file

izeye

pr closed time in 18 days

created tagmicrometer-metrics/micrometer

tagv1.5.1

An application metrics facade for the most popular monitoring tools. Think SLF4J, but for metrics.

created time in 19 days

release micrometer-metrics/micrometer

v1.5.1

released time in 19 days

created tagmicrometer-metrics/micrometer

tagv1.3.9

An application metrics facade for the most popular monitoring tools. Think SLF4J, but for metrics.

created time in 19 days

release micrometer-metrics/micrometer

v1.3.9

released time in 19 days

created tagmicrometer-metrics/micrometer

tagv1.1.14

An application metrics facade for the most popular monitoring tools. Think SLF4J, but for metrics.

created time in 19 days

release micrometer-metrics/micrometer

v1.1.14

released time in 19 days

issue commentmicrometer-metrics/micrometer

Disable aggregations

App is quite simple and having 300+ metric points almost by default. I've been asked to figure out how to resign from at least part of them, and still looking for a way to blacklist unwanted metrics (like the avg)

You could also disable the Spring Boot auto-configuration and only register the meters you want.

kvaidas

comment created time in 19 days

issue commentmicrometer-metrics/micrometer

Failed to introspect Class [org.springframework.boot.actuate.autoconfigure.metrics.export.prometheus.PrometheusPropertiesConfigAdapter]

The issue is likely to be inconsistent versions. You need to ensure you're using consistent versions. For instance, the version of the actuator dependency you're declaring does not match your Spring Boot version. You'll also want to ensure the micrometer-core and registry dependency version are consistent.

kargakis

comment created time in 19 days

push eventmicrometer-metrics/micrometer

Ikhun Um

commit sha 25fdad8559d7a5a00c71d792ee0a86fec62a5885

Allow `ExecutorServiceMetrics` accepting metric name prefix (#1920) Motivation: ExecutorService metrics names are hard-coded. User defined ExecutorService want their own name space to avoid conflict with other executors such as Reactor Scheduler. Modifications: - Add `metricPrefix` paremeter to `ExecutorServiceMetrics` factory methods - Add `metricPrefix` parameter to `Timed*` class constructor Co-authored-by: Tommy Ludwig <8924140+shakuzen@users.noreply.github.com> (cherry picked from commit fc8cec7afe7c57795b1367ae5087571f0d7a4cf2) Fixes #2070

view details

Tommy Ludwig

commit sha f4ae692546feb07b691e76295d06827cb5ecb7e4

Polish ExecutorServiceMetricsTest (cherry picked from commit f126774d1257c069472818b2fc58017d38f5a8f2)

view details

Johnny Lim

commit sha 8379390e3c63bee0801658c2e3e04a678dc7eca2

Polish ExecutorServiceMetrics changes (#2053) (cherry picked from commit 14a5eaf95bbb80f7bf0926247687749c2f28a320)

view details

Tommy Ludwig

commit sha ca234a5a06192e698573e3eb7c057004f1d2b787

Remove unused import

view details

Tommy Ludwig

commit sha 5984c10fc12b781652e27a9ea95c439f96e73cf8

Merge branch '1.3.x' into 1.5.x

view details

Tommy Ludwig

commit sha 13dc4b21e9d1a7ef31d284cb9924c03e0ff88608

Merge branch '1.5.x'

view details

push time in 19 days

issue closedmicrometer-metrics/micrometer

Backport ExecutorServiceMetrics meter name customization

@shakuzen Mentioned it in https://github.com/line/armeria/pull/2689 too but would it be possible to merge this into 1.3 as well? Currently, we're in dependency hell not that different from the ABI break in the other issue.

  • Want to support users that use any supported LTS version of micrometer, currently 1.3 and 1.5
  • Want to be able to interop with Reactor

Seems like a reasonable desire for an infra library like micrometer to not lock us out of these :) But currently we have to pick Reactor + 1.5 (taking this fix) or 1.3 and no Reactor (or continue to use our forked ExecutorServiceMetrics)

Originally posted by @anuraaga in https://github.com/micrometer-metrics/micrometer/issues/1919#issuecomment-625699782

closed time in 19 days

shakuzen
more