Hi Ricardo,
your reading of that page is correct, and it is worth being precise about what it says, because it is the part most people miss: SAP states that OpenTelemetry enabled Outbound APIs can be used to integrate non-SAP data consumers, and points to the SAP Cloud ALM Raw Data APIs for the details. So yes, exporting telemetry that lands in Cloud ALM towards a non-SAP backend like Instana is by design, not a hack.
Two honest expectation-setting notes before anyone starts wiring, though.
First, most of that page is actually about the opposite direction: instrumenting your own BTP applications (Cloud Foundry and Kyma, Java and Node.js) with SAP's libraries so the data flows INTO Cloud ALM for Real User, Health, Exception and Job monitoring. The outbound part is that one paragraph pointing at the Raw Data APIs, so the operational details (which signals, pull versus push, granularity, retention) have to be checked there against your tenant.
Second, remember the page also says you have to switch on monitoring per service and use case in Cloud ALM. What flows OUT can only be what you activated IN. And for SAP built SaaS the telemetry is what SAP's managed Data Collector Runtime lands in Cloud ALM, so expect service level metrics and events, not agent level internals of S/4HANA Cloud. Which, to be fair, is exactly why this bridge matters: for SaaS there is no agent alternative, this IS the visibility path.
The Instana side is the easy half, and it is fully documented. You have two entry doors for OTLP: the host agent, which receives OpenTelemetry traces, metrics and logs on 4317 (gRPC) and 4318 (HTTP), enabled by default on recent agent versions:
https://www.ibm.com/docs/en/instana-observability?topic=instana-agent
or straight to the backend acceptor, agentless, with the x-instana-key header carrying your agent key:
https://www.ibm.com/docs/en/instana-observability?topic=instana-backend
And here is the practical gotcha buried in that second page that will save you a debugging afternoon: the Instana backend requires a host.id, faas.id or device.id resource attribute on incoming OTel data. Third party exports rarely set those. Which is why the pattern I would build is Cloud ALM Raw Data API into an OpenTelemetry Collector, and the Collector into Instana: the Collector in the middle injects the required resource attributes, lets you filter and rename, and keeps the whole thing vendor neutral.
To answer your question directly: we have not wired the Cloud ALM outbound into Instana in production yet. We run Instana on the on-prem and IaaS side of SAP landscapes with the native sensors, and this export is on our lab list precisely because it is the missing piece for the SaaS side. So if you decide to try it, I would genuinely love to compare notes, and I will do the same here when we run our test.
If you share which SAP SaaS services you want to cover and whether the corresponding use cases are already active on your Cloud ALM tenant, we can get more concrete on the wiring.
Cheers
Roberto
------------------------------
Roberto Renna
------------------------------