vert-x3 / vertx-dropwizard-metrics Goto Github PK

View Code? Open in Web Editor NEW

32.0 25.0 39.0 1.45 MB

Vert.x Metrics

License: Apache License 2.0

Java 100.00%

dropwizard-metrics java vertx jmxtrans hawtio

vertx-dropwizard-metrics's People

Contributors

Stargazers

Watchers

vertx-dropwizard-metrics's Issues

Upgrade to io.dropwizard.metrics version 4.2

Intermittent failures in io.vertx.ext.dropwizard.MetricsTest.testHttpMetricsResponseCode

Starting test: MetricsTest#testHttpMetricsResponseCode 
java.lang.AssertionError: Was expecting responses-3xx to be not null
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.assertTrue(Assert.java:41)
    at org.junit.Assert.assertNotNull(Assert.java:712)
    at io.vertx.test.core.AsyncTestBase.assertNotNull(AsyncTestBase.java:390)
    at io.vertx.ext.dropwizard.MetricsTest.lambda$test$30(MetricsTest.java:310)
    at io.vertx.ext.dropwizard.MetricsTest$$Lambda$254/1687627235.handle(Unknown Source)
    at io.vertx.ext.dropwizard.MetricsTest.lambda$test$32(MetricsTest.java:327)
    at io.vertx.ext.dropwizard.MetricsTest$$Lambda$256/1276544608.handle(Unknown Source)
    at io.vertx.core.http.impl.HttpServerImpl.lambda$null$14(HttpServerImpl.java:296)
    at io.vertx.core.http.impl.HttpServerImpl$$Lambda$79/220813571.handle(Unknown Source)
    at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:359)
    at io.vertx.core.impl.ContextImpl$$Lambda$34/1422238463.run(Unknown Source)
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:339)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:374)
    at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
    at java.lang.Thread.run(Thread.java:745)
Unhandled exception 
java.lang.AssertionError: Was expecting responses-3xx to be not null
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.assertTrue(Assert.java:41)
    at org.junit.Assert.assertNotNull(Assert.java:712)
    at io.vertx.test.core.AsyncTestBase.assertNotNull(AsyncTestBase.java:390)
    at io.vertx.ext.dropwizard.MetricsTest.lambda$test$30(MetricsTest.java:310)
    at io.vertx.ext.dropwizard.MetricsTest$$Lambda$254/1687627235.handle(Unknown Source)
    at io.vertx.ext.dropwizard.MetricsTest.lambda$test$32(MetricsTest.java:327)
    at io.vertx.ext.dropwizard.MetricsTest$$Lambda$256/1276544608.handle(Unknown Source)
    at io.vertx.core.http.impl.HttpServerImpl.lambda$null$14(HttpServerImpl.java:296)
    at io.vertx.core.http.impl.HttpServerImpl$$Lambda$79/220813571.handle(Unknown Source)
    at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:359)
    at io.vertx.core.impl.ContextImpl$$Lambda$34/1422238463.run(Unknown Source)
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:339)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:374)
    at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
    at java.lang.Thread.run(Thread.java:745)

java.lang.AssertionError
    at org.junit.Assert.fail(Assert.java:86)
    at org.junit.Assert.assertTrue(Assert.java:41)
    at org.junit.Assert.assertTrue(Assert.java:52)
    at io.vertx.test.core.AsyncTestBase.assertTrue(AsyncTestBase.java:372)
    at io.vertx.test.core.AsyncTestBase.awaitLatch(AsyncTestBase.java:592)
    at io.vertx.ext.dropwizard.MetricsTest.test(MetricsTest.java:329)
    at io.vertx.ext.dropwizard.MetricsTest.testHttpMetricsResponseCode(MetricsTest.java:297)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
    at org.junit.rules.RunRules.evaluate(RunRules.java:20)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
    at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

Document how to use Jolokia and Hawtio

Http server request metrics incorrectly reported

