Monitoring multi-tenant HANA without breaking SYSTEMDB isolation

A multitenant (MDC) HANA setup keeps one SYSTEMDB and one or more tenant databases on the same instance. The host filesystem and the trace directories are shared; the data, the SQL surface and the operational concerns are separate. Monitoring that treats the trace directory as a flat pile of files, or that queries a tenant as if it were the whole system, either loses the tenant distinction or leaks across it. Four decisions determine whether a HANA-aware tool works across SYSTEMDB and tenants.

Where the scopes actually live

From SYSTEMDB you enumerate the databases; the tenant list is on the host, not in a config file. Connect to SYSTEMDB (SQL port 3<inst>13) and read it:

-- Connect to SYSTEMDB, then discover tenants (never hard-code them)
hdbsql -n <host>:3<inst>13 -d SYSTEMDB -u SYSTEM -p ***

SELECT DATABASE_NAME, ACTIVE_STATUS, RESTART_MODE
FROM   M_DATABASES;                       -- SYSTEMDB + every tenant

-- Read a metric across ALL tenants from SYSTEMDB, no per-tenant logon:
SELECT DATABASE_NAME, HOST, SERVICE_NAME,
       ROUND(TOTAL_MEMORY_USED_SIZE/1024/1024/1024,1) AS used_gb
FROM   SYS_DATABASES.M_SERVICE_MEMORY
ORDER  BY used_gb DESC;

The SYS_DATABASES.<VIEW> schema is the cross-tenant window: from SYSTEMDB you can read each tenant's M_* views without a separate connection, which is how you build one operational view while every query is still scoped to a named database.

1. Classify trace files by scope

SYSTEMDB trace files live in the root of the trace directory; a tenant's live under a DB_<TENANT> subdirectory of the same path.

The classifier needs the HANA SID as input: a system named HDB can also have a top-level DB_HDB folder that belongs to the SYSTEMDB, not to a tenant called HDB. A classifier that does not know the SID misfiles it, and every downstream permission and audit record inherits the wrong scope.

2. Discover tenants, don't configure them

Tenant names change over a system's life, being added, dropped and renamed. Prefer an agent that reads M_DATABASES (or walks the DB_* folders) at each poll and reports the discovered set, over one that needs an edited config file every time the landscape moves. The same discovery is a useful UI surface: the tenants currently visible on each system, sourced from the host itself.

3. Scope-aware allowlists

HANA trace files rotate constantly and most content is not worth shipping. The allowlist that controls what leaves the host must carry scope, not just a filename pattern. An entry like backup.log with no scope matches both the SYSTEMDB backup log and every tenant's; an entry that knows the operator asked for SYSTEMDB, or for tenant HDT specifically, keeps the flow to exactly what was requested.

# Scope-prefixed allowlist entries: the scope is part of the key
SYSTEMDB:backup.log
SYSTEMDB:indexserver_*.trc
DB_HDT:backup.log
DB_HDT:indexserver_alert_*.trc
# Rotation-safe: re-glob after each rotation so the *_<seq>.trc roll is
# not silently dropped between polls.

4. Per-tenant audit boundaries

Even when a single agent collects across SYSTEMDB and tenants, the platform must treat the data as scoped. Permissions, alert routing and audit records reference the scope rather than only the HANA SID, which is what makes "show me tenant HDT's backup log" a genuinely different operation from "show me SYSTEMDB's backup log" at the access-control layer, not just a different filter in the UI.

Common pitfalls

• Treating nameserver_*.trc as the primary signal. The interesting content is usually in indexserver_*.trc, compileserver_*.trc, preprocessor_*.trc, xsengine_*.trc and backup.log. Catalogue all of them.
• Hard-coding instance HDB00. Real hosts run HDB00, HDB10, HDB20 side by side; walk for any HDB<nr> directory.
• Querying a tenant for a system-wide answer. Some views only make sense from SYSTEMDB (or via SYS_DATABASES); a tenant sees only itself.
• Confusing the SYSTEMDB and tenant backup.log. SYSTEMDB is trace/backup.log; a tenant is trace/DB_<TENANT>/backup.log. One path for both loses the tenant view.

How Farrenio handles it

The collector agent performs dynamic tenant discovery, scope-aware classification, and scope-prefixed allowlists. The UI exposes SYSTEMDB and tenant chips per system so operators pick what to monitor per scope independently, and permissions and audit records carry the scope alongside the SAP SID. More on how the platform handles credentials and access, and the wider signal set is in the HANA performance monitoring guide.

What to ask a HANA monitoring vendor

1. How is a SYSTEMDB folder named after the HANA SID classified?
2. How are tenants discovered, and what happens when one is renamed?
3. How does an audit record reflect the tenant scope of the data an operator viewed?
4. What permission separates viewing one tenant from viewing another?
5. What does the default allowlist look like, and how does scope work in it?

To see this against a multi-tenant HANA setup, write to contact@farrenio.com and we can scope a short trial together.