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!

Read More

Yet another SAP monitoring tool?

Azure-native SAP monitoring is on the horizon! 

After 18 months of development, Microsoft is ready to announce Public Preview of our new Azure-native monitoring product for SAP workloads Azure Monitor for SAP Solutions, with lots of love for HANA customers. But why did Microsoft even bother to throw yet another monitoring tool on the market, given the abundance of SAP's own and third-party solutions?
In this first post, I want to share my perspective on why building Azure-native SAP monitoring makes sense and how Azure customers can benefit from it. 

Different tools for different purposes

Let me first address the elephant in the room and say that the intention is not to compete with SAP on monitoring, nor to "steal" customers from Solution Manager. However, I think we can agree that companies running SAP environments in the cloud are facing multiple operational challenges when relying on legacy monitoring tools that were built many years (or decades) ago under different premises.

Looking specifically at HANA as SAP's database and de-facto only technology platform for all its current major products, the following can be said as more and more customers move to the cloud:

• Complex installation
  Due to their complexity, Solution Manager and HANA Cockpit are not exactly straightforward to install and usually require advanced knowledge of the underlying stack.
• Limited access for cloud admins
  In evolving enterprise IT landscapes, there are new roles outside of the classic SAP Basis or database admin and not everyone who would benefit from SAP monitoring tools has access to them.
• Limited insights from bare-metal servers
  In addition, customers running HANA workloads on Azure's bare-metal offering (HANA Large Instances), often have to rely on SAP-native or third-party monitoring tools, since Azure - until now - provides very little infrastructure telemetry.
• Limited integration outside of SAP
  SAP's own HANA monitoring tools like Studio or Cockpit have very limited options for integration with modern ticketing systems (going broader, Solution Manager is slowly picking up this trend, though), or even just export telemetry off the SAP stack.

Hi, we are Azure Monitor for SAP Solutions

With the above challenges in mind, our goal was to build an native SAP monitoring tool, that:

• requires no expert knowledge and can be set up in 5 minutes;
• can be accessed as a first-party service in Azure Portal;
• provides valuable telemetry for SAP landscapes regardless of the underlying Azure infrastructure (VM or bare-metal);
• integrates with Azure's existing monitoring framework, allowing for easy integration with existing ITSM and dashboard tools.

In addition, we strive for maximum transparency and are building our product "in the open:" Just recently, Abhinaba Basu from our team shared details on the underlying architecture and our payload source code is publicly available on GitHub.

SAP HANA was just the beginning

I will say that building this product has been very gratifying and while our initial focus was to provide basic infrastructure monitoring for SAP HANA on Azure customers, we have already gone way beyond that. In our Public Preview release on July 15, 2020, we are offering the below telemetry "out-of-the-box"; thanks to a flexible payload framework, we will be able to easily add further content in the future and satisfy our customers' monitoring requirements.

SAP HANA Monitoring, directly in Azure! 

• SAP HANA
• Utilization
• Backup
• Replication (HSR)

• Microsoft SQL Server
  
• Current load
• Top statements/tables
• AlwaysOn

• High-availability cluster (Pacemaker)
• Overall cluster health
• Node status
• Resource status

If you have migrated (or are in the process of migrating) your SAP landscapes to the cloud, let me know which operational challenges - if any - you are facing related to monitoring! Also, what kind of scenarios would you like to see covered by our tool?

Read More