See failing test suite.

If there is more than one server started at same host+port then each server metrics seems to see total number of requests across all server, not just the requests of that server

Metrics always null

Currently I get only null from MetricsService.create(vertx).getMetricsSnapshot(vertx);
A view hours ago there were no problems.

Redeploy is not enabled in DeploymentOptions.

Missing HTTP Server MBeans

Issue found in 3.3.3. Works fine with 3.2.1.

See https://groups.google.com/forum/?#!msg/vertx/BP3XVk10QTE/-yaXqQajBQAJ

Collect HTTP Server metrics from explicit endpoints

Hi all,
I tried to configure vertx-dropwizard-metrics with the following config:

{
  "enabled": true,
  "jmxEnabled": true,
  "monitoredServerUris": [
    {
      "value": "/hello"
    }
  ]
}

JMX Metrics up nice but it collect information from any endpoint. Is this the expected behavior? I just want to collect information from only one endpoint.

My vert.x version is 3.3.3, I use Jprofiler 9.2 to monitor MBean data.

Document and provide config for JMX4Perl

see http://search.cpan.org/~roland/jmx4perl/scripts/check_jmx4perl

this allow to integrate with Nagios using jolokia agent.

The HttpClientMetrics `pool-ratio` gauge is wrong

For a single client the computation reports the number of (connection) / (max pool size).

Max pool size is a value per remote server, therefore the computation is wrong and there should be a gauge per server instead.

Allow to report NetClientMetric and HttpClientMetric with a name

See eclipse-vertx/vert.x#1314

New EB metric to monitor if a consumer cannot cope with messages delivered

When a message is delivered locally, a handler task is scheduled for execution. If a consumer cannot keep-up with sent messages, the handler tasks will pile up in the executor queue.

Using the EB metrics SPI, it is possible to determine how many messages have been delivered but not yet handled.

Monitoring such a metrics, users could decided how to adapt to high traffic, e.g. spawning new nodes.

Creating multiple HttpClients throws IllegalArgumentException during metrics registration

When using vertx-dropwizard-metrics 3.2.0 and -Dvertx.metrics.options.enabled=true.
IllegalArgumentException: A metric named vertx.http.clients.connections.max-pool-size already exists

Line 91 in MetricsRegistry in referenced metrics-core 3.1.2

HttpClient tests failing

Failing since build 2273 triggered after merging eclipse-vertx/vert.x#2209

Methods not used?

Where are the methods implemented in https://github.com/vert-x3/vertx-dropwizard-metrics/blob/master/src/main/java/io/vertx/ext/dropwizard/impl/HttpServerMetricsImpl.java used/invoked?

AbstractMethodError trying to use instanziate TCPMetrics

Hi,
Currently I'm struggling with the following issue using vertx-dropwizard-metrics:
java.lang.AbstractMethodError: Method io/vertx/ext/dropwizard/impl/VertxMetricsImpl.createMetrics(Lio/vertx/core/net/NetServer;Lio/vertx/core/net/SocketAddress;Lio/vertx/core/net/NetServerOptions;)Lio/vertx/core/spi/metrics/TCPMetrics; is abstract
at io.vertx.ext.dropwizard.impl.VertxMetricsImpl.createMetrics(VertxMetricsImpl.java)

It seems like the class VertxMetricsImpl has not correctly implement the method. Investigating the related part in the IDE the createMetrics methods is abstract?

Best
Sven

NPE in NetServerMetricsImpl

Hi,

I have logged several NPEs during a time where there were network problems on our servers.

We are doing HTTP requests with the Vertx HttpClient. The exceptions led to handlers not being called anymore, neither exception handler nor other handlers. And this led to a effectively dead verticle.

To me it looks like remoteAddress was null, but I have no idea how that could have happened. I cannot reproduce it. If you have an idea please let me know.

Here is the stacktrace I have:

