dropwizard / metrics

:chart_with_upwards_trend: Capturing JVM- and application-level metrics. So you know what's going on.

Metrics

📈 Capturing JVM- and application-level metrics. So you know what's going on.

For more information, please see the documentation

Versions

Version	Source Branch	Documentation	Status
<2.2.x	-	-	🔴 unmaintained
2.2.x	-	Docs	🔴 unmaintained
3.0.x	release/3.0.x branch	Docs	🔴 unmaintained
3.1.x	release/3.1.x branch	Docs	🔴 unmaintained
3.2.x	release/3.2.x branch	Docs	🔴 unmaintained
4.0.x	release/4.0.x branch	Docs	🔴 unmaintained
4.1.x	release/4.1.x branch	Docs	🔴 unmaintained
4.2.x	release/4.2.x branch	Docs	🟢 maintained
5.0.x	release/5.0.x branch	-	🟡 on pause

Future development

New not-backward compatible features (for example, support for tags) will be implemented in a 5.x.x release. The release will have new Maven coordinates, a new package name and a backwards-incompatible API.

Source code for 5.x.x resides in the release/5.0.x branch.

License

Copyright (c) 2010-2013 Coda Hale, Yammer.com, 2014-2021 Dropwizard Team

Published under Apache Software License 2.0, see LICENSE

metrics's Issues

Change HTTP status code when no health checks registered

Currently the MetricsServlet responds with a 500 if a health check fails OR if no health checks are registered. While I agree that having no health checks is bad I think it would be nice if that case used a separate HTTP status code so that my monitoring could separate the two cases. I suggest 404 for the case when no health checks are registered.

Flaw in ConsoleReporter shutdown()

After shutting down a ConsoleReporter it is not possible to start a new one. The executor rejects the new schedule. Testcase to test it is;

import com.yammer.metrics.reporting.ConsoleReporter;
import java.util.concurrent.TimeUnit;
import org.junit.Test;

public class MetricsFlawTest
{
    @Test
    public void givenShutdownReporterWhenCreatingNewReporterExpectSuccess()
    {
        ConsoleReporter reporter1 = new ConsoleReporter( System.out );
        reporter1.start( 1, TimeUnit.SECONDS );
        reporter1.shutdown();
        ConsoleReporter reporter2 = new ConsoleReporter( System.out );
        reporter2.start( 1, TimeUnit.SECONDS );
    }
}

How can I build this for a Java project?

Hello,

How can I build metrics to use in my java based project?

I have tried this in pom.xml:

com.yammer
metrics
2.0.0-BETA10

..............

codaRepo
Coda Hale's Repository
http://repo.codahale.com/
default

And I get this exception:
Missing artifact com.yammer:metrics:jar:2.0.0-BETA10:compile

Thanks

Invalid memory pool usage strings in GraphiteReporter.printVmMetrics

carbon-cache whines about messages of the form:

jvm.memory.memory_pool_usages.Perm Gen 0.11 1327102958

The offending line appears to be GraphiteReporter.java:343.

I'll send a pull request later if you don't get to it first; I don't have a working metrics dev environment at the moment.

Thread pools not shutting down

None of the thread pools created are shutting down when doing a hot deploy update in Tomcat.
Relying on daemon threads can be a risk when living in a container/jvm that survives the servlet life cycle...

My suggestion is to make it possible to shut thread pools down from e.g. a ServletContextListener (it would of course be enough with something like "Metrics.shutDown()" and leave the contextListener stuff to the one that implements metrics)

