Disable metrics

[Jean Michel]

I understand metrics is an important and significant feature of dropwizard. However, for a memory constrained application, I would like to be able to disable metrics entirely. I haven't found a way to do so. For example Bootstrap registerMetrics() adds a number of default metrics, and then starts the JmxReporter for those ones. There seem to be other metrics registered in various places as well, which may also contribute here.

Here are some examples (from an analyze using MAT) of what I would like to reduce or get rid of entirely in this case:

Class Name                                          | Objects | Shallow Heap

-----------------------------------------------------------------------------

java.util.concurrent.ConcurrentSkipListMap$Node     |  +2 487 |      +59 688

com.codahale.metrics.WeightedSnapshot$WeightedSample|  +2 487 |      +59 688

java.lang.Double                                    |  +2 487 |      +39 792

java.util.concurrent.ConcurrentSkipListMap$Index    |  +1 261 |      +30 264

-----------------------------------------------------------------------------

So is there a kosher way I can use to disable ALL metrics?

-JM

[Peter Stackle]

There isn't an easy, out-of-the-box way to disable all metrics that I'm aware of. 

I can see two options:

1) In the `Application.run(T, Environment)` method, you can access the `MetricRegistry` from the `Environment` parameter and could call `MetricRegistry.remove()` or `.removeMatching()`  in order to remove the metrics you don't want.

2) You could set a custom `MetricRegistry` implementation on the Bootstrap object during initialization (Application.initialize(Bootstrap)) that would override the `MetricRegistry.register` method (or any other methods) with a no-op implementation.

[Jean Michel]

Thank you. I went with route 1. Seems to work fine. 

-JM

[Jean Michel]

Hmm, upon closer inspection, calling `MetricRegistry.remove()` to remove them all doesn't help. There are places in the code that seems to assume metrics is to happen regardless of configuration. One such example is the HttpConnectorFactory calling metrics.timer(httpConnections()), creating a com.codahale.metrics.Timer, which uses a Histogram to provide metrics for requests. I've found no clean-cut way to avoid this. So I guess metrics is just par for the course in DW. It is indeed a major "sales feature" in many cases, and my desire to minmize memory usage here may be unusual. But in this particular case, being able to "turn off" all metrics when not desired would be useful.

-JM

[Jochen Schalanda]

Hi Jean,

we've added a no-op metrics registry in Dropwizard Metrics 4.1.17 which you could set in your application's initialize method:

https://javadoc.io/doc/io.dropwizard.metrics/metrics-core/4.2.0-beta.1/com/codahale/metrics/NoopMetricRegistry.html

HTH,

Jochen

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dropwizard-user/6f4cda8f-bd20-4af1-9595-c8c67089d359n%40googlegroups.com.

[Jean Michel]

Jochen, will that solution also handle the issue I found with "HttpConnectorFactory calling metrics.timer(httpConnections()), creating a com.codahale.metrics.Timer…", discussed above? That appeared to be hardcoded into HttpConnectorFactory, and can't be affected by any registry, as far as I can tell.

-JM

[Jochen Schalanda]

Hi Jean,

the NoopMetricRegistry would return always the same no-op Timer, so this should also solve the case you've mentioned.

Let us know if it worked for you. :-)

Best regards,
Jochen

[Jean Michel]

Thanks. That sounds very promising. Will take a look and let you know. 

I'm currently using DW 1.3.29, which uses metrics 4.1.16, but I guess I can just override the version number for metrics to try this out? It will take some time before we get to updating to DW2.

-JM

[Jochen Schalanda]

Hi Jean

I'm currently using DW 1.3.29, which uses metrics 4.1.16, but I guess I can just override the version number for metrics to try this out?

Yes, that should work.

Best regards,

Jochen

[Jean Michel]

What's the best way for overriding the metrics version in my pom file? Is it sufficient to exclude 'metrics-core' from my 'dropwizard-core' dependency, and then add it back as a separate dependency with the desired version number? Do I also need to exclude all other metrics-related artifacts (e.g., 'metrics-jvm') one by one? Or is there an easier way altogether here perhaps? As you can tell, I'm not that well versed in maven, which is quite a beast to get to grips with.

-JM

[Jochen Schalanda]

Hi Jean,

you could import the metrics-bom in the dependencyManagement section of your POM.

https://search.maven.org/artifact/io.dropwizard.metrics/metrics-bom/4.1.17/pom

https://howtodoinjava.com/maven/maven-bom-bill-of-materials-dependency/ 

Cheers,

Jochen

Am 13.01.2021 um 10:52 schrieb Jean Michel <thew...@gmail.com>:

What's the best way for overriding the metrics version in my pom file? Is it sufficient to exclude 'metrics-core' from my 'dropwizard-core' dependency, and then add it back as a separate dependency with the desired version number? Do I also need to exclude all other metrics-related artifacts (e.g., 'metrics-jvm') one by one? Or is there an easier way altogether here perhaps? As you can tell, I'm not that well versed in maven, which is quite a beast to get to grips with.

-JM

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dropwizard-user/5849c96c-d452-4489-b3a2-b760e55c8faan%40googlegroups.com.

[Jean Michel]

Thanks! That worked fine! 

It took me a few minutes to figure out that the metrics-bom had to go before the dropwizard-bom under dependencyManagement in order to take effect, since entries in POM files generally aren't order sensitive. But then I got the version override to work, and were able to use the NoopMetricRegistry like this (in a subclass I already used to override parts of ServerCommand):

@Override

protected void run(Bootstrap<Config> bootstrap, Namespace namespace, Config configuration) throws Exception {

MetricsFactory mf = configuration.getMetricsFactory();

boolean disableMetrics = mf == null || mf.getReporters().isEmpty();

if (disableMetrics) // The NoopMetricRegistry removes/NOPs out all metrics

bootstrap.setMetricRegistry(new NoopMetricRegistry());

super.run(bootstrap, namespace, configuration);

}

-JM