io.vertx.core.impl.ContextImpl 'Unhandled exception'
java.lang.NullPointerException
        at io.vertx.ext.dropwizard.impl.NetServerMetricsImpl.connected(NetServerMetricsImpl.java:60)
        at io.vertx.ext.dropwizard.impl.HttpClientMetricsImpl.connected(HttpClientMetricsImpl.java:68)
        at io.vertx.ext.dropwizard.impl.HttpClientMetricsImpl.connected(HttpClientMetricsImpl.java:33)
        at io.vertx.core.http.impl.ClientConnection.<init>(ClientConnection.java:92)
        at io.vertx.core.http.impl.HttpClientImpl.createConn(HttpClientImpl.java:815)
        at io.vertx.core.http.impl.HttpClientImpl.lambda$connected$74(HttpClientImpl.java:808)
        at io.vertx.core.impl.ContextImpl.lambda$wrapTask$18(ContextImpl.java:333)
        at io.vertx.core.impl.OrderedExecutorFactory$OrderedExecutor.lambda$new$265(OrderedExecutorFactory.java:91)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

Document `vertx.verticles.<verticle-name>` Counter

Use Timer type for vertx.net.servers bytes-read and bytes-written

Currently vertx.net.servers metrics returns Histogram type metrics for bytes-read and bytes-written it not usable to get rate throughput for net server

httpserver open-netsockets count error

I test with a websocket server using vertx 3.5.1 .
When new connection comes in, the count of "open-netsockets" and "open-connections.host" +2,end then after closed the count-1, but the value of "open-websockets" is right.

Consider removing the instance hashcode in the metric naming

For instance in HttpClient naming.

Filter out internal eventbus addresses

Once eclipse-vertx/vert.x#2516 is merged, internal eventbus addresses will be distinguished with pattern "__vertx.[net|ws|reply].randomUUID".

See vert-x3/vertx-micrometer-metrics#39

Document CLI system properties

Make reservoir configurable

Reservoir used in internal meters (e.g. ThroughputMeter) is hardcoded to the default ExponentiallyDecayingReservoir. Although it's possible to provide MetricRegistry implementation working with any other reservoir, internal meters still will be using default one.
I suggest a PR #82 allowing specifying reservoir factory. Added only java way to set the factory so far.

Appreciate your feedback.
Thanks

metrics maven dependency

Hi,
there is a problem with maven dependency for Metrics.

In docs stands:

<dependency>
  <groupId>io.vertx</groupId>
  <artifactId>vertx-metrics</artifactId>
  <version>${vertx.metrics.version}</version>
</dependency>

I assume that current version should be 3.0.0. But that is not true (latest available for me is 3.0.0-milestone3 version).

However I can find this:

<dependency>
  <groupId>io.vertx</groupId>
  <artifactId>vertx-dropwizard-metrics</artifactId>
  <version>3.0.0</version>
</dependency>

Which artifact is correct?

http client endpoint metric are not under basename vert.x

I was testing httpclient endpoint metric using version 3.3.2

            vertxOptions.setMetricsOptions(
                    new DropwizardMetricsOptions()
                            .setEnabled(true)
                            .addMonitoredHttpClientEndpoint(new Match().setValue(".*:.*").setType(MatchType.REGEX))
                            .setJmxEnabled(false)
            );

and somehow snapshot didn't give me endpoint metrics in following way

            JsonObject metrics = Deployer.metricsService.getMetricsSnapshot(vertx);

so I tried using following way and now it returns.

            JsonObject metrics = Deployer.metricsService.getMetricsSnapshot("http");

I was expecting them in "vertx.http.clients.endpoint.host:port" somehow they are NOT under basename vertx in registry.

Update some metrics to histogram

like http response time

open-websockets metric returns negative value

"vertx.http.servers.0.0.0.0:80.open-websockets": {
     "count": -3
 }

Version: 3.1.0-SNAPSHOT

Configure the list of monitored http client endpoints instead of adding/removing them at runtime

