How should security and operations teams configure OpenTelemetry to export SAP HANA metrics into a central observability backend?

Configure the SAP HANA receiver in the OpenTelemetry collector, define the exporter for the target backend, and then wire both into a metrics pipeline. The article shows this pattern for Google Cloud Ops, but the broader practice is the same: collect database telemetry at the source, route it through a standard pipeline, and keep the configuration consistent across environments.

How to Structure the OpenTelemetry Pipeline for SAP HANA Metrics

The configuration pattern is straightforward: put the SAP HANA receiver at the collection point, define the exporter for the observability backend, and connect both in a metrics pipeline. The important implementation detail is not the vendor name, but the shape of the flow, source telemetry in, standardized processing in the middle, backend export at the end.

That pipeline gives security and operations teams a consistent place to control what is collected, how often it is collected, and where it is sent. For database telemetry, that consistency matters because the same collector pattern can be repeated across environments without redesigning the instrumentation path each time.

When teams use this pattern well, they avoid embedding backend-specific logic into the database layer itself. Instead, the collector becomes the translation and routing point, which makes the telemetry path easier to operate, tune, and review.

The receiver is the source-specific ingestion layer for SAP HANA metrics.
The pipeline is the control plane for routing, filtering, and batching telemetry.
The exporter is the handoff point to the central backend, so it should be configured to match that backend’s expectations for protocol, authentication, and destination.

For teams already running multiple observability destinations, this separation also reduces drift. You can keep the SAP HANA metric collection logic stable while changing only the export target or pipeline behavior when the backend changes.

Configuration Choices That Matter in Practice

The first decision is where to terminate collection. In most production setups, the OpenTelemetry collector should sit close enough to SAP HANA to read metrics reliably, but far enough from the database to keep the database itself free of backend-specific observability work. That keeps the data path simple and makes failure isolation easier.

The second decision is how much transformation to do before export. If the backend expects a particular naming pattern, resource attribute set, or batch size, handle that in the collector pipeline rather than in multiple downstream consumers. That keeps the configuration portable and makes the observability backend easier to replace later.

The third decision is environment consistency. A strong operational pattern is to keep the receiver and pipeline structure the same across dev, test, and production, then vary only the connection details, credentials, and destination endpoint. That reduces configuration surprises and lowers the chance that metrics behave differently after promotion.

Keep the pipeline topology stable across environments.
Change destination-specific settings only where the backend requires it.
Treat collector configuration as managed infrastructure, not a one-off app setting.

Risk and Threat Considerations

Export paths for telemetry can become an operational weakness if teams treat them as plumbing rather than as a controlled data flow. Misconfiguration, overbroad access, or inconsistent collector settings can lead to missing metrics, delayed detection, or accidental exposure of backend credentials and endpoint details.

Failure mechanism: A weakly governed collector config can send metrics to the wrong backend, drop telemetry during pipeline errors, or expose sensitive connection material in files, automation, or shared configuration stores.

Impact: You lose observability fidelity when you need it most, and you may also create a secondary secrets-management problem around the exporter credentials or service access used to reach the backend.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS Control 4 — Secure Configuration of Enterprise Assets and Software	Collector pipelines and exporter settings are configuration-managed telemetry assets.
	CIS Control 8 — Audit Log Management	Central metrics export supports visibility and review of system health and failures.
Recommendation — Baseline and version-control the collector configuration, then validate each change in a controlled environment. Ensure exported telemetry is retained, searchable, and monitored for gaps or pipeline errors.
NIST CSF 2.0	PR.PT-1 — Audit/Log Records	The pipeline is the mechanism that preserves and transports operational telemetry to the backend.
	PR.AC-1 — Identity and Access Management	Exporter access to the backend depends on controlled authentication and scoped permissions.
Recommendation — Define collection and forwarding paths so operational telemetry reaches the observability platform consistently. Scope collector credentials to the minimum backend access required for metrics export.

Practitioner Guidance

What to verify: Confirm that the collector can reach SAP HANA, that the receiver is actually producing metrics, and that the exporter is accepted by the target backend before you declare the pipeline operational. A configuration that parses cleanly but does not emit usable data is a common false success.

Common mistake: Teams often validate only the exporter and ignore end-to-end metric continuity. For this use case, the real test is whether SAP HANA data appears in the backend with the expected cadence, labels, and retention path after one collector restart and one backend interruption.

What good looks like: The collector configuration is version-controlled, the pipeline is reusable across environments, and operators can change destinations or credentials without touching the SAP HANA source setup.

Practitioner takeaway: Design the collector as the stable observability boundary, because that is what lets you keep SAP HANA telemetry portable, reviewable, and resilient as backends or environments change.