Telemetry
On Node.js telemetry is a plugin that loads into the server. It wraps the runtime's own service functions and its database calls, and the configured kind decides whether the spans and metrics are printed or exported. A signal the application wants beyond that set is written against the OpenTelemetry JavaScript API, or declared in the CDS model by a plugin that reads annotations.
Showing artifacts, examples and content with confirmed Node.js applicability. View All CAP
Overview
The Telemetry plugin is the answer. Adding @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 to a project's dependencies prints traces and metrics to the console, which is its default kind in development and in production, and one of five kinds switches the export to SAP Cloud Logging, Dynatrace, Jaeger or an OTLP endpoint. @sap/cds@sap/cdsThe CAP Node.js runtime, which compiles the CDS model, serves the services declared in it, answers generic requests before any handler runs, and loads every cds-plugin.sap official, cap supplies the correlation underneath: it reads an id from one of four headers or generates one, exposes it at cds.context.id, and passes the incoming traceparent through the JSON log formatter as w3c_traceparent, which is the field SAP Cloud Logging reads to correlate requests, logs and traces across applications.
Not covered: At the plugin's own reach. Database tracing covers @cap-js/cds-dbs databases, such as @cap-js/sqlite and @cap-js/hana, and not other drivers. Exporting logs over OpenTelemetry is an experimental opt-in. Each export kind needs its exporter packages added by hand and its target set up first, and the queue metrics need @sap/cds 9 or later.
The community cds-plugins land on this flavor, since a cds-plugin loads into the Node.js runtime: @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 for metrics declared in the model, 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 for the browser half of a request, 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 for a span per agent request, 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 for the diagnostic logging the exporters themselves write.
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.
@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.
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.
Content
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