Monitoring Cloud Foundry in SAP Business Technology Platform (BTP)

Cloud Foundry is possibly the most popular environment on SAP Business Technology Platform. When customers build applications with the SAP Cloud Application Programming (CAP) framework to extend SAP S/4HANA solutions and achieve a clean core, they typically deploy using Cloud Foundry.

After the applications on Cloud Foundry go into productive use, they become business critical and that creates a need for observability in those applications and the platform.  Monitoring of Cloud Foundry is now an essential requirement of SAP operations teams.

What is Cloud Foundry and what is it for? 

Cloud Foundry is an open-source cloud app platform that makes it easier to run apps written in any language on any private or public cloud. Normally, an administrator would install and configure Cloud Foundry, but SAP BTP provides their Cloud Foundry environment ready configured and ready-to-go for customers to deploy their applications.

The ability to run applications written in any language is provided by a combination of stacks and buildpacks. Stacks contain the key parts of an operating system, and buildpacks provide all the supporting requirements for an application. For example, a Java application could be deployed with the cflinuxfs4 stack, providing the Ubuntu 22.04 Jammy Jellyfish distribution of Linux, using a Java buildpack that provides the JVM and other dependencies to run Java applications.

Cloud Foundry aims to provide a fast, secure and innovative cloud platform with a good developer experience. It saves time and cost of manual configuration and maintenance of the infrastructure to run applications, to allow developers to focus on making their applications, whilst the platform handles tricky topics like scaling. It’s no surprise that SAP have chosen to make Cloud Foundry available as one of the environments in BTP.

What do I need to monitor in Cloud Foundry? 

Cloud Foundry abstracts a lot of the infrastructure problems that observability typically starts with, but that doesn’t mean that nothing goes wrong or that you don’t need to monitor it.  There are a number of key areas to consider monitoring for successful Cloud Foundry operations.

Quotas

Quotas are a major topic in Cloud Foundry administration. You can set quotas on CPU, memory, routes, processes and services, and apply them to an entire Cloud Foundry  organisation, or to a space within an organisation.

Quotas are good, and in fact essential to ensure applications have the resources they need whilst costs are controlled. However they are also brutal and will stop an application from starting, or restarting after maintenance, if doing so would exceed one of the configured quota limits. Downtime can be caused and prevented by quotas, and both happen often.

Monitoring CPU and memory may not be required at the infrastructure level anymore, but it’s still an essential part of observability in Cloud Foundry. As well as avoiding running out of quota, regular tracking of quota usage is an important part of optimising and right-sizing your Cloud Foundry environment for future growth, minimum cost and carbon footprint.

Runtime problems and availability

Cloud Foundry is so many levels of abstraction away from the bare metal that typical computer problems might seem impossible, but the reality is that Cloud Foundry applications are ordinary code running in ordinary processes on ordinary operating systems behind all the layers of cloudy abstraction.

Applications throw exceptions and sometimes entire processes crash.  Sometimes the application seems fine but it simply isn’t available or doing what it’s supposed to do.  Monitoring for process crashes, logged exceptions and basic availability is a totally fundamental feature of any Cloud Foundry observability solution.

Since applications in any language can run on Cloud Foundry, the logging capability provides very generic reports of problems, and further interpretation with knowledge of the specific language is needed to understand and resolve them.  If an observability platform can do that interpretation for you, operations teams can solve problems more quickly.

Scalability and resources

Cloud Foundry has memory and CPU usage limits for process instances, and allows automatic or manual scaling of process instances to handle varying demand. Monitoring for usage nearing limits and actively increasing and decreasing the configured limits is essential for well-performing applications at minimum costs.

One area where Cloud Foundry allows some leniency to an application is in bursting CPU usage beyond a set CPU entitlement, known as spiking. In time, Cloud Foundry will begin to identify “bad” applications that use too much CPU consistently and throttle those applications. Throttling also occurs when available CPU is insufficient for all applications.  Monitoring the time applications spend over their CPU entitlement is essential to ensure they do not get throttled and perform well for users.  

Deployment and build issues

Deploying or updating an application on Cloud Foundry is often done with a single command, but that triggers a complex process involving many steps. From the point the developer runs cf push on her command line: first an app is created, then files updated to storage to build, and the app is staged, a droplet is created and stored, and finally the application can be started and checked for a running state. 

At each point, things can go wrong. The Cloud Foundry platform reports the status of droplets, builds and applications in staging and running states. These are all vital points to monitor as any problems could mean the app is in a different state from how the developer expected. In the worst case, an application could be totally unavailable to users after problems with starting, stopping, building or staging.

Technical security

SAP cloud products in general, and SAP BTP specifically, brings SAP operations teams outside of the corporate firewall, often for the first time. SAP applications always ran inside a well-protected part of the corporate network, but cloud applications are on the public internet with zero-trust security by default.

Cloud Foundry offers Security Groups to configure allowable network access for applications, and these must be configured in line with general best practices (allow access to DNS, block access to cloud management services) and organisation-specific policies and configuration. Monitoring for configuration problems ensures applications can talk when they are supposed to, and not when they are not supposed to.

Checking the security audit logs has never really been optional but it’s definitely mandatory in any public cloud setting, and deviation from baseline or potential threat should be investigated. It could be an innocent failure like a poorly configured integrating system that is causing a business disruption in itself, or it could be an attacker.

Compliance

Compliance is a slightly different sort of security, considering topics like implementation audit controls and segregation of duty. Cloud Foundry has roles for administrator and developer users, and it’s just as important to check those are set correctly as checking the authorisations in a production S/4HANA system.

Sadly, many Cloud Foundry deployments are a wild west today. As relatively new technology in the SAP world, applications are built on Cloud Foundry as an innovation proof-of-concept or as part of a challenging S/4HANA implementation project. In both cases, time and skills are stretched and getting it working is a higher priority than configuring everything for compliance.

Auditors are catching up now, and the common practice of deploying from a developer’s laptop to the production environments in BTP will not be possible in enterprise companies for much longer. Correct configuration of CI/CD provides a SAP transport-esque route to live for applications, and so checking for Cloud Foundry user authorisations to make sure nobody can develop applications and deploy them to production becomes an essential monitoring check.

So, how do I monitor everything in Cloud Foundry? 

Naturally, this Avantra blog is going to recommend the Cloud Foundry monitoring capability released in Avantra 25.

Avantra 25 provides totally automatic discovery of all directories and subaccounts, environment and services in a SAP BTP Global Account after being given a single API key in a single subaccount. The detection and setup is totally automatic with the absolute minimum of administrator effort.

When a Cloud Foundry environment is found, all spaces and applications are detected and monitoring checks for everything listed in this blog are configured automatically, including over twenty standard checks and five custom checks for every application and environment.

Avantra is the leading observability platform for SAP operations teams, providing totally automated and user-friendly visibility of SAP landscapes to our customers for over twenty years. Expanding into coverage of essential BTP services like Cloud Foundry brings the possibility to observe and operate modern SAP business processes in the cloud in a single, integrated platform.

Talk with one of our SAP experts today to find out more.