Update io.dropwizard.metrics:metrics-core to 4.0.2

Document how to configure the metrics from the command line

Just improve the section a bit with a full example.

MetricsService improvements

see https://github.com/vert-x3/vertx-dropwizard-metrics/issues

ThreadPoolMetrics implementation

Config from file not working

I am trying to use the vertx.metrics.options.configPath system property to configure the metrics collection from the commandline. While vertx loads the property correctly the MetricsOptions dont get set with the values like it is specified in the docs.
I am not sure if this is the intended behavior and the documentation is just unclear or this is actually a bug.

Intermittent failures io.vertx.ext.dropwizard.MetricsTest.testHttpMetricsOnClose

java.lang.IllegalStateException: Timed out
    at io.vertx.test.core.AsyncTestBase.waitUntil(AsyncTestBase.java:611)
    at io.vertx.test.core.AsyncTestBase.waitUntil(AsyncTestBase.java:596)
    at io.vertx.ext.dropwizard.MetricsTest.testHttpMetricsOnClose(MetricsTest.java:363)

Vert.x (and custom) MBeans are not showing with Docker

Hi there,

When running my Vert.x app on a Desktop I get to see my MBeans in visualvm.

I start my vert.x app as follow :

public class MyLauncher extends Launcher {

    private static final String JMX_DOMAIN    = "foobar";

    public static void main(String... args) {
        new UpstreamMockLauncher().dispatch(args);
    }

    @Override
    public void beforeStartingVertx(final VertxOptions options) {
        options.setMetricsOptions(new DropwizardMetricsOptions()
                                          .setEnabled(true)
                                          .setRegistryName(REGISTRY_NAME)
                                          .setJmxEnabled(true)
                                          .setJmxDomain(JMX_DOMAIN)
                                          .addMonitoredHttpServerUri(new Match().setValue("/.*")
                                                                                .setAlias("Root")
                                                                                .setType(MatchType.REGEX)));

        super.beforeStartingVertx(options);
    }
}

Under "foofbar" in visualvm I can see all vertx MBeans.
Environement :

Ubuntu 18
Java Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)
Vert.x 3.5.1

Now here is my Docker file :

FROM vertx/vertx3

ENV VERTICLE_HOME /mycompany
ENV VERTICLE_NAME com.mycompany.MyVerticle
ENV LAUNCHER_CLASS com.mycompany.MyLauncher
ENV HOST_IP 0.0.0.0
ENV JAVA_OPTS -Xms256m -Xmx256m -Dvertx.metrics.options.enabled=true \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.port=50001 \
-Dcom.sun.management.jmxremote.rmi.port=50001 \
-Dcom.sun.management.jmxremote.local.only=false \
-Dcom.sun.management.jmxremote.host=$HOST_IP \
-Djava.rmi.server.hostname=$HOST_IP

ARG JAR_FILE
ARG LIBS

ADD $LIBS $VERTICLE_HOME/libs
ADD $JAR_FILE $VERTICLE_HOME/my-app.jar

EXPOSE 8080
EXPOSE 50001

WORKDIR $VERTICLE_HOME
ENTRYPOINT ["sh", "-c"]
CMD ["export CLASSPATH=my-app.jar:`find $VERTICLE_HOME/libs -printf '%p:' | sed 's/:$//'`; exec vertx run $VERTICLE_NAME --launcher-class=\"$LAUNCHER_CLASS\""]

When I connect visualvm using localhost:50001 I can see CPU metrics and regular JVM MBeans (JMImplementation, com.sum.management, java.lang...)

I don't what to suspect.

PS : BTW where is the Dockerfile for vert/vertx3, can't find it in you github repo ?

HttpClient endpoint metric does not remove the associated metrics

Intermittent failure in MetricsTest#testHttpMetricsOnClose

