Collecting metrics is important for every project to analyze the behavior of the system in terms of resources used, performance, etc. It is however often overlooked the aspect of the development. In this article let me show you how we can easily gather the basic metrics from our hybris/SAP Commerce instance.

Define the metrics!

First of all, let’s enlist our key metrics we want to measure. We want to focus on runtime metrics. Below is an exemplary list of metrics to be tracked.

Performance

  • method execution time,
  • request handling time,
  • number of executions of particular code

Business metrics

  • orders created,
  • email sent,
  • HTTP errors (as simple measure of user satisfaction),
  • searched keywords

Of course, we could imagine checking other metrics like:

  • database connections,
  • Garbage Collector statistics,
  • disk usage,
  • thread pool usage,
  • memory usage

However, those we can easily measure using tools like zabbix or prometheus.

On the other hand static analysis can be done using sonarqube which can help us determine:

  • code quality through static code analysis,
  • security – checking vulnerabilities
  • testability – coverage with unit tests

Ok then, we know what we want to measure, but how do it mos easily?

metrics.dropwizard.io to the rescue

It turns out SAP Commerce already has a dependency to a great metrics gathering library called metrics.dropwizard.io. According to their site, it is a powerful toolkit of ways to measure the behavior of critical components in applications.

SAP Commerce introduces a dependency to this library in its core extension. For SAP Commerce 1911 version this looks like:

<dropwizard.metrics.version>4.0.2</dropwizard.metrics.version>
...
<dependency>
    <groupId>io.dropwizard.metrics</groupId>
    <artifactId>metrics-core</artifactId>
    <version>${dropwizard.metrics.version}</version>
</dependency>

Usage of Metrics library is very simple if only we learn a few key concepts:

Metric registries

The starting point for Metrics is the MetricRegistry class. It is a collection of all the metrics that we define in our e-commerce solution. We will define one global registry that will handle the whole application:

<bean id="metricRegistry" class="com.codahale.metrics.MetricRegistry"/>

Metric names

Since we have defined the registry now we can insert metrics to it. Each metric has unique! name (in context of the registry):

MetricRegistry.name(ProductPageController.class, "requests")

Method execution time

Now we are ready do gather our first metric. To measure execution of key fragments of our application code we will use aspects to dynamically add the metric code:

Then we have to define spring bean for our advice:

<bean id="executionTimeAdvice" class="com.c4tune.metrics.ExecutionTimeAdvice">
    <property name="metricRegistry" ref="metrics"/>
</bean>

The last point is to define the aspect with its pointcut to tell spring-aop library for which method calls it should execute our advice:

<aop:config>
    <aop:aspect id="controllerTimeAspect" ref="executionTimeAdvice">
        <aop:pointcut id="controllerPointcut" expression="@annotation(org.springframework.web.bind.annotation.RequestMapping) && execution(public * *(..))"/>
        <aop:around method="timeAroundAdvice" pointcut-ref="controllerPointcut" />
    </aop:aspect>  
</aop:config>

Above aspect will match every public method which is annotated with @RequestMapping – so basically controller methods in our application. To make it more complete one can also add similar aspects for @GetMapping, @PostMapping and so on.

Visualization of data

Each metric can be then visualized using custom servlet or simply using OOTB functionalities:

MetricsServlet

MetricsServlet exposes the state of the metrics in a particular registry as a JSON object. For details see https://metrics.dropwizard.io/3.1.0/manual/servlets/#manual-servlets

JMX

With om.codahale.metrics.jmx.JmxReporter, you can expose your metrics as JMX MBeans. To explore them you can use VisualVM (which ships with most JDKs as jvisualvm) or JConsole (which ships with most JDKs as jconsole).

To report metrics via JMX:

final JmxReporter reporter = JmxReporter.forRegistry(registry).build(); reporter.start();
Metrics exposed as JMX MBeans being viewed in VisualVM's MBeans browser

2 Comments

SeoJ · 27 January 2020 at 4 h 01 min

Awesome post! Keep up the great work! 🙂

AffiliateLabz · 16 February 2020 at 4 h 16 min

Great content! Super high-quality! Keep it up! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *