Metrics v2.x

Monitor your Java web applications in production Github

Currently refactoring API for 2.x

The 2.x API is currently unstable. Please check back in July 2014 or watch for changes.

Monitoring Web Applications

Add metrics for any web application. This can be done in minutes using Enhancement for JAX-RS or Spring MVC web applications.

Web applications

Monitoring Ebean ORM

Monitor the behaviour of your Ebean ORM applications in production, test, dev.

Monitoring Ebean

What the!! Why not use ...

The metrics library I most liked and used was codahale/metrics. It has some great features but in getting into it I realised there were benefits to a simple metrics with very low overhead and regular collection (every minute).

More

Design goals

  • All the metrics are collected and reported frequently (typically every minute or every 5 minutes).
  • Statistics collectors are kept simple (count / total / average / maximum) with small overhead cost of collection (relative to Moving averages or Histograms).
  • Separate metrics collected for "Success" and "Error".

Secret Sauce

Use LongAdder, Simple metrics (count/total/average/maximum) are not only relatively cheap to collect even on busy highly concurrent applications they also are easy to 'roll up' afterwards. Metrics can be collected every 1 minute and then metrics older than say 1 month can be 'rolled up' to 5 minute or 10 minute intervals and still be very representative.

Why not use codahale/metrics?

For "Timed Events" codehale/metrics is orientated towards using Moving Averages and Histograms and these are relatively heavy weight collectors.

Provide separate error and non-error metric collection for "Timed Events". This is useful when collecting metrics where errors might have quite a different value characteristics (as in the case of soap operations and database operations etc). This means the 'statistics' for error events are keep separate from the 'normal behaviour statistics'. It also means you can easily monitor the error rate (error count to success count) for each metric.

Although Moving Averages are good, once you go to collecting and reporting metrics every minute then moving averages (expotentially weighted moving averages) are quite laggy relative to the actual aggregate statistics collected and reset every minute. If you didn't collect and report the statistics every minute (or more frequently) then the Moving Averages would be great but the intention for avaje-metrics is to collect and report the statistics every minute by default.

Histograms are good but with min and max collected and reported every minute you can get a similar value with a much lower overhead.

In summary avaje-metric has moved away from Moving Averages and Histograms in favour of regular collection and reporting of simple aggregate statistics.