Monitoring multi-tenant HANA without breaking SYSTEMDB isolation

A multitenant HANA setup keeps one SYSTEMDB and one or more tenant databases on the same instance. The host filesystem layout and the trace directories are shared, but the data and the operational concerns are separate. Monitoring tools that treat the trace directory as a flat collection of files tend to either lose the tenant distinction or ship more than they should.

The four design decisions below are the ones that determine whether a HANA-aware monitoring tool will work for you across SYSTEMDB and tenants.

1. Classify trace files by scope

Trace files for the SYSTEMDB live in the root of the trace directory. Trace files for a tenant database live under a DB_<TENANT> subdirectory of the same path. A monitoring agent that walks the trace directory needs to assign each file to a scope: SYSTEMDB, a named tenant, or shared.

The classifier needs the HANA SID as input because a HANA system named, for example, HBD can also have a folder named DB_HBD at the top of the trace directory. That folder belongs to the SYSTEMDB, not to a tenant called HBD. A classifier that does not know the system SID can misclassify it.

2. Discover tenants rather than configuring them

Tenant names change over the life of a HANA system. Tenants are added, dropped, renamed. An agent that reads the directory structure at each poll and reports the discovered set is easier to operate than one that requires an updated configuration file each time the landscape changes.

The same discovery also gives the operator a useful UI surface: the list of tenants currently visible on each system, sourced from the host itself.

3. Scope-aware allowlists

HANA trace files rotate often and most of their content is not interesting to ship to a monitoring platform. The allowlist that controls what gets shipped should carry scope, not just filename pattern. An entry like backup.log without a scope picks up both the SYSTEMDB backup log and every tenant backup log. An entry that knows whether the operator asked for the SYSTEMDB log or a specific tenant's log keeps the data flow scoped to what was requested.

4. Per-tenant audit boundaries

Even when a single agent collects across SYSTEMDB and tenants, the platform should treat the data as scoped. Permissions, alert routing and audit records should reference the scope of the data, not only the HANA SID. This is what makes "show me Tenant A's backup log" a different operation from "show me SYSTEMDB's backup log" at the access-control layer.

The end-to-end data flow

For one HANA host the flow looks like this:

1. Agent reads its configuration, which includes the HANA SID and a scope-aware allowlist.
2. Discovery pass walks the trace directory, classifies subdirectories as SYSTEMDB or tenant, reports the tenant list to the platform on the next heartbeat.
3. Tail loop monitors files that match the allowlist for the scope the operator selected.
4. Each line shipped to the platform carries the scope of its source.
5. The UI shows the operator only the scopes their role permits.

Common pitfalls

• Treating nameserver_*.trc as the primary signal. The interesting content is more often in indexserver_*.trc, compileserver_*.trc, preprocessor_*.trc, xsengine_*.trc and backup.log. A complete catalogue covers all of them.
• Hard-coding the instance number HDB00. Real landscapes can have HDB00, HDB10, HDB20 on the same host. The agent should walk for any HDB instance directory.
• Missing trace-file rotation. If you tail a file and miss the rotation to the next sequence number, you lose data. The agent should re-glob after each rotation.
• Confusing the SYSTEMDB and tenant backup.log paths. SYSTEMDB lives at trace/backup.log; tenants live at trace/DB_<TENANT>/backup.log. Treating both as one path 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 can select what to monitor for each scope independently. Permissions and audit records carry the scope alongside the SAP SID. More on how the platform handles credentials and access.

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.

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