Telemetry
Seeing what a running service did — traces across handlers and database calls, metrics, and correlation that survives an async boundary.
Overview
In CAP telemetry is OpenTelemetry: spans around service and database calls, metrics beside them, and a correlation id that lets one request be followed across the services it touches. Which runtime the service is on decides how the signals arrive and what the application has to write to add one of its own.
@cap-js/telemetry Automatic OpenTelemetry instrumentation for CAP Node.js services and their database calls, exported as traces and metrics to the console, SAP Cloud Logging, Dynatrace, Jaeger or an OTLP endpoint.
com.sap.cds:cds-services-bom CAP instrumentation for OpenTelemetry, traces and metrics through the Java agent and extension library, for SAP Cloud Logging or Dynatrace.
Not covered: It stops at the server. Traces begin when a request arrives, so frontend performance and client-side errors, the half the user actually experiences, are outside what the runtime can see. Two more edges sit inside the server: on Node.js database tracing reaches @cap-js/cds-dbs databases and not other drivers, and on Java the CAP-specific instrumentation creates no spans at all until the matching logger is raised, even with the agent attached.
@cap-js-community/business-metrics@cap-js-community/business-metricsAn extension of @cap-js/telemetry that turns two CDS annotations into business metrics, a counter on an entity event or action and a gauge on numeric fields.community org, cap turns CDS annotations into counter and gauge metrics, so a business count does not have to be written as OpenTelemetry API calls. cap-ui-telemetrycap-ui-telemetryUI5 frontend performance (FESR) and client error capture for CAP, written as cds.log records and forwarded to SAP Cloud Logging, rather than as OpenTelemetry spans.independent, cap takes the browser side the runtime cannot see, reading UI5's FESR headers and accepting batches of client errors, and writes them as cds.log records. cap-mcp-guardcap-mcp-guardA CDS plugin — the trust layer for AI agents accessing SAP CAP business data — request interception, policy enforcement, field masking/pseudonymization, and OpenTelemetry-native observability for MCP-enabled applications.independent, cap adds a span per agent request against the application's own OpenTelemetry SDK, and @sanjay-sde/cap-js-log-control@sanjay-sde/cap-js-log-controlA CAP plugin for controlling CDS logger verbosity and OpenTelemetry DiagLogger noise, reducing log clutter so that real errors surface.independent, cap lowers the diagnostic logging the OTLP exporters produce so real errors stay visible.
In ABAP telemetry is exported from the system to a tool outside it: metrics exposed for Prometheus to scrape, or traces, metrics and logs serialised as OTLP and posted to a backend such as Elastic.
SAP Cloud ALM health monitoring collects technical metrics from ABAP systems on a regular basis, among them work process usage, response time and ABAP runtime errors, and calculates the health of the monitored system from them.
Not covered: At SAP Cloud ALM. The metrics are the ones SAP defines and they are read in SAP's tool; exposing them to Prometheus, or sending traces and logs as OpenTelemetry to another backend, is written on top.
The core side is SAP Cloud ALMSAP Cloud ALMSAP's application lifecycle management product, run by SAP as a service: implementation projects with their tasks, requirements, features, documents and test management, and the operations side of a landscape. For the things here it is the system a server reads over the published Cloud ALM APIs, on behalf of an agent.. The community and independent tools expose metrics to Prometheus, send OpenTelemetry data to a backend, or record the usage and response times of an abap2UI5abap2UI5One ABAP class implementing z2ui5_if_app is the whole app: the browser loads a generic UI5 shell once, and every interaction after that is an HTTP roundtrip back into ABAP.community org, abap installation.
On BTP telemetry is where an instrumented application's data goes: SAP Cloud ALM for operations shows its health and exceptions, and SAP Cloud Logging keeps its logs, metrics and traces for analysis.
SAP Cloud ALM for operations monitors a custom application on Cloud Foundry or Kyma once it is instrumented with SAP's OpenTelemetry-based Data Collection Instrumentation Libraries, and SAP Cloud Logging stores and analyses its logs, metrics and traces.
Not covered: At what the application emits. Both services receive telemetry; what is traced inside the application is the runtime's side, which on CAP is @cap-js/telemetry@cap-js/telemetryAutomatic OpenTelemetry instrumentation for CAP Node.js services and their database calls, exported as traces and metrics to the console, SAP Cloud Logging, Dynatrace, Jaeger or an OTLP endpoint.sap official, cap.
Independent command lines read back what SAP Cloud LoggingSAP Cloud LoggingAn instance-based observability service built on OpenSearch that stores and analyses logs, metrics and traces from Cloud Foundry, Kyma, Kubernetes and other runtime environments.sap official, btp has already ingested: @saptools/cf-otel@saptools/cf-otelA read-only command line that queries the OpenTelemetry trace spans SAP Cloud Logging has already ingested and ranks the spans of a trace by self-time.independent, btp queries trace spans and ranks them by self-time, and @saptools/cf-metrics@saptools/cf-metricsA read-only command line that queries the container and OpenTelemetry metrics SAP Cloud Logging has ingested for Cloud Foundry apps, as history over a time range, a ranking across apps or a live watch.independent, btp queries container and OpenTelemetry metrics of Cloud Foundry apps.
Artifacts
Tasks
Count a business event as a metric
A count the business asks for, how often an order is released or a document read, is emitted as a metric beside the runtime's technical ones, with the tenant on it.
Covers declaring the metric and getting it emitted. Where it is exported to, and the dashboard built from it, are separate tasks.
@cap-js/telemetryThe plugin's own metrics are technical, host, database pool and the persistent queue. A business count is added by the application through the OpenTelemetry JavaScript API, and the plugin exports it with the rest; the README's example registers a counter on listening and raises it in a middleware with the tenant as an attribute.
Remaining work: Write the meter and the counter, decide where they are raised, and carry the attributes; the model says nothing about such a metric on this route.
com.sap.cds:cds-services-bomOn Java the same thing is done against the OpenTelemetry Java API, which capire says is preconfigured by the injected agent. Its example builds a Meter, a LongCounter named reviewCounter and raises it in an @After handler with the book id as an attribute for the front end to aggregate on.
Remaining work: Write the handler code, pick the attributes, and have the agent attached, since the API instance comes from it. No annotation declares such a metric from the model on this runtime.
@cap-js-community/business-metricsTwo CDS annotations instead of code. @UsageMetering.Counting on a service entity or an action produces a counter, raised on the CRUD event the annotation names or on each call of the action, and its qualifier becomes the metric name. @UsageMetering.Gauge observes numeric fields of an entity under a name fixed to the service and the entity.
Conditions: Telemetry is enabled in the CAP application configuration enableBusinessMetrics is set under cds.requires.telemetry.metrics The project is a CAP Node.js project with service definitions Tenant is the only dimension available, which the README states for the counting annotation
Remaining work: Choose the entities and actions to annotate and the qualifier each metric is named by, and keep fields holding personal data out of an observed gauge, which the README asks for.
See what the browser did before the request arrived
The time a UI5 interaction took in the browser, and the JavaScript errors it hit, land in the backend beside the server's own telemetry, so a complaint about a slow or broken screen can be checked.
Covers getting the client's own measurements and errors off the browser and into a backend. What the server did once the request arrived is the rest of this capability.
cap-ui-telemetryIt reads the SAP-Perf-FESRec headers UI5 piggybacks onto the next backend request after a completed interaction, and it adds a CDS REST service that accepts batches of client errors. Each interaction becomes one structured cds.log record and each error one cds.log('ui-error') record, so the client's side arrives as logs rather than as spans.
Conditions: @sap/cds 8.0 or later on Node.js A UI5 app that sends the FESR headers SAP Cloud Logging bound to the CAP app for the custom fields to be indexed
Remaining work: Switch FESR on in the UI5 app and point its error reporting at the service's path, then choose the sampling fraction and the batch and length limits. Because the records are logs, a trace view will not show them beside the server's spans.
@cap-js/telemetryIts instrumentation starts at the server: the spans wrap the functions of cds.Service and the database calls, and nothing on the pages read states that it reads a FESR header or accepts anything the browser measured. Absence of a statement is not a refusal, so this stays unknown rather than a no.
Remaining work: Read the plugin's instrumentations option and its list of default instrumentations for a browser or FESR source before treating this as settled.
See where a slow request spent its time
A request that takes too long is broken down into the service calls, handlers and database statements it ran, with the elapsed time of each, so the slow part can be named.
Covers producing and reading the breakdown for one application's own request. Getting it to a backend is a separate task, and so is what the browser did before the request arrived.
@cap-js/telemetryAdding the plugin to the dependencies is the whole setup: it wraps the essential functions of cds.Service and its derivates, and the prepare and statement run of a @cap-js/cds-dbs database, and prints the finished request as a tree of elapsed times. The console is its default kind in development and in production, so the breakdown is there without an export target.
Remaining work: Read the tree and decide which span is the problem; nothing names it. A service on another database driver gets the service spans without the database ones.
com.sap.cds:cds-services-bomThe Java runtime answers this twice. In non-production profiles it logs a completed request as an indented timing tree on the console, down to the CQN statement, with no dependency and no JVM flag. With the OpenTelemetry Java Agent attached it produces spans instead, but its CAP-specific instrumentation is off by default and each span source, among them the CQN statement, is switched on by raising that logger.
Remaining work: Nothing for the local tree. For the agent path, raise the span loggers that matter and expect the console tree to switch itself off, since it is disabled as soon as the agent is detected.
opentelemetry-cdsAn independent plugin for the same job on the Node.js runtime, and what it instruments today was not established here. Its npm record names 0.1.4, published 2023-12-22, as the latest version, and the repository that record points at answered 404 when it was requested on 2026-10-15.
Remaining work: Find a reachable current source, or record where the project moved, before this entry is compared with the two above.
Send a service's traces and metrics to SAP Cloud Logging
The spans and metrics a deployed CAP service produces arrive in an SAP Cloud Logging instance, where they can be searched and put on a dashboard.
Covers getting the signals out of the application and into the instance. What is inside a span, and what a dashboard is built from once they arrive, are separate questions.
@cap-js/telemetryOne of the plugin's five predefined kinds exports its traces and metrics to SAP Cloud Logging. The README states the instance and the binding as requirements, names the three exporter packages the project has to add itself, and gives the instance configuration that makes the binding carry OpenTelemetry credentials.
Conditions: cds.requires.telemetry.kind is set to to-cloud-logging An SAP Cloud Logging instance exists and the application is bound to it The instance was created or updated with ingest_otlp enabled, so the binding carries OpenTelemetry credentials @grpc/grpc-js, @opentelemetry/exporter-trace-otlp-grpc and @opentelemetry/exporter-metrics-otlp-grpc are added as dependencies A user-provided service instance used for the binding carries the tag Cloud Logging
Remaining work: Create or update the instance with ingest_otlp, add the three exporter packages, set the kind per profile, and check the binding resolves. Nothing in the plugin creates or configures the instance.
SAP Cloud LoggingThe receiving end of both routes. Its catalogue record states that it ingests logs, metrics and traces over an OpenTelemetry format API and keeps the ingested data for a configurable retention period, and that it ships predefined content for Cloud Foundry and Kyma to investigate load, latency and error rates.
Remaining work: Create the instance with OTLP ingestion enabled, and build or adopt the views the signals are read in; the predefined content is per runtime environment and not per application.
com.sap.cds:cds-services-bomOn Java the export is the OpenTelemetry Java Agent's, attached to the application, with the agent extension reading the credentials from the service binding. Capire's steps are a cloud-logging binding created with ingest_otlp enabled and two environment variables naming cloud-logging as the metrics and traces exporter.
Conditions: The application uses the SAP Java Buildpack, which the documented configuration steps assume The application is bound to a cloud-logging service instance created with ingest_otlp enabled OTEL_METRICS_EXPORTER and OTEL_TRACES_EXPORTER are set to cloud-logging The CAP span loggers are raised, since the CAP-specific instrumentation creates no spans by default
Remaining work: Attach the agent and the extension as the buildpack documents, add the binding and the environment variables to the deployment descriptor, and raise the span loggers that are wanted. Without that last step the agent still exports the auto-instrumented library spans and the JVM metrics, and no CAP spans.
Content
Show 6 more
Seen working
Details
Coverage
Comparison properties
These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.
For your agent
- Ref
capability:telemetry- JSON
- /capabilities/telemetry.json
- MCP
- Connecting an agent