Stupid example follows:
public final class ShutdownContextListener implements ServletContextListener
{
@OverRide
public void contextDestroyed(final ServletContextEvent context)
{
Metrics.shutdown(); //dig down and shutdown all thread pools (i.e. MeterMetric, JmxReporter, ConsoleReporter etc)
}
...

Add support for Guava's cache

Friendly way to ser/deser metrics

A few options:

• Implement Serializable and manually manage things :-(
• bean-ify all of the classes, does not play nice with final fields.
• Choose the One True Serializer and place it's annotations all over the place.
• Jackson [1] at least has some clever ways to explain how to serialize classes without adding annotations to the original source files. Create a metrics-jacksonmagic module, and do the same for whatever other ser/deser libraries people want.

I think the last one is least bad, but I hope someone has a better idea.

[1] http://www.cowtowncoder.com/blog/archives/2009/08/entry_305.html

Bug in GC duration metrics

Seeing this in production:

"gc": {
    "duration": {
        "ConcurrentMarkSweep": {
            "type": "timer",
            "duration": {
                "unit": "milliseconds",
                "min": 45.0,
                // I suspect we didn't spend 200 years in GC
                "max": 9.223372036854775E12,
                "mean": -1.2464015984372668E11,
                "std_dev": 1.0721952202082451E12,
                "median": 2092.0,
                "p75": 5437.0,
                "p95": 7008.0,
                "p98": 4.611686022016888E12,
                "p99": 9.223372036854775E12,
                "p999": 9.223372036854775E12
            },
            "rate": {
                "unit": "hours",
                "count": 74,
                "mean": 92.8048769995121,
                "m1": 17.709334732763374,
                "m5": 25.26532874469293,
                "m15": 99.77693684369099
            }
        },
        "ParNew": {
            "type": "timer",
            "duration": {
                "unit": "milliseconds",
                "min": 1.0,
                "max": 239.0,
                "mean": 39.96952908587257,
                "std_dev": 31.414993979341588,
                "median": 30.0,
                "p75": 56.0,
                "p95": 93.89999999999998,
                "p98": 136.76,
                "p99": 156.53999999999985,
                "p999": 239.0
            },
            "rate": {
                "unit": "hours",
                "count": 361,
                "mean": 452.7364351143507,
                "m1": 405.6806460635502,
                "m5": 402.32293854651465,
                "m15": 456.7277139153417
            }
        }
    },
    "throughput": {
        "ConcurrentMarkSweep": {
            "type": "meter",
            "event_type": "bytes",
            "unit": "seconds",
            "count": 16681453136,
            "mean": 5811260.435752383,
            "m1": 5524948.0659188535,
            "m5": 7361606.051429296,
            "m15": 6370836.471473948
        },
        "ParNew": {
            "type": "meter",
            "event_type": "bytes",
            "unit": "seconds",
            "count": 73375904376,
            "mean": 2.556168014277674E7,
            "m1": 3.0556347765034005E7,
            "m5": 3.0240997793706447E7,
            "m15": 2.820924125605985E7
        }
    }
}

Enable customized metric names when using annotations

= Scenario
We have multiple version of the same service in production with different root contexts in the same servlet container and JVM.

= Problem
We don't want JMX, Graphite, etc from one version to overwrite that of another version. When constructing metrics "by hand" this is manageable by simply setting the name to include the deployment context. When using annotations (which we prefer) it's not since the context isn't available as static expression that can be used in the annotation and, additionally, it would clutter all annotations.

= Proposed solution
Provide a "hook" in the InstrumentationModule in metrics-guice that allows users to customize how the metrics created from annotations are named.

JMX reset operation on metrics

It would be really great to have operation "reset" on every metric exposed via JMX.

Meter rate Long instead of Double

I needed to convert library to Scala 2.7.7 and that issue is in 2.7.7. I'm not sure if 2.8 has different behavior...
Method rate returns Long value as "count" is a Long. Need to be converted to Double before calculating:
def rate = Rate.perNanosecond(
if (count > 0) count.asInstanceOf [ Double ] / ( Clock.nanoTime - startTime )
else 0.0
)

Move documentation to Sphinx

Dropwizard's new doc hotness needs to be shared.

XML Schema's not present at specified URL for Spring Configuration.

As given in the documentation

xmlns:metrics="http://www.yammer.com/schema/metrics"
xsi:schemaLocation="http://www.yammer.com/schema/metrics http://www.yammer.com/schema/metrics/metrics.xsd"

Do not exist.

Using the example provided at http://metrics.codahale.com/manual/spring/
Results in the expception : https://gist.github.com/1934563

GangliaReporter

It would be nice to have a GangliaReporter similar to the GraphiteReporter (possibly as a separate repo, just putting it down here so I don't forget.)

There's a Java lib for gmetric: http://code.google.com/p/embeddedgmetric/wiki/GmetricJava

Add cache-control headers

It sucks to hit refresh a lot and not see new data.

Scala versions

Now that Scala 2.9.0.final is out, is it safe to just support Scala 2.8.1 and 2.9.0?

MetricsServlet sometimes dies when a Gauge throws an exception

We've seen a few backtraces like these on our servers:

2011-08-18 19:25:04,012 (50338760) [http-8080-11] ERROR com.greplin.common.server.ErrorLoggingFilter - Uncaught error in servlet
org.codehaus.jackson.JsonGenerationException: Can not write text value, expecting field name
at org.codehaus.jackson.impl.JsonGeneratorBase._reportError(JsonGeneratorBase.java:481)
at org.codehaus.jackson.impl.Utf8Generator._verifyValueWrite(Utf8Generator.java:919)
at org.codehaus.jackson.impl.Utf8Generator.writeString(Utf8Generator.java:446)
at com.yammer.metrics.reporting.MetricsServlet.writeGauge(MetricsServlet.java:325)
at com.yammer.metrics.reporting.MetricsServlet.writeMetric(MetricsServlet.java:267)
at com.yammer.metrics.reporting.MetricsServlet.writeRegularMetrics(MetricsServlet.java:256)
at com.yammer.metrics.reporting.MetricsServlet.handleMetrics(MetricsServlet.java:243)
at com.yammer.metrics.reporting.MetricsServlet.doGet(MetricsServlet.java:151)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.greplin.common.server.ServletContextFilter.doFilter(ServletContextFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.greplin.common.server.ErrorLoggingFilter.doFilter(ErrorLoggingFilter.java:31)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:865)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)

I looked at the writeGauge source code and tried to reproduce the bug in a simple test case, without much luck. Just thought I'd report the bug in case anyone else has any ideas. This seems to occur very rarely, fwiw (100s of servers, with their status pages being polled dozens of times per hour, and we only see ~1 of these per day).

Use Metics to wrap legacy and dynamic MBeans

Not really an issue, but I'm not finding the mailing list :-)

We've staring using metics in a green-field project and like the json output from the servet.

We would like to leverage this package to wrap our legacy "metrics" that are exposed via JMX. We also have a need to expose JMX metrics from projects where the MBeans are not know ahead of time.

I have a working proof of concept that uses JmxGuage as a wrapper around an existing MBean. I receive notifications of new MBeans by registering an MBean listener, then creating Metrics as a response.

I wanted to make sure there was no visceral reaction to this idea before I proceed further.

Thoughts?

• Bob

MeterMBean calls everything minute, regardless of rate TimeUnit

public static interface MeterMBean extends MetricMBean {
    public long getCount();
    public String getEventType();
    public TimeUnit getRateUnit();
    public double getMeanRate();
    public double getOneMinuteRate();
    public double getFiveMinuteRate();
    public double getFifteenMinuteRate();
}

s/Minute/TimeUnit would be clearer.

GraphiteReporter prints exception stack traces to STDERR

Should probably be using Slf4j and a logger.

Make JVM metrics in MetricsServlet optional

For folks who have multiple Metrics-enabled applications in a single JVM, having multiple VirtualMachineMetrics instances all keeping track of the same data is a waste of cycles.

We should extract VirtualMachineMetrics to a non-singleton and scope it to the MetricsServlet instance.

(h/t @Hitta)

NPE in com.yammer.metrics.util.Utils:sortMetrics

As described at http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Class.html#getCanonicalName() the canonical name of an anonymous or local class will be null. This results in an NPE at the call to entry.getKey().getKlass().getCanonicalName().replace etc. This could likely be replaced with a call to getName or getSimpleName

Change JMXReporter.GaugeMBean to MXBean

Sometimes gauge the callback might run a non-trivial operation that collects several data items. Instead of running the whole operation for each data item, it is preferable for the gauge to return composite data. MXBeans support composite data better than regular MBeans.

All that is required to implement this is change the name of GaugeMBean to GaugeMXBean or to annotate the type declaration with @javax.management.MXBean. It is a trivial code change that provides a useful functionality.

Allow for fine-grained filtering of metrics

Currently reporters' outputs can be filtered by MetricName, but it would be preferable to have more fine-grained filters than that, ideally down to the measurement level.

Pull request #91 by @cburroughs attempted to address this, but it's still an open issue.

AbstractMethodError on HEAD

Perhaps related to 606249b, but my app doesn't start correctly anymore. I get failures when instantiating my objects. I'm not using the feature in this commit myself, so I can't evaluate it's usefulness.

Exception in thread "main" java.lang.AbstractMethodError:     seevibes.twitter.Converter.metricsRegistry()Lcom/yammer/metrics/core/MetricsRegistry;
    at com.yammer.metrics.Instrumented$class.com$yammer$metrics$Instrumented$$metricsGroup(Instrumented.scala:7)
    at seevibes.twitter.Converter.com$yammer$metrics$Instrumented$$metricsGroup(Converter.scala:21)
    at com.yammer.metrics.Instrumented$class.metrics(Instrumented.scala:12)
    at seevibes.twitter.Converter.metrics(Converter.scala:21)

I'll try without this commit tomorrow.

Optionally persistent reservoir pool state for Histograms/Timers

It's annoying for us, operationally, to reset histograms after server restarts (sometimes).

If I write this feature (off by default and maintaining API backwards-compatible), in principle could it be accepted upstream?

Metrics & GangliaReporter reports TimeUnit to Ganglia

Short summary: a Meter, e.g. "requests per second", appears to be reported to Ganglia with units of "seconds" as opposed to "requests".

This is with Metrics 2.0.0.

Meter values are reported to Ganglia with measurements in terms of TimeUnits. I have a Meter, for example, which measures
requests per minute. What appears in our Ganglia web display is a y-axis marked MINUTES as opposed to "requests".
Configuration is simple

final MetricName tps = new MetricName("project", "http", "submit", ""); 
final Meter meter = Metrics.newMeter(tps, "requests", TimeUnit.MINUTES); 
registry.add(tps, meter); 

In GangliaReporter, the meter.rateUnit() is used to report "units" to Ganglia, but this appears to mean Ganglia is receiving values in terms of, e.g. minutes - as if it were a timer, rather than a request per minute counter.

RejectedExecutionException when using the MetricsServletContextListener in tests

I have a bunch of unit tests that bring up an embedded jetty server hosting a servlet that uses a timer metric. The first test works fine, but any subsequent one fails with a RejectedExecutionException:

java.util.concurrent.RejectedExecutionException
    at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
    at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
    at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:215)
    at java.util.concurrent.ScheduledThreadPoolExecutor.scheduleAtFixedRate(ScheduledThreadPoolExecutor.java:426)
    at com.yammer.metrics.core.MeterMetric.newMeter(MeterMetric.java:37)
    at com.yammer.metrics.core.TimerMetric.<init>(TimerMetric.java:30)
 ...

The reason for that seems to be that I use the MetricsServletContextListener which calls Utils.shutdownThreadPools, and then creating a new metric calls scheduleAtFixedRate on MeterMetric.TICK_THREAD which however is at that point in shutdown state.

Here's a simple JUnit java test case that shows this without servlets:

public class SimpleTimerTest {
    public static class Thing {
        private final TimerMetric timer = new TimerMetric(TimeUnit.MILLISECONDS, TimeUnit.SECONDS);

