If you develop a Java application on the Neo environment in SAP Cloud Platform (SAP CP), you can make use of some default metrics like memory and CPU usage, busy threads, requests per minute, etc. If they are not enough, there is the option to add custom ones based on JMX MBeans. The process is described here.
All the available MBeans can be accessed via the JMX Console. Navigate to Cloud Cockpit -> your region with Neo Environment -> Global Account -> Subaccount -> Java applications -> your Java application -> JMX Console. You can directly check MBeans’ attribute values, or even invoke their operations and check the outcome. Also, these are all MBeans which might be used for creating custom metrics – there are some default ones which are coming from Tomcat or the JVM itself, as well as all MBeans registered by you (if any).
Although quite straightforward indeed, implementing MBeans might still be tedious. In this blog post I will describe how to make use of a third-party tools for introducing a variety of different metrics to your application. The tool being used in the example is Dropwizard Metrics, however the same approach applies for others as well.
In short, a metrics API is used inside the application in a very convenient manner. MBeans are automatically generated and registered, so the only step left is to register the custom metrics into the monitoring service out of them. Support for custom thresholds and alerting is coming out of the box, no question.
So first, let’s add the dependency to Dropwizard Metrics in our Java app. In case the project is being built by Maven, add those Maven dependencies:
<dependency> <groupId>io.dropwizard.metrics</groupId> <artifactId>metrics-core</artifactId> <version>4.0.2</version> </dependency> <dependency> <groupId>io.dropwizard.metrics</groupId> <artifactId>metrics-jmx</artifactId> <version>4.0.2</version> </dependency>
Alternatively, those two jars might be added under WEB-INF/lib:
WEB-INF/lib |- metrics-core-4.0.2 |- metrics-jmx-4.0.2
Now let’s start using the API inside our Java application. A MetricRegistry needs to be created, then the needed metrics are registered programatically.
MetricRegistry metricRegistry = new MetricRegistry(); // metrics Meter requests = metricRegistry.meter("requests"); Counter errors = metricRegistry.counter("errors"); Histogram responseTimes = metricRegistry.histogram("responseTimes"); Timer timers = metricRegistry.timer("timers");
To report the metrics via JMX, a JMXReporter needs to be triggered:
JmxReporter jmxReporter = JmxReporter.forRegistry(metricRegistry).build(); jmxReporter.start();
And that’s all. To update metric values, call the methods according to the API, e.g. errors.inc(), etc. Detailed user guide can be found here.
MBeans are automatically created and get visible in the JMX Console.
And beyond the simplicity, getting so much data out of the box is the other benefit of using such a specialized tool – e.g. in case of a timer, you directly get more than 15 different measures which might be converted to metrics, or at least being observed via the JMX Console!
Note: In order the MBeans to get visible in the JMX Console, make sure that the code for creation of the metrics and the JMXReporter has been executed at least once, e.g. in case of a servlet make sure to call it once.
Then, create a custom check based on some of those metrics. You can use the create-jmx-check command, as described in the link above. Set appropriate warning and critical thresholds
Note: MBeans ObjectNames might be built in different ways. Use the Details view in the JMX Console (the third tab on the picture above) in order to get the proper ObjectName of the MBean. This name is then used on the command line when registering the JMX check.
Metrics created in this way are first-level citizens of the monitoring service. They are shown in Cloud Cockpit along with all the others, values are kept for 2 months, plus they might be retrieved via the public REST API of the monitoring service. To get notified via email upon any warning or critical thresholds – register an alert recipient, i.e. an email address, as described here.
Adding custom metrics to Java apps in SAP CP has never been easier. Check it out and bring your observability capabilities on the next level.