java.lang.AssertionError: null
	at org.junit.Assert.fail(Assert.java:86)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at org.junit.Assert.assertTrue(Assert.java:52)
	at io.vertx.test.core.AsyncTestBase.assertTrue(AsyncTestBase.java:372)
	at io.vertx.ext.dropwizard.MetricsTest.testHttpMetricsOnClose(MetricsTest.java:364)

metricsService.getMetricsSnapshot(vertx) return null when redeploy is enabled.

Example java project:

https://github.com/bckfnn/vertx-metrics-test

Watch the line stdout "metrics json in verticle" which print null when redeploy is enabled. It return the correct metrics data when redeploy is disabled.

The AbstractMetrics class seem to get loaded twice, both with the AppClassLoader and with the IsolationClassLoader.

HttpServer metrics for URI with PathParams

Hi,

Is there a way to record in a nice way metrics for URI like : https://foo.bar/path/:param (on GET or DELETE for example) ?

Actually, via JMX, I have multiple entries like :
vertx.http.servers.get-requests./path/1
vertx.http.servers.get-requests./path/2
...

Best regards,

How can I get http response time in dropwizard-metrics?

ThroughputMeter metrics snapshots are reported as Meter

Remove timer metrics

Follows up on eclipse-vertx/vert.x#2352

Cannot configure baseName from file

When setting -Dvertx.metrics.options.configPath, Vert.x will ignore the baseName field. This is also evident in the constructor code:

vertx-dropwizard-metrics/src/main/java/io/vertx/ext/dropwizard/DropwizardMetricsOptions.java

Line 121 in 2e37817

public DropwizardMetricsOptions(JsonObject json) {

It doesn't do a json.getString("baseName") anywhere in the constructor body.

Intermittent failures in io.vertx.ext.dropwizard.MetricsTest.testThreadPoolMetrics

java.lang.AssertionError: null (count) expected:<6> but was:<2>
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.failNotEquals(Assert.java:834)
    at org.junit.Assert.assertEquals(Assert.java:645)
    at io.vertx.test.core.AsyncTestBase.assertEquals(AsyncTestBase.java:431)
    at io.vertx.ext.dropwizard.MetricsTest.assertCount(MetricsTest.java:1176)
    at io.vertx.ext.dropwizard.MetricsTest.testThreadPoolMetrics(MetricsTest.java:1290)

Negative value in "vertx.pools.datasource.*.in-use"

Version

vert.x core: 3.5.0
vert.x jdbc-client: 3.5.0
jdbc driver: HSQLDB Driver 2.3.2
RDBMS: HSQLDB

General info

What is your jdbc driver - HSQLDB Driver
What is your RDBMS server - HSQLDB
What is your connection string (no user/passwords please!) - jdbc:hsqldb:mem:test?shutdown=true

Context

I created a JDBCVerticle, a worker verticle, which is responsible to execute SQL queries.
While deploying the verticle, I obtained a connection from the Database to check if DB connection can be established. I closed the connection as soon as the handler was called to return the connection to the pool. However, in the success method of the connectionHandler, I called close() on the connection second time by mistake (check file rao.lalit.verticle.JDBCVerticle.java#38,44).
JDBCConnectionImpl didnt throw any exception, as it checks if the connection is in detached mode before trying to close it. However, I was checking time-series data in Graphana with Graphite as underlying database only to find that the connection in-use value is negative. I have spent days to figure out the issue only to know that by mistake i called close() on the connection object twice.

As a owner of maintaining SQLConnection, JDBCConnectionImpl should call "metrics.end(metric, true);" only after checking if connection is open.

Do you have a reproducer?

Link to github project/gist
https://github.com/lalitjeevanrao/vertx-jdbc-metric-inuse-bug

Steps to reproduce

Checkout https://github.com/lalitjeevanrao/vertx-jdbc-metric-inuse-bug
cd vertx-jdbc-metric-inuse-bug
./gradlew clean build
java -jar build/libs/vertx-jdbc-metric-inuse-bug.jar
The console reporter will start reporting metrics in console at 10 seconds frequency.
Under -- Counters --, check "vertx.pools.datasource.DEFAULT_DS.in-use".
The value will be -1.

Under load and multiple event loops dropwizard metrics can fail to register metrics

Version - 3.3.0

We have been doing some load testing on our server and were seeing some issues. I reduced the test so that it was just testing a simple HTTP GET on a URL which produces a constant JSON payload in return. When I run this under moderate load (400 clients, 1300 rps sustained) I see numerous exceptions, some clearly identifiable as being metric related, others with less information and the clients experience intermitant failures. When I disable the vertx metrics all exceptions cease, as do the client errors. Here are some samples:

22:05:21.907 [vert.x-eventloop-thread-3] ERROR io.vertx.core.impl.ContextImpl - Unhandled exception
java.lang.NullPointerException: null
22:05:22.087 [vert.x-eventloop-thread-0] ERROR io.vertx.core.impl.ContextImpl - Unhandled exception
java.lang.IllegalArgumentException: vertx.http.servers.open-connections.127.0.0.1 is already used for a different type of metric
        at com.codahale.metrics.MetricRegistry.getOrAdd(MetricRegistry.java:325)
        at com.codahale.metrics.MetricRegistry.counter(MetricRegistry.java:115)
        at io.vertx.ext.dropwizard.impl.AbstractMetrics.counter(AbstractMetrics.java:113)
        at io.vertx.ext.dropwizard.impl.TCPMetricsImpl.connected(TCPMetricsImpl.java:62)
        at io.vertx.ext.dropwizard.impl.TCPMetricsImpl.connected(TCPMetricsImpl.java:31)
        at io.vertx.core.http.impl.HttpServerImpl$ServerHandler.lambda$createConnAndHandle$1(HttpServerImpl.java:707)
        at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:357)
        at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:234)
        at io.vertx.core.http.impl.HttpServerImpl$ServerHandler.createConnAndHandle(HttpServerImpl.java:706)
        at io.vertx.core.http.impl.HttpServerImpl$ServerHandler.doMessageReceived(HttpServerImpl.java:570)
        at io.vertx.core.http.impl.HttpServerImpl$ServerHandler.doMessageReceived(HttpServerImpl.java:522)
        at io.vertx.core.http.impl.VertxHttpHandler.channelRead(VertxHttpHandler.java:76)
        at io.vertx.core.net.impl.VertxHandler.channelRead(VertxHandler.java:122)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:326)
        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:326)
        at io.vertx.core.http.impl.HttpServerImpl$Http1xOrHttp2Handler.http1(HttpServerImpl.java:1019)
        at io.vertx.core.http.impl.HttpServerImpl$Http1xOrHttp2Handler.channelRead(HttpServerImpl.java:990)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:326)
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1320)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:334)
        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:905)
        at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:123)
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:563)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:504)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:418)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:390)
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
        at java.lang.Thread.run(Thread.java:745)
22:05:22.088 [vert.x-eventloop-thread-0] ERROR io.vertx.core.impl.ContextImpl - Unhandled exception
java.lang.NullPointerException: null

22:06:02.504 [vert.x-eventloop-thread-0] ERROR io.vertx.core.impl.ContextImpl - Unhandled exception
java.lang.NullPointerException: null
        at io.vertx.ext.dropwizard.impl.TCPMetricsImpl.disconnected(TCPMetricsImpl.java:76)
        at io.vertx.ext.dropwizard.impl.TCPMetricsImpl.disconnected(TCPMetricsImpl.java:31)
        at io.vertx.core.net.impl.ConnectionBase.handleClosed(ConnectionBase.java:198)
        at io.vertx.core.http.impl.ServerConnection.handleClosed(ServerConnection.java:350)
        at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:357)
        at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:234)
        at io.vertx.core.net.impl.VertxHandler.channelInactive(VertxHandler.java:97)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:238)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:224)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:217)
        at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:360)
        at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:325)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:238)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:224)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:217)
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1315)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:238)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:224)
        at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:887)
        at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:732)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:339)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:393)
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
        at java.lang.Thread.run(Thread.java:745)