        public void doStuff() throws Exception {
            timer.time(new Callable<Void>() {
                @Override
                public Void call() throws Exception {
                    return null;
                }
            });
        }
    }

    @Test
    public void firstTest() throws Exception  {
        new Thing().doStuff();
        Utils.shutdownThreadPools();
    }

    @Test
    public void secondTest() throws Exception  {
        new Thing().doStuff();
        Utils.shutdownThreadPools();
    }
}

The first test will run just fine, but the second one will fail with the above exception.

Sample iterator wrong size

I needed to convert library to Scala 2.7.7 and that issue is in 2.7.7. I'm not sure if 2.8 has different behavior...
current implementation

def iterator = {
val copy: Array[A] = Array.fill(window)(init)
for (i <- 0 until size) {
copy(i) = values.get(i)
}
copy.iterator
}

needs to be:

def iterator = {
val copy: Array[A] = Array.fill(size)(init)
for (i <- 0 until size) {
copy(i) = values.get(i)
}
copy.iterator
}

JmxReport.Timer should be static

This class does not dependon JmxReport instance and would be easier to use if this class is static

HistogramMetric.updateVariance() is not thread-safe

This code does not look thread-safe:

HistogramMetric.updateVariance():

            while (!done) {
                final long oldMCas = varianceM.get();
                final double oldM = longBitsToDouble(oldMCas);
                final double newM = oldM + ((value - oldM) / count());

                final long oldSCas = varianceS.get();
                final double oldS = longBitsToDouble(oldSCas);
                final double newS = oldS + ((value - oldM) * (value - newM));

                done = varianceM.compareAndSet(oldMCas, doubleToLongBits(newM)) &&
                        varianceS.compareAndSet(oldSCas, doubleToLongBits(newS));
            }

The && of two atomic operations is not an atomic operation: the CAS operations at the end could be interleaved between threads so that the first is successful and the second one fails, in which case the loop would repeat and varianceM would have an incorrect value.

This is a probably rare case, but I noticed it so I thought I'd mention it.

This could be fixed by using a lock, or with an atomic reference to an object that contains both M and S and thus could be CAS'ed in one atomic operation.

Use object mapping for Servlet

I was wondering, would making that configurable be useful ? E.g. so that somebody for instance could have json generated instead of plain text ?
I toyed with the idea a little bit here: https://github.com/tomdz/metrics/commits/healthcheck-renderer

Timer - slow callback

When using timers, it'd be nice to supply a threshold and some code and have that code run when the timer exceeds the threshold.

Think something like slow-query logging to record additional state.

Float precision

Before I work on a fix for this, I have some data in JSON that ends up looking like this:

m1: 1.7286243339272653e-161
m5: 6.040173010840546e-34
m15: 4.822140384259968e-13

I'm pretty sure that anything below about 0.0000001 can be safely treated as zero.

What do you think?

Add link to mailing list back to docs

ClassCastException in GraphiteReporter

While trying to use GraphiteReporter as a mostly drop-in replacement for GangliaReporter, GraphiteReporter it gets a ClassCastException when trying to insert into the map in Utils.sortAndFilterMetrics()

java.lang.ClassCastException: com.yammer.metrics.core.MetricName cannot be cast to java.lang.Comparable
    at java.util.TreeMap.toComparable(TreeMap.java:164)
    at java.util.TreeMap.put(TreeMap.java:1971)
    at com.yammer.metrics.util.Utils.sortAndFilterMetrics(Utils.java:46)
    at com.yammer.metrics.reporting.GraphiteReporter.printRegularMetrics(GraphiteReporter.java:208)
    at com.yammer.metrics.reporting.GraphiteReporter.run(GraphiteReporter.java:180)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:680)

