yammer – Metrics made easy – Part II

Last time i explained a little example using yammer metrics to inspect runtime metrics of a standalone client application. This time we want to go a step further and instrument a web application and expose some metrics around request/response cycles.
Important Note:
For this example we need a jmx-enabled container like a Tomcat or a Glassfish. If you want to use Jetty or similar containers please provide a JMX-Registry within them. For example you can use JMinix which is quite easy (add dependency and add the JMinix servlet to your web.xml)
So, lets get started with yammer metrics for web apps. What provides metrics out of the box for your project:
* DefaultWebappMetricsFilter for request / response cycle metrics
* Little Administration Servlet with links for further inspections
* Ping Servlet for isAlive checks
* ThreadDump Servlet to inspect containers threads
* Metrics Servlet which exposes all your registered metrics as JSON
* HealthCheck Servlet which exposes all your registered HealthChecks as JSON
For todays blog we dig a bit deeper into enabling all these Servlets as well as exposing them to a JmxRegistry. In a later article we will dig deeper into health checks and standard metrics.
Now, where to start? Add metrics-core, metrics-servlet and metrics-servlets (bad naming, isn’t it?) to your pom. After that we are able to add the DefaultWebappMetricsFilter to our web.xml


Then we need to add all within the distribution shipped helper-servlets


and then expose them to an url:


Not yet .. nothing will work for now. yammer Metrics need some “bootstrapping” which cannot be done too easy with DI Frameworks like Spring. It’s a little hazzle /o\
For our little example it is enough to enable the required bootstrapping with a ServletContextListener and it’s provided methods contextInitialized and contextDestroyed.
Why do we need a programmatic bootstrapping? Because metrics searches for it’s MetricRegistries in servletcontext. It is possible doing this by hand but this won’t work with the current 3.0.0-beta1 version so i decided using this way. Furthermore it seems the easiest way enabling all the needed stuff and registries.
An apropriate contextInitialized method could look like this:

    public void contextInitialized(ServletContextEvent sce) {

The corresponding createAndBuildRegistries Method could look like this:

    private void createAndBuildRegistries(ServletContextEvent sce) {
        metricsForWebapp = new MetricRegistry("DemonstrationWebapp");
        jmxForWebapp = JmxReporter.forRegistry(metricsForWebapp).build();
        sce.getServletContext().setAttribute(DefaultWebappMetricsFilter.class.getName() + ".registry", metricsForWebapp);

and the method registerHealthChecks is used to register all developed HealthChecks to the appropriate Registry we want to expose them. Currently we implemented no HealthChecks so the HealthCheckRegistry should just expose nothing to JMX and send back a 400 via REST.
So that’s it for today. We showed you how easy it is to enhance a web-application with runtime metrics for it’s request/response cycles. In the upcoming port we will show you hw to implement some HealthChecks as well as some measurements around business-interactions.
So stay tuned …