The determining factor here appears to be the number of concurrent clients, moreso than the RPS (I did not see any issues unitl we started testing with a larger number of clients).

Make metric names configurable

Hi,

I've got an intention to override default metrics names Vertx provides. For example, I'm not happy with this metric for HTTP server (https://github.com/vert-x3/vertx-dropwizard-metrics/blob/master/src/main/java/io/vertx/ext/dropwizard/impl/VertxMetricsImpl.java#L112), as it actually leaves a colon in the metric's name. Some services treat colon in datapoint's name as invalid character (for instance Wavefront does that: https://docs.wavefront.com/wavefront_data_format.html).

In order to redefine the naming I have to extend VertxMetricsImpl class (which is a dirty as this class has a package private access), as well as provide custom factory for my new implementation.

Having configuration for metrics names or making official and clean way to redefine VertxMetricsImpl class would be really helpful to integrate metrics emitted by Vertx into common providers.

JSON options: remove backward compatibility for monitoredServerUris, monitoredClientUris and monitoredClientEndpoints

In 3.3, monitoredServerUris, monitoredClientUris and monitoredClientEndpoints have been renamed to monitoredHttpServerUris, monitoredHttpClientUris and monitoredHttpClientEndpoints, respectively.

In the JSON to options constructor, there is code to support the old options format. It shall be removed now.

Intermittent failures in io.vertx.ext.dropwizard.MetricsTest.testMultiHttpClients

This test fails from time to time on CB, at different stages:

java.lang.AssertionError: expected:<3> but was:<2>
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.failNotEquals(Assert.java:834)
    at org.junit.Assert.assertEquals(Assert.java:645)
    at org.junit.Assert.assertEquals(Assert.java:631)
    at io.vertx.test.core.AsyncTestBase.assertEquals(AsyncTestBase.java:235)
    at io.vertx.ext.dropwizard.MetricsTest.testMultiHttpClients(MetricsTest.java:1141)

java.lang.AssertionError: expected:<2> but was:<3>
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.failNotEquals(Assert.java:834)
    at org.junit.Assert.assertEquals(Assert.java:645)
    at org.junit.Assert.assertEquals(Assert.java:631)
    at io.vertx.test.core.AsyncTestBase.assertEquals(AsyncTestBase.java:235)
    at io.vertx.ext.dropwizard.MetricsTest.testMultiHttpClients(MetricsTest.java:1151)

java.lang.AssertionError: expected:<1> but was:<2>
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.failNotEquals(Assert.java:834)
    at org.junit.Assert.assertEquals(Assert.java:645)
    at org.junit.Assert.assertEquals(Assert.java:631)
    at io.vertx.test.core.AsyncTestBase.assertEquals(AsyncTestBase.java:235)
    at io.vertx.ext.dropwizard.MetricsTest.testMultiHttpClients(MetricsTest.java:1159)

My understanding is that when the latches involved reach the expected value, the SPI callbacks may not have been invoked yet, and consequently the metric snapshots are wrong.

Collect response codes per configured server url

We have configured some endpoint to be monitored by dropwizard (and grouped by type, e.g. api requets, asset requests).

  .addMonitoredHttpServerUri(new Match().setValue("/images/.*").setType(MatchType.REGEX).setAlias("image-requests"))

We have now nice metrics for how long a request takes. But we can't see how many api requests returned 5xx for example. We only have the overall 5xx count for the whole server. It would be cool to see how many 5xx we have per group (e.g. api requests, asset request) as the overall 5xx rate might be misleading (as asset requests for example can never return 5xx in our case but are done quite a lot in our system).

If you think this feature has some value I can prepare a PR (as I think it is feasible)