Kyma Runtime - "if (!credentials) throw new Error('No SAP Cloud Logging credentials found')"

[gopalanand333]

With telemetry plugin version 1.0.1 using the command cds add telemetry throws exception 'cds add telemetry' is not available for Kyma yet.

With the current version if i add the libraries manually

npm add @cap-js/telemetry @opentelemetry/exporter-metrics-otlp-grpc @opentelemetry/exporter-trace-otlp-grpc @grpc/grpc-js

I am getting the following error:

2024-10-03T03:59:07.345102246Z /layers/paketo-buildpacks_npm-install/launch-modules/node_modules/@cap-js/telemetry/lib/tracing/index.js:101
2024-10-03T03:59:07.345135924Z     if (!credentials) throw new Error('No SAP Cloud Logging credentials found')
2024-10-03T03:59:07.345139603Z                             ^
2024-10-03T03:59:07.345141813Z 
2024-10-03T03:59:07.345144175Z Error: No SAP Cloud Logging credentials found
2024-10-03T03:59:07.345146640Z     at _getExporter (/layers/paketo-buildpacks_npm-install/launch-modules/node_modules/@cap-js/telemetry/lib/tracing/index.js:101:29)
2024-10-03T03:59:07.345149610Z     at module.exports (/layers/paketo-buildpacks_npm-install/launch-modules/node_modules/@cap-js/telemetry/lib/tracing/index.js:136:22)
2024-10-03T03:59:07.345151976Z     at module.exports (/layers/paketo-buildpacks_npm-install/launch-modules/node_modules/@cap-js/telemetry/lib/index.js:36:26)
2024-10-03T03:59:07.345154363Z     at Object.<anonymous> (/layers/paketo-buildpacks_npm-install/launch-modules/node_modules/@cap-js/telemetry/cds-plugin.js:12:31)
2024-10-03T03:59:07.345156699Z     at Module._compile (node:internal/modules/cjs/loader:1358:14)
2024-10-03T03:59:07.345158913Z     at Module._extensions..js (node:internal/modules/cjs/loader:1416:10)
2024-10-03T03:59:07.345161340Z     at Module.load (node:internal/modules/cjs/loader:1208:32)
2024-10-03T03:59:07.345163552Z     at Module._load (node:internal/modules/cjs/loader:1024:12)
2024-10-03T03:59:07.345165575Z     at Module.require (node:internal/modules/cjs/loader:1233:19)
2024-10-03T03:59:07.345178826Z     at require (node:internal/modules/helpers:179:18)
2024-10-03T03:59:07.345180853Z 
2024-10-03T03:59:07.345183062Z Node.js v20.15.0

For the Kyma runtime, since we don't bind application to the Cloud Logging instance and CLS is configured at the cluster level, Ideally the plugin should not be looking for SAP Cloud Logging credentials

[sjvans]

hi @gopalanand333

when does this error occur? during npm add or later?

best,
sebastian

[swaldmann]

Sure, if you don't add the package via cds add the MTA/Helm charts are not augmented and you don't get the service and binding added. But that's of course expected, that's exactly what cds add was built for. The first error message is kind of self-explanatory, no? It's just not available on Kyma yet. There's a draft PR with cds-dk/pulls/3000 to add the feature.

[gopalanand333]

@sjvans

when does this error occur? during npm add or later?

I used npm add to add the plugin as cds add was returning error.
With npm add I was able to add the plugin to application and deploy to Kyma. And this error is coming in the kyma runtime.

[gopalanand333]

Sure, if you don't add the package via cds add the MTA/Helm charts are not augmented and you don't get the service and binding added. But that's of course expected, that's exactly what cds add was built for. The first error message is kind of self-explanatory, no? It's just not available on Kyma yet. There's a draft PR with cds-dk/pulls/3000 to add the feature.

@swaldmann thanks for letting me know that there's a draft PR for this.

I have been using the older version of this plugin in Kyma runtime without any problem. With the newer version I am getting this error. This is basically a feature which was working and have stopped working now.

One this note worthy is that for Kyma runtime, We bind the SAP Cloud Logging Service at the cluster level. https://github.com/SAP-samples/btp-developer-guide-cap/blob/main/documentation/observability/5-deploy-to-kyma.md
Once configured, All the applications deployed within that cluster can push their telemetry data to the same SAP Cloud Logging Instance.
Hopefully cds-dk/pulls/3000 this PR would have considered this Kyma specific approach.

[sjvans]

hi @gopalanand333

@cap-js/telemetry gets the necessary credentials via cds.env lookup. please see Service Bindings → In Kubernetes / Kyma for how to create compatible service bindings on kyma.

I have been using the older version of this plugin in Kyma runtime without any problem. With the newer version I am getting this error. This is basically a feature which was working and have stopped working now.

which version is that? please keep in mind that everything before 1.0.0 was beta.

best,
sebastian

[gopalanand333]

@sjvans

@cap-js/telemetry gets the necessary credentials via cds.env lookup. please see Service Bindings → In Kubernetes / Kyma for how to create compatible service bindings on kyma.

In this case, will it not become little complex to cross consume the service from another namespace and bind it to the CAP application. Considering people would share single CLS instance for the whole cluster, even for workload deployed to the Cloud Foundry runtime making the CLS instance as single entry point for all the observability data. We can discuss this in detail over a call maybe.

which version is that? please keep in mind that everything before 1.0.0 was beta.

Yes it was the initial release of telemetry plugin.

[a-thaler]

Hi @sjvans,

on Kubernetes you are usually running much more then just the single CAP container, think already of the html5-deployer or the approuter as just some examples even coming with the CAP helm chart already. From these containers you also want to get telemetry data and this is the focus of the Kyma telemetry module. It brings gateways to push data to, but also provides agents to collect data. This setup is already integrated with Cloud Logging via a service binding, and the CAP application can just push it's data to the OTLP gateway endpoints. So it will be an integration scenario with an OTLP-enabled backend.

The direct binding to Cloud Logging is a valid scenario for Kubernetes as well, but maybe not the recommended. Also it will require to have serviceinstances for Cloud Logging defined per namespace, which all should reference a shared instance.

What about keeping the telemetry-to-cloud-logging kind indeed specific to the direct cloud-logging binding and requires the injection of a binding, but supporting additionally a telemetry-to-otlp kind, which supports connecting to any OTLP backend taking the target URL from env variables. And for kyma/kubernetes you then have the choice.

Grüße,
Andreas

[sjvans]

We can discuss this in detail over a call maybe.

sure

... which supports connecting to any OTLP backend taking the target URL from env variables.

we can definitely look into this. which exporter would be used in this scenario which which credentials? i find setting paths to keys and certificates in files via env vars rather clumsy...

[a-thaler]

In this scenario the application will push to a cluster-local OTLP GRPC endpoint, and no credentials are required, similar to the local Jaeger setup.
The same libraries should be active as for CloudLogging, so I guess:

• @opentelemetry/exporter-metrics-otlp-grpc
• @opentelemetry/exporter-trace-otlp-grpc
• @grpc/grpc-js

People knowing the otel-sdk are aware of the harmonized env variables defined in the spec.
Of course we can have them as well defined params as well. For kyma it is important to support a differentiated configuration of the OTLP URL by providing options for

• OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
• OTEL_EXPORTER_OTLP_METRICS_ENDPOINT

[sjvans]

→ bli for credentials via env vars

as for this issue: closing as "works as designed" (i.e., credentials via cds.env)

[a-thaler]

Corrected link from Sebastian: #243