Histogram doesn't update min/max correctly when initial updates are 0 or negative

Test case:

var Histogram = require('../metrics/histogram');

var broken = function(callback) {
  console.log("\nBroken histogram demo");
  var brokenHist = Histogram.createUniformHistogram(1000);
  console.log("Adding 0 to histogram");
  brokenHist.update(0);
  console.log("Current min: " + brokenHist.min + ", max: " + brokenHist.max);
  console.log("Adding -1 to histogram");
  brokenHist.update(-1);
  console.log("Current min: " + brokenHist.min + ", max: " + brokenHist.max);
  console.log("Adding 1 to histogram");
  brokenHist.update(1);
  console.log("Current min: " + brokenHist.min + ", max: " + brokenHist.max);

  if (typeof callback == 'function') {
    callback();
  }
};

Broken histogram demo
Adding 0 to histogram
Current min: 0, max: null
Adding -1 to histogram
Current min: -1, max: null
Adding 1 to histogram
Current min: -1, max: 1

Fix forthcoming in pull request.

Add some docs to help using spring module

The spring module doc is difficult to understand what we can do or not.

Please add a sample after the config.

Can we use annotation with sprint module or is it only working for guice ?

Errors registering Gauge<Object> with JMX

This issue is caused by using MXBeans instead of MBeans. Reverting 90396fc resolves this issue.

