Setting up monitoring for SAP HANA on Azure - but how?

The road to Hana can be a rocky one... 

Although the above picture might suggest differently, I’m not talking about the picturesque town of Hāna in Maui, Hawaiʻi, but SAP's in-memory database and de-facto technology stack. Collecting telemetry from SAP HANA is one of the primary use cases of our new product Azure Monitor for SAP Solutions, and yet, getting everything configured properly is not exactly straightforward. In this post, I want to go beyond the official documentation and de-mystify some of the intimidating parameters, hopefully saving you some time and unnecessary frustration.

First things first

As I already explained in my QuickStart video, you start by creating an empty "SAP Monitor" resource, which will serve as a container for the shared components required for monitoring, as well as the configuration to each of the source systems.

☝Pro Tip: Carefully choose the VNET you deploy the SAP Monitor resource into, as it cannot be changed later on. Particularly, make sure that all systems you want to monitor (such as your SAP HANA landscape) can be reached from within this VNET.

Once the SAP Monitor resource has been created, you can add one or more "providers" to it (providers are the connections to the systems you would like to monitor). You can do this by navigating to the SAP Monitor resource, choosing "Providers" from the table of contents on the left and clicking on "+ Add" in the top bar.

Adding a provider after the SAP Monitor resource is deployed 

☝Pro Tip: While you can already add providers when you deploy the SAP Monitor resource, I recommend you just create an empty SAP Monitor resource add the providers in a separate step - this will make later troubleshooting a lot easier.

In this example, I will use a scale-out (multi-node) HANA instance called RU1 running on HANA 2.0 SPS04 with 3+1 nodes (i.e. 3 worker, 1 standby). To keep things simple, there is no System Replication (HSR) to a secondary site configured, although this seems like a great topic for a future post.

Our HANA test landscape RU1 

Choosing the right node

As you're about to add your new SAP HANA provider, the first challenge is to pick the right node and enter it correctly: It is absolutely necessary you specify the current HANA master node, since no SQL connections can be opened against slave or standby nodes. Once the initial connection is established, it's all smooth sailing, as the provider will continuously fetch the current host configuration and update the master node, if necessary. By the way, in scale-up landscapes, the single node is always the master node.

Note that could enter either the IP address or hostname of the current master node, although the hostname may not be resolvable if you're using an external DNS server or have custom entries in your /etc/hosts or /etc/resolv.conf files.

☝Pro Tip: Want an easy way to find the IP address of the current HANA master node required for the initial connection? Just use the following SQL:

SELECT
 hi.VALUE AS IP,
 lhc.HOST 
FROM SYS.M_LANDSCAPE_HOST_CONFIGURATION lhc 
LEFT OUTER JOIN SYS.M_HOST_INFORMATION hi ON lhc.HOST=hi.HOST 
WHERE lhc.INDEXSERVER_ACTUAL_ROLE = 'MASTER' 
AND hi.KEY = 'net_publicname' 
ORDER BY HOST_ACTIVE DESC,
 INDEXSERVER_ACTUAL_ROLE ASC

Determining the current HANA master node and its IP address in RU1 

Choosing the right database and port

SAP introduced multi-tenant database containers (MDC) in HANA back in 2016 with HANA 1.0 SPS09, so it's safe to say that most HANA installations nowadays are MDC. This means there will be multiple isolated databases running within the same HANA instance:

• the SYSTEMDB database;
• the tenant database whose name is identical to the HANA SID;
• (optional) additional databases created by the user (rather uncommon for HANA instances running in a public cloud like Azure).

As some of our telemetry (such as backup or replication) relies on system-wide monitoring tables, I strongly recommend to connect your SAP HANA provider against the SYSTEMDB database of your instance. (Side note: As we keep adding database-specific monitoring content, you can always add more providers to your tenant and/or other databases in the future.)

So now, what's the SQL port you should pick to establish the connection? As a rule of thumb:

• in (current) MDC installations, SYSTEMDB can be accessed via SQL port 3xx13; 
• in (legacy) non-MDC installations, the single database can be accessed via SQL port 3xx15.

☝Pro Tip: When adding a SAP HANA provider to connect your MDC instance, use database SYSTEMDB with SQL port 3xx13 (replacing xx with your 2-digit instance number).

Checking available databases in RU1 

Choosing the right credentials

While it may be tempting to just (ab-)use the database's SYSTEM user and be done with it, this should be a big no-no for any deployment besides a quick test. We strongly recommend creating a dedicated (technical) user for Azure Monitor for SAP Solutions and assign the pre-defined MONITORING and CATALOG READ roles to it, like so:

CREATE USER AZURE_MONITORING PASSWORD "Welcome123!" NO FORCE_FIRST_PASSWORD_CHANGE;

GRANT MONITORING TO AZURE_MONITORING; 

GRANT CATALOG READ TO AZURE_MONITORING;  

As far as entering the credentials is concerned, we built a nifty feature that allows you to reference an existing KeyVault secret (or create a new one) instead of entering the password directly. Not only does this increase security, but it also allows for easier maintenance and rotation of your passwords.

Storing the password of the monitoring user in a separate Azure KeyVault 

Putting it all together

Now that we've discussed some of the caveats, below is a handy cheat sheet of how to set up SAP HANA providers the right way in Azure Monitor for SAP Solutions:

Field	Input
IP address	<IP address of current HANA master node>
Database tenant	SYSTEMDB
SQL port	3xx13
Database username	<Technical HANA user with MONITORING and CATALOG READ roles, e.g. AZURE_MONITORING>
Provide the database password by	select "selecting an existing or creating a new secret inside an Azure KeyVault (more secure)"
Secret URI for database password	click on "Select existing secret or create new"

Making sure everything works

Don't despair if adding your new provider fails the first time; a quick look at the last few lines of the activity log usually reveals the culprit right away:

Looks like I mis-typed the password... 

Once you managed to add your new SAP HANA provider and its status shows "Succeeded," you should see data come in after a few minutes - just wait for the new HANA SID to appear on the top of the "SAP HANA" workbook.

Hooray, it worked - we can see our HANA instance RU1! 

Hopefully this deep dive was helpful - let me know if you still have trouble connecting your SAP HANA landscapes to our monitoring service!