Skip to content

Metrics missing after adding com.codahale.metrics #4142

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
vachacz opened this issue Oct 10, 2015 · 5 comments
Closed

Metrics missing after adding com.codahale.metrics #4142

vachacz opened this issue Oct 10, 2015 · 5 comments

Comments

@vachacz
Copy link

vachacz commented Oct 10, 2015

Hi,

I use Spring Boot 1.3.0 M5.

When I add compile('com.codahale.metrics:metrics-jvm:3.0.1') dependency to my project standard http-request related metrics are no longer passed to the StatsdMetricsWriter.

<app-prefix>.gauge.response.greeting:24|g
<app-prefix>.counter.status.200.greeting:2|g

Documentation mentions that that "CounterService and GaugeService are replaced with a DropwizardMetricServices". It happens in MetricsDropwizardAutoConfiguration and i think this is the reason.

Link to the documentation: http://docs.spring.io/spring-boot/docs/1.3.0.M5/reference/htmlsingle/#production-ready-dropwizard-metrics

I wanted to publish JVM stats from dropwizard and internal request statistics as well. It does not work.

There is one similar StackOverflow thread http://stackoverflow.com/questions/32215723/exporting-spring-boot-actuator-metrics-dropwizard-metrics-to-statsd. After using example code from this thread results are the same. Dropwizard JVM metrics are published to the Statsd daemon, but internal Spring metrics are not.

Is there any way to combine both metric sources ?

Thanks for you help.

@philwebb
Copy link
Member

/cc @dsyer

@dsyer
Copy link
Member

dsyer commented Oct 13, 2015

The assumption is that if you are using Dropwizard then that is what you use for export as well. You can switch the export back on by creating a @MetricExportReader bean to suck any metrics that you want back from the DW MetricRegistry.

We can certainly rethink the defaults if people find them inconvenient or surprising.

@vachacz
Copy link
Author

vachacz commented Oct 13, 2015

Thanks for your replay.

I think what can happen is, that statsd is used to collect the metrics (because i.e. it's already there used by other apps). Someone might want to store standard Spring traffic metrics and JVM metrics at the same time. Some basic JVM metrics are available in /metrics endpoint, but they don't get exported to statsd via ExportWriter. An alternative to get JVM metrics is Dropwizard reader. It works, but if overrides standard Spring traffic metrics. I could imagine, that exposing of all metrics from /metrics endpoint to a ExportWriter could be also useful.

FYI: I'm just playing around and my case does not come from a real project

Thanks, Lukasz

@jasperkremer
Copy link

I have the same problem:

I have created a custom NewRelicMetricWriter that exports metrics to NewRelic:
It is registered in my program as follows:


    @Bean
    @ExportMetricWriter
    public MetricWriter metricWriter(final MetricExportProperties export) {
        return new NewRelicMetricWriter();
    }

The same program also uses datastax Casandra driver. It has a dependency with com.codahale.metrics:metrics-core:

[INFO] +- com.datastax.cassandra:cassandra-driver-core:jar:2.1.7.1:compile
[INFO] |  +- io.netty:netty-handler:jar:4.0.27.Final:compile
[INFO] |  |  +- io.netty:netty-buffer:jar:4.0.27.Final:compile
[INFO] |  |  |  \- io.netty:netty-common:jar:4.0.27.Final:compile
[INFO] |  |  +- io.netty:netty-transport:jar:4.0.27.Final:compile
[INFO] |  |  \- io.netty:netty-codec:jar:4.0.27.Final:compile
[INFO] |  +- com.google.guava:guava:jar:14.0.1:compile
[INFO] |  \- com.codahale.metrics:metrics-core:jar:3.0.2:compile

But now my metrics are not exported anymore to my custom NewRelicMetricWriter.

How can I fix this?

@snicoll snicoll changed the title [Actuator] Metrics missing after adding com.codahale.metrics Metrics missing after adding com.codahale.metrics Jan 12, 2017
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jun 19, 2017
@wilkinsona wilkinsona removed the status: waiting-for-triage An issue we've not yet triaged label Aug 11, 2017
@wilkinsona
Copy link
Member

This has been superseded by the planned move to Micrometer-based metrics (#9970)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants