Skip to Content
Technical Articles
Author's profile photo Florian Wilhelm

Step 17 with SAP Cloud SDK: Monitoring

Disclaimer: This blog post is only applicable for the SAP Cloud SDK version of at most 2.19.2. We plan to continuously migrate these blog posts into our List of Tutorials. Feel free to check out our updated Tutorials on the SAP Cloud SDK.

The following steps will explain how to monitor your application using the SAP Cloud SDK. If you want to follow this tutorial, we highly recommend checking out the previous parts of this series.

Note: This post is part of a series. For a complete overview visit the SAP Cloud SDK Overview.

Note: This post only applies to SAP Cloud Platform Neo, not to SAP Cloud Platform Cloud Foundry.

Goal of this blog post

This blog post covers the following steps:

  1. Introduction to the concept of monitoring
  2. Basics of monitoring within SAP Cloud SDK
  3. Add monitoring capabilities to your own application

Introduction to monitoring

Knowing what happens in your application is important, because it can be useful when you run into problems. In the best case, you can avoid that if you always have an idea about how your application is doing. But how can you know? The answer is monitoring.

Most computer users are familiar with some simple forms of monitoring, for example the Windows Task Manager is a basic tool to find out about resource usage of applications on your computer. You might open it, if your computer feels slow or does not behave as you expect it. It is easy to see when an application uses loads of memory or computation time.

In today’s world of computing, the line between development and operations blurs. Developers interact directly with cloud platforms such as SAP Cloud Platform. This is where the concept of DevOps comes into play. Development and operations merge into one. Monitoring your applications is critical in this environment, and is not only interesting for system administrators, but also for software developers.

There is little benefit in “optimizing” certain aspects of an application when you don’t know where your bottlenecks are. Will your application benefit from parallelizing computations? If you have 100% load on one single CPU core, but almost none on the others you might benefit from parallel execution. Another potential bottleneck might be many calls to an external system, for example SAP S/4HANA. Introducing a local cache might improve the performance of your application dramatically in this case.

Monitoring in SAP Cloud SDK

Java Management Extensions (JMX) is the Java specification for monitoring capabilities. JMX defines managed beans (MBeans for short). MBeans are Java objects which expose some metrics (such as memory usage for example) and implement some functionality (such as flushing the cache). The SAP Cloud SDK implements this specification to provide you with insights about your application.

To get started with monitoring, go to the SAP Cloud Platform Cockpit, click the Monitoring menu item and then JMX Console. The JMX Console allows you to inspect the MBeans of your application. There is some SAP specific MBeans, which can be easily identified by the com.sap prefix. For each MBean, there are attributes and operations. An attribute has a name and a value. Operations may take parameters and can be executed. The result of an executed operation is displayed in the bottom part of the JMX Console.

Here is an example screenshot of the JMX Console. On the left side, you can see a tree view of the MBeans, ordered by the package name. On the right side, you can inspect the attributes of the currently selected bean.

This is how operations are presented in the JMX Console. You can execute them by pressing ▶️. For operations that require parameters, you should fill them before executing.

Let’s discuss some of the attributes and operations that are provided by the SAP Cloud SDK:

MBean com.sap.cloud.sdk.cloudplatform.cache.CacheMonitor

Tip: If you are interested in caching, please make sure you read step 6 of this series.

The cache monitor sums up information on the caches in your application. It also allows you to invalidate the caches. This should not be necessary in a normal operation mode, but it might come in handy in development or if you’re debugging a problem.

MBean com.sap.cloud.sdk.cloudplatform.monitoring.ExceptionMonitor

The exception monitor aggregates thrown exceptions by timeframe. The operations allow you to dump exceptions to a file for further investigation.

MBean com.sap.cloud.sdk.s4hana.connectivity.ErpEndpointMonitor

Counts all queries, and additionally long running queries to the SAP S/4HANA system. If you have lots of long running queries, you’ll likely benefit from using a cache as discussed in step 6 of this series.

Implement your own monitoring metrics and operations

You can add your own metrics and operations to your application. For example, let’s assume in your application, you manage authentication requests to a system. You might want to know about the failed attempts, but you probably also want to be able to clear the failed requests by a certain user.

We’ll write an AuthenticationMonitor for that purpose. First, you need to create an interface which follows the MXBean naming convention. It can contain methods that follow the getter/setter name convention. Those will become attributes. It can also contain other methods, that can optionally have parameters. Those methods will become operations. We’ll have one example for each. The clearLogOfFailedAuthenticationRequestsByUser method will become an operation, and getNumberOfFailedAuthenticationRequests will become an attribute.

public interface AuthenticationMonitorMXBean {
    String clearLogOfFailedAuthenticationRequestsByUser(String name);
    int getNumberOfFailedAuthenticationRequests();
}

Now, create a class which implements that interface. In this sample, we delegated the actual processing to a utility class. You also need to make your class inherit from the JmxMonitor class which is provided by the SAP Cloud SDK. This class brings the contextInitialized and contextDestroyed methods, which have to be overridden. For now, we don’t need to do more than to register and unregister our bean instance here.

@WebListener
public class AuthenticationMonitor extends JmxMonitor implements AuthenticationMonitorMXBean {

    private static final AuthenticationMonitor instance = new AuthenticationMonitor();

    @Override
    public String clearLogOfFailedAuthenticationRequestsByUser(String name) {
        Auth.clearLogOfFailedAuthenticationRequestsByUser(name);
        return "Clear failed login attempts by " + name;
    }

    @Override
    public int getNumberOfFailedAuthenticationRequests() {
        return Auth.getNumberOfFailedAuthenticationRequests();
    }

    @Override
    public void contextInitialized(final ServletContextEvent servletContextEvent) {
        instance.registerJmxBean();
    }

    @Override
    public void contextDestroyed(final ServletContextEvent servletContextEvent) {
        instance.unregisterJmxBean();
    }
}

You don’t have to return a String in the operation, but it is useful to do so because this will be shown in the JMX Console once your operation is executed.

Once you added the monitor to your application and re-deployed it to the cloud platform, you can revisit the JXM Console. Drill down to your package name, and you’ll see the results of your work.

The attribute we have defined is there:

Our operation also made it into the JMX Console and can be executed. As you can see, the String we returned is used to indicate the result of the operation.

Wrap up

In this blog post, we introduced the concept of monitoring and how SAP Cloud SDK uses it to provide you with insights about your application. Also, we explored how you can add your own monitoring capabilities to your application.

Questions and Troubleshooting

Are you facing a development question? Then check out Stack Overflow, the main place for SAP Cloud SDK related questions. If you do not find an answer, feel free to post your question and make sure to attach the tag ‘s4sdk’. Our team, as well as the whole Stack Overflow community, are at your service and will quickly react to your question.
For an overview of SAP Cloud SDK related questions, go to https://stackoverflow.com/questions/tagged/s4sdk.
You think that you found a bug in one of our Continuous Delivery artifacts? Feel free to open an issue in our Pipeline GitHub repository on https://github.com/SAP/cloud-s4-sdk-pipeline/issues.

Happy monitoring!

See the next tutorial in the series here: Step 18 with SAP Cloud SDK: Your Multi-Tenant Application in SAP Fiori Launchpad on SAP Cloud Platform Cloud Foundry

Assigned Tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hello Florian,

      Thanks for posting the blog. I was going through the steps. Can you please tell me which package to import for JmxMonitor and ServletContextEvent ?

      Thanks,

      Sankeerth

      Author's profile photo Former Member
      Former Member

      Also, What is the "Auth" in the line

      return Auth.getNumberOfFailedAuthenticationRequests();

       

       

      Author's profile photo Florian Wilhelm
      Florian Wilhelm
      Blog Post Author

      Hello Sankeerth,

      Thanks for your feedback.

      The fully qualified class names are:

      com.sap.cloud.sdk.cloudplatform.monitoring.JmxMonitor
      javax.servlet.ServletContextEvent

      "Auth" is just a placeholder for your code which implements whatever you're monitoring. I wanted to make the example code more realistic then just returning a constant value. In my example code, "Auth" was just a class with the static method getNumberOfFailedAuthenticationRequests.

      I hope this helps.

      Best regards,
      Florian