javax.management.NotCompliantMBeanException: com.yammer.metrics.reporting.JmxReporter$GaugeMXBean: Method com.yammer.metrics.reporting.JmxReporter$GaugeMXBean.getValue has parameter or return type that cannot be translated into an open type
Caused by: java.lang.IllegalArgumentException: Method com.yammer.metrics.reporting.JmxReporter$GaugeMXBean.getValue has parameter or return type that cannot be translated into an open type
    at com.sun.jmx.mbeanserver.ConvertingMethod.from(ConvertingMethod.java:32)
...
Caused by: javax.management.openmbean.OpenDataException: Cannot convert type: class java.lang.Object
    at com.sun.jmx.mbeanserver.OpenConverter.openDataException(OpenConverter.java:1411)
...
Caused by: javax.management.openmbean.OpenDataException: Can't map java.lang.Object to an open data type
    at com.sun.jmx.mbeanserver.OpenConverter.makeCompositeConverter(OpenConverter.java:454)

Can't create metric instances in the default package

Creating a metric in the default package results in a NPE in the MetricName constructor when evaluating

    public MetricName(Class<?> klass, String name, String scope) {
        this(klass.getPackage().getName(),
             klass.getSimpleName().replaceAll("\\$$", ""),
             name,
             scope);
    }

klass.getPackage() returns null in this case.

This occurs under version 2.0.0-BETA18-SNAPSHOT.

MetricsServlet incorrectly handles servlet paths

Say you have a webapp mapped to the context path "/foo". Then, you map the metrics servlet as follows:

  <servlet-mapping>
    <servlet-name>Metrics</servlet-name>
    <url-pattern>/monitoring/*</url-pattern>
  </servlet-mapping>

...attempting to expose the metrics servlet on "/foo/monitoring/*". When the MetricsServlet is initialized, the lines like:

this.metricsUri = addContextPath(contextPath, config.getInitParameter("metrics-uri"), this.metricsUri);

...will set "metricsUri = /foo/metrics". To avoid this, you set the metrics-uri init-param to "/monitoring/metrics". Then, in the doGet() method, the req.getPathInfo() call will return "/metrics", and you'll get a 404. Changing this to:

String uri = req.getServletPath() + req.getPathInfo();

...will fix the issue.

EhChache decorator is unusable in "by configuration" form

Current implementation of Metrics' ehcache decorator relies on static factory method "instrument". Ehcache has support for declarative way of configuring decorators:

   <cacheDecoratorFactory
        class="com.yammer.metrics.ehcache.InstrumentedEhcacheFactory"
        properties="property1=36 ..." />

http://ehcache.org/documentation/apis/cache-decorators#by-configuration

It would be possible to monitor second level Hibernate caches if Metrics would support this configuration style.

Way to delete metrics

Two related ways to think about similar problems:

1. I have metrics for operations types with ids 1..n. If a query is no longer used I'd like to delete it's Metrics without restarting the jvm
2. Have at most m metrics for n operation types, if m+1's metrics are created, delete an older one.

I'd be prefer to pass in my own ConcurrentMap (so I can use CLHM, a guava MapMaker, or something else that implements whatever crazy policy I want), but manual deletes would also be okay. If this seems reasonable to you I can take a stab at making the changes, but would probably wait for the de-static-fication merge.

Unncessary thread pool creation in GraphiteReporter

I recently started using GraphiteReporter and I notice that it seems to create a new thread pool (metricsRegistry.threadPools().newScheduledThreadPool(1, "graphite-reporter");) even if I do a new instead of calling GraphiteReporter.enable(). I propose that we move the thread pool creation to enable() instead of the constructor.

I also noticed that the class has a start() method but no stop() method. Should we supply one in case users want to temporarily or permanently disable the stats reporting?

Would you be open to a patch that fixes these two issues?

servlet-api:3.0 getContextPath AdminServlet

Hi,
using tomcat 7 which is using servlet-api:3.0 the visibility of getContextPath() of ServletContext was changed to package level.
at AdminServlet line 80 the follwoing code gets error this.contextPath = context.getContextPath()
java.lang.NoSuchMethodError: javax.servlet.ServletContext.getEffectiveSessionTrackingModes()Ljava/util/Set;

Regards, Avihay

Expose HealthChecks via JMX

Would it be possible to expose each registered HealthCheck as an MBean, run the check when the bean's attribute is queried, and return the check result? This would be really useful so the Nagios check_jmx plugin could run a health check on apps that can't expose the servlet for /healthcheck.

"Use MXBeans for JMX" Breaks Gauge Import

Running from trunk, the fix in codahale/metrics@90396fc causes an exception to be thrown when a Gauge is registered. The Gauge looks something like this

  Metrics.newGauge(oomMName, new Gauge<Integer>() {
                    @Override public Integer value() {
                        final File logDir = new File(System.getProperty("log.dir"));
                        final File[] list = logDir.listFiles((FileFilter) new NameFileFilter("heap.dump"));
                        return list == null ? 0 : list.length;
                    }
                })

The problem appears in JDK code which I can follow through the debugger, but which doesn't include debug symbols - not sure what is going wrong, exactly. The problem shows up in com.sun.jmx.mbeanserver.ConvertingMethod#from, when it tries to determine the return type of, I think, the getValue() method. To work around this I reverted the commit locally and it works. I don't have a fix.

Stack trace is:
2012-03-01 13:06:39,830 [main] WARN com.yammer.metrics.reporting.JmxReporter Error processing tsc:type=pages,scope=search,name=async-callback-task
javax.management.NotCompliantMBeanException: com.yammer.metrics.reporting.JmxReporter$GaugeMXBean: Method com.yammer.metrics.reporting.JmxReporter$GaugeMXBean.getValue has parameter or return type that cannot be translated into an open type
at com.sun.jmx.mbeanserver.Introspector.throwException(Introspector.java:412)
at com.sun.jmx.mbeanserver.MBeanAnalyzer.(MBeanAnalyzer.java:101)
at com.sun.jmx.mbeanserver.MBeanAnalyzer.analyzer(MBeanAnalyzer.java:87)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.getAnalyzer(MXBeanIntrospector.java:53)
at com.sun.jmx.mbeanserver.MBeanIntrospector.getPerInterface(MBeanIntrospector.java:163)
at com.sun.jmx.mbeanserver.MBeanSupport.(MBeanSupport.java:147)
at com.sun.jmx.mbeanserver.MXBeanSupport.(MXBeanSupport.java:48)
at com.sun.jmx.mbeanserver.Introspector.makeDynamicMBean(Introspector.java:184)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:915)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at com.yammer.metrics.reporting.JmxReporter.registerBean(JmxReporter.java:451)
at com.yammer.metrics.reporting.JmxReporter.processGauge(JmxReporter.java:429)
at com.yammer.metrics.reporting.JmxReporter.processGauge(JmxReporter.java:16)
at com.yammer.metrics.core.Gauge.processWith(Gauge.java:28)
at com.yammer.metrics.reporting.JmxReporter.onMetricAdded(JmxReporter.java:386)
at com.yammer.metrics.core.MetricsRegistry.notifyMetricAdded(MetricsRegistry.java:516)
at com.yammer.metrics.core.MetricsRegistry.getOrAdd(MetricsRegistry.java:491)
at com.yammer.metrics.core.MetricsRegistry.newGauge(MetricsRegistry.java:79)
at com.yammer.metrics.Metrics.newGauge(Metrics.java:70)
at com.example.App.(App.java:183)
Caused by: java.lang.IllegalArgumentException: Method com.yammer.metrics.reporting.JmxReporter$GaugeMXBean.getValue has parameter or return type that cannot be translated into an open type
at com.sun.jmx.mbeanserver.ConvertingMethod.from(ConvertingMethod.java:32)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.mFrom(MXBeanIntrospector.java:63)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.mFrom(MXBeanIntrospector.java:33)
at com.sun.jmx.mbeanserver.MBeanAnalyzer.initMaps(MBeanAnalyzer.java:118)
at com.sun.jmx.mbeanserver.MBeanAnalyzer.(MBeanAnalyzer.java:99)
... 25 more
Caused by: javax.management.openmbean.OpenDataException: Cannot convert type: class java.lang.Object
at com.sun.jmx.mbeanserver.OpenConverter.openDataException(OpenConverter.java:1411)
at com.sun.jmx.mbeanserver.OpenConverter.toConverter(OpenConverter.java:264)
at com.sun.jmx.mbeanserver.ConvertingMethod.(ConvertingMethod.java:184)
at com.sun.jmx.mbeanserver.ConvertingMethod.from(ConvertingMethod.java:27)
... 29 more
Caused by: javax.management.openmbean.OpenDataException: Can't map java.lang.Object to an open data type
at com.sun.jmx.mbeanserver.OpenConverter.makeCompositeConverter(OpenConverter.java:454)
at com.sun.jmx.mbeanserver.OpenConverter.makeConverter(OpenConverter.java:293)
at com.sun.jmx.mbeanserver.OpenConverter.toConverter(OpenConverter.java:262)
... 31 more

ArrayIndexOutOfBoundsException thrown from Snapshot

I found this exception in my logs today. I am running Metrics 2.0.0-BETA19. I would guess the Collection the Snapshot is generated from is not properly locked and has changed size.

E 01-16 13:59:07.377 c.y.m.r.GraphiteReporter:234 :::] Error printing regular metrics:
java.lang.ArrayIndexOutOfBoundsException: 1028
    at com.yammer.metrics.stats.Snapshot.<init>(Snapshot.java:33) 
    at com.yammer.metrics.stats.ExponentiallyDecayingSample.getSnapshot(ExponentiallyDecayingSample.java:107) 
    at com.yammer.metrics.core.Histogram.getSnapshot(Histogram.java:183) 
    at com.yammer.metrics.core.Timer.getSnapshot(Timer.java:173) 
    at com.yammer.metrics.reporting.GraphiteReporter.sendSampling(GraphiteReporter.java:330)
    at com.yammer.metrics.reporting.GraphiteReporter.processTimer(GraphiteReporter.java:319)
    at com.yammer.metrics.reporting.GraphiteReporter.processTimer(GraphiteReporter.java:26)
    at com.yammer.metrics.core.Timer.processWith(Timer.java:204) 
    at com.yammer.metrics.reporting.GraphiteReporter.printRegularMetrics(GraphiteReporter.java:232)
    at com.yammer.metrics.reporting.GraphiteReporter.run(GraphiteReporter.java:198)

Tests don't compile ...

I get errors like

[ERROR] metrics-core/src/test/scala/com/yammer/metrics/core/tests/CounterMetricSpec.scala:12: error: value mustEqual is not a member of Long
[INFO]       counter.count.mustEqual(0)
[INFO]                     ^

Maybe you need to update the version of simplespec available in your maven repository?

NullPointerException in GraphiteReporter if Graphite server is unavailable, terminates reporter thread

If the remote Graphite server can't be found, the GraphiteReporter throws a NullPointerException from within the catch clause because the 'writer' variable is null:

public void run() {
    Socket socket = null;
    try {
        socket = new Socket(host, port);
        // ...
    } catch (Exception e) {
        log.error("Error:", e);
        try {
            writer.flush();       // <-- throws NullPointerException if opening the socket fails
        } catch (IOException e1) {
            log.error("Error while flushing writer:", e1);
        }
    } finally {
        // ...
    }
}

The original error is still reported by the first line in the catch clause, but the NPE is not logged and silently throws the exception from the scheduled thread. This means that the scheduler never runs the task again.