Persist Coda Hale Metric information

Question

I am a newbee to Coda Hale Metrics. I have created a sample spring app which is having a simple RESTful web service method.

I have used Meter, Timer and Counter tools provided by Coda Hale Metrics framework, to track the number of requests, request ratio and request duration. Currently I output these info to the console by using the Console Reporter of Metrics (please find the code below).

@Override
    public void configureReporters(MetricRegistry metricRegistry) {

        registerReporter(ConsoleReporter.forRegistry(metricRegistry).build())
                .start(30, TimeUnit.SECONDS);
    }

I have few questions regarding Coda Hale Metrics.

(1) Currently the Counter shows the total no. of request made since the server is up. Are there any way to get the no. of requests made in a specific reporting period (ex:- count for 1st 30 seconds = count1, count for 2nd 30 seconds = count2, etc...)

(2) Is it possible to get the duration of each request using Timer? Currently Timer shows min, max and average rates of all the requests being made.

(3) Are there any possibilities to persist those Metrics data into an external DB (ex:- MySQL)?

Below is my REST service method.

@RequestMapping(value = "/examplerest", method = RequestMethod.GET)
    @ResponseBody
    @Metered(name="exampleRestMetered")
    @Timed(name="exampleRestTimed")
    @Counted(name="exampleRestCounted", monotonic=true)
    public String exampleRest(
            HttpServletResponse response) {

/**
some logics here
*/
}

I appreciate your guidance on this.

Thanks.

Answer 1

1) Are there any way to get the no. of requests made in a specific reporting period?

Not from a counter directly. However, a Meter or Timer outputs an "m1_rate" which should be the count of calls within the past minute.

Generally, I would collect the counter's value periodically and write a query against my metrics database to perform this kind of analysis.

2) Hell no. That's not what a Timer is for. Think about it: you might have millions of calls to Timer within a reporting window. Keeping all that data around would both inflate the size of a Timer in memory and the complexity of computing its reported values.

If you really need the time for each request, this is a job for logging or auditing. You could also log some unique identifying characteristics of the request to help you roll up performance along various axis.

Note that you may be able to assemble some of the intel you're looking for w/r/t collecting request timings through the various rates and meters reported for a Timer. For example, if you know that 1000 requests happened in the last minute (because the m1_rate is 16.6 Hz or 1000 requests per minute) and you know the 50th Percentile time is 10ms and the 99th Percentile is 100ms, you can assume at least 500 requests completed in 10ms or less and that 10 or more requests completed in 100ms or more.

3) Sure. DW Reporters are pluggable and mad basic, you could write one in a day (assuming you can't find an acceptable open offering).

BUt IMO, the best place to persist metrics is a metrics-specific database. There are two Reporters built into the DropWizard package that help with this: a Ganglia reporter and a Graphite reporter.

The advantage of using one of these tools is that they are built for efficient storage, retrieval and application of functions on time series data. Consider: you've got a counter and you want to graph its rate of change over time. With Graphite, you simply wrap your call to graph the value with a derivative() and bam, you've got the rate. I have no idea how I'd perform that operation in SQL, which is understandably more concerned with Sets than Series.