SAP HANA Integration

Connect to the database you want to monitor and create a restricted user:

1CREATE RESTRICTED USER otel_monitoring_user PASSWORD "<PASSWORD>" NO FORCE_FIRST_PASSWORD_CHANGE;

Here,

• NO FORCE_FIRST_PASSWORD_CHANGE is required. By default SAP HANA forces a password change on first login. An unattended agent cannot perform that change, so without this clause every connection attempt fails.
• A restricted user is used deliberately: it has no data-access privileges of its own and receives only the read permissions granted in Step 3.

Keep the double quotes around the password. An unquoted password is converted to upper case by SAP HANA, which will not match what you configure in the agent.

A restricted user can only connect over HTTP/HTTPS until client connect is enabled. Grant SQL connectivity:

1ALTER USER otel_monitoring_user ENABLE CLIENT CONNECT;
2GRANT RESTRICTED_USER_JDBC_ACCESS TO otel_monitoring_user;

Here,

• ENABLE CLIENT CONNECT allows the user to open a SQL connection at all.
• RESTRICTED_USER_JDBC_ACCESS is what the agent needs. This was confirmed against a SAP HANA 2 tenant: with this role alone, the agent authenticated and collected metrics.

If your organisation's policy also expects the ODBC access role, granting it as well is harmless for a read-only monitoring user:

1GRANT RESTRICTED_USER_ODBC_ACCESS TO otel_monitoring_user;

You can copy these commands directly from the Configuration tab of the SAP HANA integration in Middleware:

Create a role with read access to the monitoring views the integration queries, then assign it to the user:

1CREATE ROLE OTEL_MONITORING;
2GRANT CATALOG READ TO OTEL_MONITORING;
3GRANT SELECT ON SYS.M_BACKUP_CATALOG TO OTEL_MONITORING;
4GRANT SELECT ON SYS.M_BLOCKED_TRANSACTIONS TO OTEL_MONITORING;
5GRANT SELECT ON SYS.M_CONNECTIONS TO OTEL_MONITORING;
6GRANT SELECT ON SYS.M_CS_ALL_COLUMNS TO OTEL_MONITORING;
7GRANT SELECT ON SYS.M_CS_TABLES TO OTEL_MONITORING;
8GRANT SELECT ON SYS.M_DATABASE TO OTEL_MONITORING;
9GRANT SELECT ON SYS.M_DISKS TO OTEL_MONITORING;
10GRANT SELECT ON SYS.M_HOST_RESOURCE_UTILIZATION TO OTEL_MONITORING;
11GRANT SELECT ON SYS.M_LICENSES TO OTEL_MONITORING;
12GRANT SELECT ON SYS.M_RS_TABLES TO OTEL_MONITORING;
13GRANT SELECT ON SYS.M_SERVICE_COMPONENT_MEMORY TO OTEL_MONITORING;
14GRANT SELECT ON SYS.M_SERVICE_MEMORY TO OTEL_MONITORING;
15GRANT SELECT ON SYS.M_SERVICE_REPLICATION TO OTEL_MONITORING;
16GRANT SELECT ON SYS.M_SERVICE_STATISTICS TO OTEL_MONITORING;
17GRANT SELECT ON SYS.M_SERVICE_THREADS TO OTEL_MONITORING;
18GRANT SELECT ON SYS.M_SERVICES TO OTEL_MONITORING;
19GRANT SELECT ON SYS.M_VOLUME_IO_TOTAL_STATISTICS TO OTEL_MONITORING;
20GRANT SELECT ON SYS.M_WORKLOAD TO OTEL_MONITORING;
21GRANT SELECT ON _SYS_STATISTICS.STATISTICS_CURRENT_ALERTS TO OTEL_MONITORING;
22GRANT OTEL_MONITORING TO otel_monitoring_user;

Here,

• Each GRANT SELECT corresponds to a monitoring view the integration reads. Grant all of them — removing one silently drops the metrics sourced from that view.
• CATALOG READ allows the user to read system catalog metadata.
• These are read-only permissions on system views. No permission to read application data is granted.

The agent connects to one specific database per configured endpoint, selected entirely by port — there is no database-name setting. You therefore need the SQL port of each database you want to monitor.

Query the ports rather than assuming them. Connect to SYSTEMDB as an existing administrator-level user and run:

1SELECT DATABASE_NAME, SERVICE_NAME, SQL_PORT FROM SYS_DATABASES.M_SERVICES WHERE SQL_PORT > 0;

Here,

• Run this once, and only from SYSTEMDB. The SYS_DATABASES schema is a cross-database catalog that exists only on a SYSTEMDB connection; running it against a tenant fails with an object-not-found error.
• Do not run this as otel_monitoring_user. That user is created per tenant and cannot query SYS_DATABASES from any connection.
• Each tenant's SQL port is the one reported for its indexserver. Note the port of each database you want to monitor and use it in the next step.

Point the agent at each tenant's own port. The agent reads only the plain SYS.* views of whichever database it connects to, so an endpoint aimed at SYSTEMDB collects the nameserver's own near-empty metrics rather than your tenant's workload. It connects and reports success either way, which makes this easy to miss.

The tenant port is also the only option. Interactive clients such as hdbsql can connect to the SYSTEMDB entry port and name a tenant to be redirected to it; the agent cannot, because it builds a bare connection string with no database-name parameter. Connect to each tenant's port directly.

In Middleware, go to Installations → All Integrations, filter by the Database category, and select SAP HANA.

On the Installation tab, select the host where the agent runs, then complete the form:

• Collection Interval: how often metrics are scraped. Defaults to 10s.
• SAP HANA Instances — one row per database you want to monitor:
  • Name: a label for this instance (for example db-instance).
  • Endpoint URL: host:port of the database, using the port identified in Step 4 (for example hana01.acme.local:30015).
  • Username: the monitoring user from Step 1 (otel_monitoring_user).
  • Password: that user's password, entered without the surrounding double quotes used in the SQL statement.
• Enable TLS (optional): turn this on to connect over TLS and supply the certificate details.

Use Add Endpoint to monitor more than one database or tenant. Each endpoint is collected independently, so a multitenant system needs one row per tenant.

Click Save Configuration. Once saved, the agent begins collecting metrics on its next scrape.