{"ref":"capability:telemetry","page":"/capabilities/telemetry","json":"/capabilities/telemetry.json","generated":"2026-10-26","drafted_with_ai":true,"entity":{"id":"telemetry","name":"Telemetry","domain":"operations-and-runtime","ecosystems":["cap","abap","btp"],"universal":true,"description":"Seeing what a running service did — traces across handlers and database calls, metrics, and correlation that survives an async boundary.","short":"Traces, metrics and correlation for a running service","core_coverage":{"state":"core-and-community","assessed_at":"2026-10-15","what_core_does":"SAP ships OpenTelemetry instrumentation for both CAP runtimes, and each delivers it differently. On Node.js it is the Telemetry plugin, [@cap-js/telemetry](artifact:cap-js-telemetry), added as a dependency and printing traces and metrics to the console until an export kind is configured. On Java the OpenTelemetry Java Agent and the agent extension of the SAP Java Buildpack carry the signals, and the runtime also logs a completed request as an indented timing tree in non-production profiles with no dependency and no JVM flag. Capire states one export set for both runtimes, SAP Cloud Logging and Dynatrace, with Jaeger on Node.js only.","where_it_stops":"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.","community_adds":"[@cap-js-community/business-metrics](artifact:cap-js-community-business-metrics) turns CDS annotations into counter and gauge metrics, so a business count does not have to be written as OpenTelemetry API calls. [cap-ui-telemetry](artifact:sleibach-cap-ui-telemetry) 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-guard](artifact:furkanaksy838-cap-mcp-guard) adds a span per agent request against the application's own OpenTelemetry SDK, and [@sanjay-sde/cap-js-log-control](artifact:sanjay-sde-cap-js-log-control) lowers the diagnostic logging the OTLP exporters produce so real errors stay visible.","sources":[{"url":"https://cap.cloud.sap/docs/plugins/","title":"CAP Plugins & Enhancements — Telemetry","checked":"2026-10-15","quote":"The Telemetry plugin provides observability features such as tracing and metrics, including automatic OpenTelemetry instrumentation."},{"url":"https://cap.cloud.sap/docs/plugins/","title":"CAP Plugins & Enhancements — Telemetry, export targets","checked":"2026-10-15","quote":"Telemetry data can be exported to SAP Cloud Logging and Dynatrace. Node.js additionally supports Jaeger."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Open Telemetry","checked":"2026-10-15","quote":"Out-of-the-box traces and metrics by auto-instrumented"},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Dev Trace Output","checked":"2026-10-15","quote":"In non-production profiles, CAP Java automatically logs completed request traces as indented timing trees to the console."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, CAP Instrumentation","checked":"2026-10-15","quote":"By default, instrumentation for CAP-specific components is disabled, so that no traces and spans are created even if the Open Telemetry Java Agent has been configured."},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Setup","checked":"2026-10-15","quote":"Database tracing is limited to [@cap-js/cds-dbs](https://github.com/cap-js/cds-dbs)-based databases, such as [@cap-js/sqlite](https://www.npmjs.com/package/@cap-js/sqlite) and [@cap-js/hana](https://www.npmjs.com/package/@cap-js/hana)."}],"relationship":"core-adopted-it"},"history":[{"date":"2026-08-31","field":"core_coverage.state","from":"left-open-on-purpose","to":"core-and-community","reason":"States renamed to describe who is present rather than to interpret intent. left-open-on-purpose asserted a motive; core-and-community states a fact, with relationship carrying the intent separately."},{"date":"2026-09-14","field":"ecosystems","from":"cap","to":"cap, abap, btp","reason":"abap-metrics-provider, abap-opentelemetry and abap-prometheus export metrics and OpenTelemetry data from an ABAP system; SAP-samples/teched2025-CS261 monitors an instrumented BTP application through SAP Cloud ALM and SAP Cloud Logging."},{"date":"2026-09-27","field":"core_coverage","from":"without the page","to":"cites the page","reason":"capire audit 2026-09-27: a page this capability owns was cited nowhere."},{"date":"2026-10-15","field":"core_coverage.sources","from":"https://cap.cloud.sap/docs/guides/integration/platform/telemetry","to":"https://cap.cloud.sap/docs/plugins/","reason":"The cited capire page answered 404 when it was requested on 2026-10-15. The Telemetry section of capire's plugins page carries the same claim and states the export targets per runtime, so the citation moves there."},{"date":"2026-10-15","field":"core_coverage.what_core_does, core_coverage.where_it_stops, core_coverage.community_adds","from":"Java only, with no community sentence","to":"Both runtimes, with their two delivery routes and the community options named","reason":"what_core_does described the Java agent alone, which left the Node.js answer, the Telemetry plugin, out of the one field a reader checks first. The boundary gains the two edges inside the server that the sources state: the Node.js plugin's database tracing reaches @cap-js/cds-dbs databases only, and CAP Java's own instrumentation is off until a logger is raised."},{"date":"2026-10-15","field":"coverage_by_flavor, framing_by_flavor, framing_by_ecosystem.cap","from":null,"to":"node, java","reason":"The two CAP flavors answer this concern by different mechanisms, a plugin loaded into the server against an agent attached to the JVM, and the conditions a reader has to meet differ with them. Both flavors are assessed from capire rather than derived from the options."},{"date":"2026-10-15","field":"facets","from":null,"to":"signals, destinations, instrumented_by","reason":"Three questions the sources answer differently for the CAP options and that change which one a reader reaches for: which signals it produces, where it can send them, and whether the application has to write code for a signal of its own. Scoped to the CAP door; the ABAP and BTP options were not assessed in this pass."},{"date":"2026-10-26","field":"coverage_by_ecosystem.abap.note","from":"The repositories here are independent or from a community organisation; how they relate to SAP Cloud ALM has not been assessed.","to":"The core side is SAP Cloud ALM; the community and independent tools expose metrics, send OpenTelemetry data or record abap2UI5 usage.","reason":"Reassessed against the graph (check:capabilities): the old note described the repositories by count-like scope and left out the newer abap2UI5 admin cockpit. The state stays core-and-community, since the block states what SAP Cloud ALM does with sources."},{"date":"2026-10-26","field":"coverage_by_ecosystem.btp.state, coverage_by_ecosystem.btp.community_adds, coverage_by_ecosystem.btp.note","from":"core-only; The repository answering this here is SAP's TechEd 2025 CS261 session, which demonstrates and does not provide, so core-only is a assessment of the corpus.","to":"core-and-community; community_adds names the read-only command lines over what SAP Cloud Logging has ingested; the note is removed.","reason":"Reassessed against the graph (check:capabilities): SAP's own BTP services and independent command lines now provide this concern behind the BTP door. The old note only explained a state the providers no longer support."},{"date":"2026-10-26","field":"coverage_by_flavor.java.note","from":"No community or independent artifact in the corpus answers this concern on the Java flavor: every other provider on the CAP door is a cds-plugin, which loads into the Node.js runtime.","to":"A cds-plugin loads into the Node.js runtime, so the community cds-plugins on the CAP door sit on the Node.js flavor.","reason":"Reassessed against the graph (check:capabilities): the sentence was an absence claim about who has built something; the platform fact stays."},{"date":"2026-10-26","field":"coverage_by_flavor.node.community_adds","from":"Every community artifact on this capability is a cds-plugin, so they all land on this flavor: ...","to":"The community cds-plugins land on this flavor, since a cds-plugin loads into the Node.js runtime: ...","reason":"Reassessed against the graph (check:capabilities): removes a universal claim about the providers that goes stale as they arrive."}],"coverage_by_ecosystem":{"abap":{"state":"core-and-community","assessed_at":"2026-09-14","what_core_does":"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.","where_it_stops":"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.","sources":[{"url":"https://support.sap.com/en/alm/sap-cloud-alm/operations/expert-portal/health-monitoring.html","title":"Health Monitoring — SAP Cloud ALM for Operations Expert Portal","checked":"2026-09-14","quote":"Technical metrics are collected on a regular basis and can be used to calculate the overall health of the monitored object."},{"url":"https://support.sap.com/en/alm/sap-cloud-alm/operations/expert-portal/health-monitoring/health-mon-content.html","title":"Health Monitoring — Content, SAP Cloud ALM for Operations Expert Portal","checked":"2026-09-14","quote":"ABAP Runtime Errors"}],"relationship":"unassessed","note":"The core side is [SAP Cloud ALM](external:sap-cloud-alm). The community and independent tools expose metrics to Prometheus, send OpenTelemetry data to a backend, or record the usage and response times of an [abap2UI5](artifact:abap2ui5-abap2ui5) installation."},"btp":{"state":"core-and-community","assessed_at":"2026-09-14","relationship":"unassessed","what_core_does":"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.","where_it_stops":"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](artifact:cap-js-telemetry).","community_adds":"Independent command lines read back what [SAP Cloud Logging](artifact:btp-cloud-logging) has already ingested: [@saptools/cf-otel](artifact:saptools-cf-otel) queries trace spans and ranks them by self-time, and [@saptools/cf-metrics](artifact:saptools-cf-metrics) queries container and OpenTelemetry metrics of Cloud Foundry apps.","sources":[{"url":"https://support.sap.com/en/alm/sap-cloud-alm/operations/expert-portal/data-collection-infrastructure.html","title":"OpenTelemetry@SAP — SAP Cloud ALM for Operations Expert Portal","checked":"2026-09-14","quote":"how you can instrument your custom-built application in SAP BTP, Cloud Foundry environment and SAP BTP, Kyma runtime with our Data Collection Instrumentation Libraries to monitor this in SAP Cloud ALM"},{"url":"https://kyma-project.io/external-content/telemetry-manager/docs/user/integration/sap-cloud-logging/README.html","title":"Integrate with SAP Cloud Logging — Kyma documentation","checked":"2026-09-14","quote":"SAP Cloud Logging is an instance-based and environment-agnostic observability service to store, visualize, and analyze logs, metrics, and traces."}]}},"coverage_by_flavor":{"node":{"state":"core-and-community","assessed_at":"2026-10-15","relationship":"core-adopted-it","what_core_does":"The Telemetry plugin is the answer. Adding [@cap-js/telemetry](artifact:cap-js-telemetry) 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](artifact:sap-cds) 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.","where_it_stops":"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.","community_adds":"The community cds-plugins land on this flavor, since a cds-plugin loads into the Node.js runtime: [@cap-js-community/business-metrics](artifact:cap-js-community-business-metrics) for metrics declared in the model, [cap-ui-telemetry](artifact:sleibach-cap-ui-telemetry) for the browser half of a request, [cap-mcp-guard](artifact:furkanaksy838-cap-mcp-guard) for a span per agent request, and [@sanjay-sde/cap-js-log-control](artifact:sanjay-sde-cap-js-log-control) for the diagnostic logging the exporters themselves write.","sources":[{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Setup","checked":"2026-10-15","quote":"Simply add `@cap-js/telemetry` to your dependencies via `npm add @cap-js/telemetry` and you will find telemetry output written to the console like so:"},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, telemetry-to-console","checked":"2026-10-15","quote":"This is the default kind in both development and production."},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Predefined Kinds","checked":"2026-10-15","quote":"See [Predefined Kinds](#predefined-kinds) for additional dependencies you need to bring yourself as well as some additional setup steps you need to perform when exporting to Dynatrace, SAP Cloud Logging, Jaeger, etc."},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Logs","checked":"2026-10-15","quote":"Exporting logs via OpenTelemetry is supported as an experimental opt-in feature."},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Queue","checked":"2026-10-15","quote":"Further, `queue` metrics are only available when using `@sap/cds >= 9`."},{"url":"https://cap.cloud.sap/docs/node.js/cds-log","title":"Logging Support (CAP Node.js) — capire, Request Correlation","checked":"2026-10-15","quote":"As CAP aims to be platform independent, we check an array of headers (or generate a new ID if none hits) and ensure the value available at `cds.context.id` as well as `req.headers['x-correlation-id']`:"},{"url":"https://cap.cloud.sap/docs/node.js/cds-log","title":"Logging Support (CAP Node.js) — capire, Request Correlation","checked":"2026-10-15","quote":"Specifically field `w3c_traceparent` is then used by both SAP Application Logging Service and SAP Cloud Logging to determine field `trace_id` in order to correlate requests, logs, and traces across multiple applications."}]},"java":{"state":"core-only","assessed_at":"2026-10-15","what_core_does":"Two things, and they do not overlap. In non-production profiles the runtime logs a completed request as an indented timing tree on the console, down to the CQN statement, with no dependency and no JVM flag. For a deployed application the OpenTelemetry Java Agent and the agent extension delivered by the SAP Java Buildpack export traces and metrics, to SAP Cloud Logging through a cloud-logging binding created with ingest_otlp enabled, or to Dynatrace, where OneAgent takes the distributed traces and the agent the metrics. The CAP spans the runtime itself can add, for CQN statements, the members of an OData $batch, request and ChangeSet contexts, the outbox collector and event dispatch, are off by default and each is switched on by raising its logger to INFO or DEBUG.","where_it_stops":"At what the agent configuration covers. The documented steps assume the SAP Java Buildpack, nothing is spanned by the CAP instrumentation until a logger is raised, and the console timing tree turns itself off as soon as the agent is detected, so the two routes are never in use at once. A span or a metric the application wants beyond the auto-instrumented set is written against the OpenTelemetry Java API.","note":"A cds-plugin loads into the Node.js runtime, so the community cds-plugins on the CAP door sit on the Node.js flavor.","sources":[{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Dev Trace Output","checked":"2026-10-15","quote":"This feature is auto-enabled in development and disabled when the OpenTelemetry Java Agent is detected or in production profiles. No dependencies or JVM flags are required."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Configure Java Agent and Extension Library","checked":"2026-10-15","quote":"The configuration steps below assume that your application uses the"},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Configuration of Cloud Logging Service","checked":"2026-10-15","quote":"Bind your CAP Java application to a service instance of `cloud-logging`. It's important to enable the Open Telemetry capabilities by passing `ingest_otlp` as additional configuration parameter."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Configuration of Dynatrace","checked":"2026-10-15","quote":"Open Telemetry support using Dynatrace leverages the _Dynatrace OneAgent_ for distributed traces and _Open Telemetry Java Agent_ for metrics."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, CAP Instrumentation","checked":"2026-10-15","quote":"By default, instrumentation for CAP-specific components is disabled, so that no traces and spans are created even if the Open Telemetry Java Agent has been configured."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, CAP Instrumentation","checked":"2026-10-15","quote":"| `com.sap.cds.otel.span.CQN`                    | `INFO`         | Spans for executed CQN statement.                          |"},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Custom Instrumentation","checked":"2026-10-15","quote":"Using the Open Telemetry Java API, it's possible to provide additional observability signals from within a CAP Java application. This can include additional spans as well as metrics."}]}},"framing_by_ecosystem":{"cap":{"description":"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."},"abap":{"description":"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."},"btp":{"description":"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."}},"framing_by_flavor":{"node":{"description":"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."},"java":{"description":"On Java telemetry is an agent attached to the JVM with the extension that reads the service binding, and the runtime's own CAP spans are switches on a logger rather than code. Before any of that, the server prints the timing tree of a finished request to the console in non-production profiles, which is the local half of the same concern."}},"drafted_with_ai":true,"facets":[{"key":"signals","label":"Signals","kind":"many","values":["Traces","Metrics","Logs"],"ecosystems":["cap"]},{"key":"destinations","label":"Where it sends data","kind":"many","values":["Console","SAP Cloud Logging","Dynatrace","Jaeger","OTLP endpoint"],"ecosystems":["cap"]},{"key":"instrumented_by","label":"Instrumented by","kind":"many","values":["Automatically","CDS annotations","Application code"],"ecosystems":["cap"]}]},"sap_delivery":{"door":"cap","all":{"built_in":[{"ref":"artifact:cap-java-cds-services-bom","name":"com.sap.cds:cds-services-bom","json":"/artifacts/cap-java-cds-services-bom.json"}],"documented_pattern":[],"announced":[],"packages":[{"ref":"artifact:cap-js-telemetry","name":"@cap-js/telemetry","json":"/artifacts/cap-js-telemetry.json"},{"ref":"artifact:sap-ux-telemetry","name":"@sap-ux/telemetry","json":"/artifacts/sap-ux-telemetry.json"}]},"by_flavor":{"node":{"built_in":[],"documented_pattern":[],"announced":[],"packages":[{"ref":"artifact:cap-js-telemetry","name":"@cap-js/telemetry","json":"/artifacts/cap-js-telemetry.json"}]},"java":{"built_in":[{"ref":"artifact:cap-java-cds-services-bom","name":"com.sap.cds:cds-services-bom","json":"/artifacts/cap-java-cds-services-bom.json"}],"documented_pattern":[],"announced":[],"packages":[]}}},"edges":{"use_cases":[{"id":"count-a-business-event-as-a-metric-in-a-cap-service","name":"Count a business event as a metric","capability":"capability:telemetry","ecosystem":"cap","flavors":["node","java"],"outcome":"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.","boundary":"Covers declaring the metric and getting it emitted. Where it is exported to, and the dashboard built from it, are separate tasks.","origin":"Editorial hypothesis, prompted by a practitioner post already attached to this capability that adds such a counter by hand.","requirement_dimensions":["Which runtime the service is on","Whether the count has to be declared in the model or may be written in a handler","Which dimensions the metric has to carry besides the tenant","Whether the observed field may hold personal data"],"needs":[{"key":"signals","value":"Metrics"}],"contributions":[{"ref":"artifact:cap-js-community-business-metrics","role":"metrics declared in the model","state":"conditional","flavors":["node"],"version_scope":"README at cap-js-community/business-metrics commit eee01d0, version 1.0.1.","description":"Two 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.","remaining_kinds":["configuration"],"sources":[{"url":"https://raw.githubusercontent.com/cap-js-community/business-metrics/eee01d0e28e5a76bdb3d58900f8068d516d1ab17/README.md","title":"Business-metrics — README, Features","checked":"2026-10-15","quote":"- **Counter Metrics**: Track the number of times specific events occur for service entities or actions (e.g., READ, DELETE or custom actions like releaseSalesOrder)."},{"url":"https://raw.githubusercontent.com/cap-js-community/business-metrics/eee01d0e28e5a76bdb3d58900f8068d516d1ab17/README.md","title":"Business-metrics — README, Counting Annotation","checked":"2026-10-15","quote":"Use the `@UsageMetering.Counting` annotation in your `services.cds` file to enable counter metrics for specific entities or actions."},{"url":"https://raw.githubusercontent.com/cap-js-community/business-metrics/eee01d0e28e5a76bdb3d58900f8068d516d1ab17/README.md","title":"Business-metrics — README, Counting Annotation","checked":"2026-10-15","quote":"The library supports the capture of tenant information only."},{"url":"https://raw.githubusercontent.com/cap-js-community/business-metrics/eee01d0e28e5a76bdb3d58900f8068d516d1ab17/README.md","title":"Business-metrics — README, Requirements and Setup","checked":"2026-10-15","quote":"- Telemetry enabled in the CAP application configuration"}]},{"ref":"artifact:cap-js-telemetry","role":"metric written in application code","state":"documented","flavors":["node"],"version_scope":"README at cap-js/telemetry commit e97874b, the 2.1.0 release.","description":"The 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.","remaining_kinds":["application-code"],"sources":[{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Custom Metrics","checked":"2026-10-15","quote":"counter.add(1, { 'sap.tenancy.tenant_id': cds.context.tenant })"},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Custom Metrics","checked":"2026-10-15","quote":"const meter = metrics.getMeter('@capire/incidents:req.counter')"}]},{"ref":"artifact:cap-java-cds-services-bom","role":"metric written in application code","state":"documented","flavors":["java"],"description":"On 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.","remaining_kinds":["configuration","application-code"],"sources":[{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Custom Instrumentation","checked":"2026-10-15","quote":"Using the Open Telemetry Java API, it's possible to provide additional observability signals from within a CAP Java application. This can include additional spans as well as metrics."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Custom Instrumentation","checked":"2026-10-15","quote":"You can record metrics during execution of, for example, a custom event handler."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Custom Instrumentation","checked":"2026-10-15","quote":"The instance of OpenTelemetry API is preconfigured for you by the agent that was injected in your application. You don't need to configure it again."}]}],"readings":[{"ref":"content:adding-custom-metrics-to-a-cap-application-using-cap-js-telementry-plugin-and-sa","relevance":"Somebody doing exactly the code route: a custom OpenTelemetry counter on top of the plugin's built-in metrics, raised and lowered from a service handler on CREATE and UPDATE of high-urgency incidents, then found again in SAP Cloud Logging.","flavors":["node"],"shows":["artifact:cap-js-telemetry"]}],"unknowns":["business-metrics names no export target of its own; which backend receives its counters follows from the kind configured for the plugin it extends, and that combination was not tested here.","The README states the gauge metric name as fixed to the service and the entity and nothing read offers an override, so a naming convention of one's own is not recorded as possible.","Nothing read states whether a dimension other than tenant can be added to a counter on the Node.js annotation route."],"assessed_at":"2026-10-15","drafted_with_ai":true,"omitted_contributions":0,"assessment_kind":"documented-contributions"},{"id":"see-what-the-browser-did-before-a-cap-request-arrived","name":"See what the browser did before the request arrived","capability":"capability:telemetry","ecosystem":"cap","flavors":["node"],"outcome":"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.","boundary":"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.","origin":"Editorial hypothesis. The core's stated boundary on this capability is the server, and this outcome starts exactly where that boundary is drawn.","requirement_dimensions":["Whether the UI5 app can be changed to send FESR and report its errors","Which backend the records have to be readable in","Whether the client records have to correlate with the server's spans","How much of the traffic may be recorded"],"contributions":[{"ref":"artifact:sleibach-cap-ui-telemetry","role":"client capture in the server","state":"conditional","flavors":["node"],"version_scope":"README at sleibach/cap-ui-telemetry commit 78e5d75.","description":"It 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.","remaining_kinds":["configuration"],"sources":[{"url":"https://raw.githubusercontent.com/sleibach/cap-ui-telemetry/78e5d7576ac69d18b807161b4c52c73a3cb28d04/README.md","title":"cap-ui-telemetry — README","checked":"2026-10-15","quote":"UI5 FESR (frontend performance) + client-error capture for SAP CAP (Node.js), forwarded to SAP Cloud Logging via `cds.log`."},{"url":"https://raw.githubusercontent.com/sleibach/cap-ui-telemetry/78e5d7576ac69d18b807161b4c52c73a3cb28d04/README.md","title":"cap-ui-telemetry — README, FESR capture","checked":"2026-10-15","quote":"**FESR capture** — reads the `SAP-Perf-FESRec` / `SAP-Perf-FESRec-opt` headers UI5 piggybacks onto the next backend request after each completed interaction"},{"url":"https://raw.githubusercontent.com/sleibach/cap-ui-telemetry/78e5d7576ac69d18b807161b4c52c73a3cb28d04/README.md","title":"cap-ui-telemetry — README, Client-error ingestion","checked":"2026-10-15","quote":"**Client-error ingestion** — a CDS REST service (`POST <path>/errors`) accepts batches of client errors and emits one `cds.log('ui-error')` record per entry."},{"url":"https://raw.githubusercontent.com/sleibach/cap-ui-telemetry/78e5d7576ac69d18b807161b4c52c73a3cb28d04/README.md","title":"cap-ui-telemetry — README, prerequisites","checked":"2026-10-15","quote":"SAP Cloud Logging bound to your CAP app for the custom fields to be indexed"}]},{"ref":"artifact:cap-js-telemetry","role":"runtime instrumentation","state":"unknown","flavors":["node"],"description":"Its 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."}],"unknowns":["The README names SAP Cloud ALM's RUM as the official target for FESR records; whether RUM would receive the same records, or what is lost by sending them to Cloud Logging instead, is outside what was read.","No source read shows a client record and a server span correlated on one id, so following one interaction from the browser into the handler is not recorded as working.","The Java flavor was not assessed for this outcome: every option in the corpus that captures the client side is a cds-plugin, and no Java answer was looked for."],"assessed_at":"2026-10-15","drafted_with_ai":true,"readings":[],"omitted_contributions":0,"assessment_kind":"documented-contributions"},{"id":"see-where-a-slow-cap-request-spent-its-time","name":"See where a slow request spent its time","capability":"capability:telemetry","ecosystem":"cap","flavors":["node","java"],"outcome":"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.","boundary":"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.","origin":"Editorial hypothesis, taken from the two capire pages that both open on this question: the plugin's console output on Node.js and CAP Java's dev trace output.","requirement_dimensions":["Whether the breakdown is needed on a developer machine or in a deployed landscape","Which runtime the service is on","Which database driver the service uses","Whether the request carries on into another service"],"needs":[{"key":"signals","value":"Traces"}],"contributions":[{"ref":"artifact:cap-js-telemetry","role":"runtime instrumentation","state":"documented","flavors":["node"],"version_scope":"README at cap-js/telemetry commit e97874b, the 2.1.0 release.","description":"Adding 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](artifact: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.","sources":[{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Setup","checked":"2026-10-15","quote":"Simply add `@cap-js/telemetry` to your dependencies via `npm add @cap-js/telemetry` and you will find telemetry output written to the console like so:"},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Traces","checked":"2026-10-15","quote":"For this, `@cap-js/telemetry` wraps all essential functions of `cds.Service` and its derivates."},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, telemetry-to-console","checked":"2026-10-15","quote":"This is the default kind in both development and production."},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Setup","checked":"2026-10-15","quote":"Database tracing is limited to [@cap-js/cds-dbs](https://github.com/cap-js/cds-dbs)-based databases, such as [@cap-js/sqlite](https://www.npmjs.com/package/@cap-js/sqlite) and [@cap-js/hana](https://www.npmjs.com/package/@cap-js/hana)."}]},{"ref":"artifact:cap-java-cds-services-bom","role":"runtime instrumentation","state":"documented","flavors":["java"],"description":"The 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.","sources":[{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Dev Trace Output","checked":"2026-10-15","quote":"In non-production profiles, CAP Java automatically logs completed request traces as indented timing trees to the console."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Dev Trace Output","checked":"2026-10-15","quote":"This feature is auto-enabled in development and disabled when the OpenTelemetry Java Agent is detected or in production profiles. No dependencies or JVM flags are required."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, CAP Instrumentation","checked":"2026-10-15","quote":"By default, instrumentation for CAP-specific components is disabled, so that no traces and spans are created even if the Open Telemetry Java Agent has been configured."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, CAP Instrumentation","checked":"2026-10-15","quote":"| `com.sap.cds.otel.span.CQN`                    | `INFO`         | Spans for executed CQN statement.                          |"}]},{"ref":"artifact:soontao-opentelemetry-cds","role":"independent OpenTelemetry plugin","state":"unknown","flavors":["node"],"description":"An 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."}],"readings":[{"ref":"content:implementation-of-observability-using-opentelemetry-in-sap-btp","relevance":"Where one service's breakdown stops. The post is about tracing across a landscape, BTP applications, integrations and workflows calling microservices the customer runs, which is the span a single runtime's instrumentation does not reach."}],"unknowns":["Capire's dev-trace comparison table names Jaeger, Dynatrace and Cloud Logging as the Java agent's output, while the plugins page says Jaeger is supported on Node.js only. Which holds for a CAP Java application is not settled by the pages read.","Nothing read states whether the Node.js plugin's spans cover a remote service call made through the SAP Cloud SDK, so an outbound hop is not recorded here as traced."],"assessed_at":"2026-10-15","drafted_with_ai":true,"omitted_contributions":0,"assessment_kind":"documented-contributions"},{"id":"send-a-cap-services-traces-and-metrics-to-sap-cloud-logging","name":"Send a service's traces and metrics to SAP Cloud Logging","capability":"capability:telemetry","ecosystem":"cap","flavors":["node","java"],"outcome":"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.","boundary":"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.","origin":"Editorial hypothesis. Both CAP runtimes document this one target, and both documented routes carry conditions that have to be met before anything arrives.","requirement_dimensions":["Which runtime the service is on","Whether the Cloud Logging instance was created with OTLP ingestion enabled","Whether the binding is a managed instance or a user-provided one","Whether the Java application uses the SAP Java Buildpack"],"needs":[{"key":"destinations","value":"SAP Cloud Logging"}],"paths":[{"key":"node-plugin","name":"The Telemetry plugin on Node.js, exporting to the bound instance"},{"key":"java-agent","name":"The OpenTelemetry Java Agent on Java, exporting to the bound instance"}],"contributions":[{"ref":"artifact:cap-js-telemetry","role":"exporter in the application","state":"conditional","flavors":["node"],"paths":["node-plugin"],"version_scope":"README at cap-js/telemetry commit e97874b, the 2.1.0 release.","description":"One 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.","remaining_kinds":["configuration"],"sources":[{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, telemetry-to-cloud-logging","checked":"2026-10-15","quote":"Exports traces and metrics to SAP Cloud Logging."},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, telemetry-to-cloud-logging","checked":"2026-10-15","quote":"Hence, a SAP Cloud Logging instance is required and the app must be bound to that SAP Cloud Logging instance."},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, telemetry-to-cloud-logging","checked":"2026-10-15","quote":"Use via `cds.requires.telemetry.kind = 'to-cloud-logging'`."},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, telemetry-to-cloud-logging","checked":"2026-10-15","quote":"In order to receive OpenTelemetry credentials in the binding to the SAP Cloud Logging instance, you need to include the following configuration while creating the SAP Cloud Logging instance (or by updating an existing instance):"},{"url":"https://raw.githubusercontent.com/cap-js/telemetry/e97874b47272abb9f8bbae776c0df5378d6cf1a3/README.md","title":"@cap-js/telemetry — README, Setup","checked":"2026-10-15","quote":"See [Predefined Kinds](#predefined-kinds) for additional dependencies you need to bring yourself as well as some additional setup steps you need to perform when exporting to Dynatrace, SAP Cloud Logging, Jaeger, etc."}]},{"ref":"artifact:cap-java-cds-services-bom","role":"exporter in the application","state":"conditional","flavors":["java"],"paths":["java-agent"],"description":"On 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.","remaining_kinds":["configuration"],"sources":[{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Configuration of Cloud Logging Service","checked":"2026-10-15","quote":"Bind your CAP Java application to a service instance of `cloud-logging`. It's important to enable the Open Telemetry capabilities by passing `ingest_otlp` as additional configuration parameter."},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Configuration of Cloud Logging Service","checked":"2026-10-15","quote":"OTEL_METRICS_EXPORTER: cloud-logging"},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, Configure Java Agent and Extension Library","checked":"2026-10-15","quote":"The configuration steps below assume that your application uses the"},{"url":"https://cap.cloud.sap/docs/java/operating-applications/observability","title":"Observability (CAP Java) — capire, CAP Instrumentation","checked":"2026-10-15","quote":"By default, instrumentation for CAP-specific components is disabled, so that no traces and spans are created even if the Open Telemetry Java Agent has been configured."}]},{"ref":"artifact:btp-cloud-logging","role":"receiving instance","state":"documented","paths":["node-plugin","java-agent"],"description":"The 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.","remaining_kinds":["configuration"],"sources":[{"url":"https://discovery-center.cloud.sap/servicecatalog/api/v1/services/14450845-5f9e-46e3-9488-79c837bd65af","title":"SAP Discovery Center — SAP Cloud Logging","checked":"2026-10-15","quote":"Ingest logs, metrics, and traces via OpenTelemetry format API."},{"url":"https://discovery-center.cloud.sap/servicecatalog/api/v1/services/14450845-5f9e-46e3-9488-79c837bd65af","title":"SAP Discovery Center — SAP Cloud Logging","checked":"2026-10-15","quote":"Persist the ingested observability data for a configurable retention period."},{"url":"https://discovery-center.cloud.sap/servicecatalog/api/v1/services/14450845-5f9e-46e3-9488-79c837bd65af","title":"SAP Discovery Center — SAP Cloud Logging","checked":"2026-10-15","quote":"For Cloud Foundry and Kyma, it offers an easy integration by providing predefined contents to investigate load, latency, and error rates of the observed applications based on their requests and correlate them with additional data."}]}],"readings":[{"ref":"content:kyma-integration-with-sap-cloud-logging-part-2-let-s-ship-some-traces","relevance":"A multitenant CAP application instrumented with the plugin, with its traces arriving in SAP Cloud Logging and read in its Trace Analytics view. The route there is a Kyma TracePipeline pointed at the binding's OTLP endpoint rather than the plugin's own Cloud Logging kind, so it shows the two ends working and a third way between them.","flavors":["node"],"shows":["artifact:cap-js-telemetry","artifact:btp-cloud-logging"]},{"ref":"content:adding-custom-metrics-to-a-cap-application-using-cap-js-telementry-plugin-and-sa","relevance":"The other end of the same route: a metric exported by the plugin, found again in Cloud Logging's Discover and Visualize screens and put on a custom visualisation.","flavors":["node"],"shows":["artifact:cap-js-telemetry"]}],"unknowns":["The Node.js route's documented exporters are the OTLP/gRPC ones; nothing read states whether the HTTP exporters can be used against a Cloud Logging binding instead.","Neither page read states what happens to signals produced while the instance is unreachable.","Both posts behind the readings answered 403 when they were requested on 2026-10-15, so what they show rests on the summaries their accepted entries already carry rather than on a fresh read."],"assessed_at":"2026-10-15","drafted_with_ai":true,"omitted_contributions":0,"assessment_kind":"documented-contributions"}],"shared_tasks":[],"related_tasks":[],"options":[{"ref":"artifact:cap-js-community-business-metrics","name":"@cap-js-community/business-metrics","json":"/artifacts/cap-js-community-business-metrics.json","ecosystem":"cap","origin_ring":"community-org"},{"ref":"artifact:cap-js-telemetry","name":"@cap-js/telemetry","json":"/artifacts/cap-js-telemetry.json","ecosystem":"cap","origin_ring":"sap-official"},{"ref":"artifact:sanjay-sde-cap-js-log-control","name":"@sanjay-sde/cap-js-log-control","json":"/artifacts/sanjay-sde-cap-js-log-control.json","ecosystem":"cap","origin_ring":"independent"},{"ref":"artifact:sap-ux-telemetry","name":"@sap-ux/telemetry","json":"/artifacts/sap-ux-telemetry.json","ecosystem":"cap","origin_ring":"sap-official"},{"ref":"artifact:sap-e2e-trace","name":"@sap/e2e-trace","json":"/artifacts/sap-e2e-trace.json","ecosystem":"btp","origin_ring":"sap-official"},{"ref":"artifact:saptools-cf-metrics","name":"@saptools/cf-metrics","json":"/artifacts/saptools-cf-metrics.json","ecosystem":"btp","origin_ring":"independent"},{"ref":"artifact:saptools-cf-otel","name":"@saptools/cf-otel","json":"/artifacts/saptools-cf-otel.json","ecosystem":"btp","origin_ring":"independent"},{"ref":"artifact:abap-observability-tools-abap-metrics-provider","name":"abap-metrics-provider","json":"/artifacts/abap-observability-tools-abap-metrics-provider.json","ecosystem":"abap","origin_ring":"independent"},{"ref":"artifact:heliconialabs-abap-opentelemetry","name":"abap-opentelemetry","json":"/artifacts/heliconialabs-abap-opentelemetry.json","ecosystem":"abap","origin_ring":"independent"},{"ref":"artifact:pacroy-abap-prometheus","name":"abap-prometheus","json":"/artifacts/pacroy-abap-prometheus.json","ecosystem":"abap","origin_ring":"independent"},{"ref":"artifact:abap2ui5-addons-admin-cockpit","name":"admin-cockpit","json":"/artifacts/abap2ui5-addons-admin-cockpit.json","ecosystem":"abap","origin_ring":"community-org"},{"ref":"artifact:btp-dynatrace-agent-activation","name":"Agent Activation for Dynatrace Service for SAP BTP","json":"/artifacts/btp-dynatrace-agent-activation.json","ecosystem":"btp","origin_ring":"sap-official"},{"ref":"artifact:furkanaksy838-cap-mcp-guard","name":"cap-mcp-guard","json":"/artifacts/furkanaksy838-cap-mcp-guard.json","ecosystem":"cap","origin_ring":"independent"},{"ref":"artifact:sleibach-cap-ui-telemetry","name":"cap-ui-telemetry","json":"/artifacts/sleibach-cap-ui-telemetry.json","ecosystem":"cap","origin_ring":"independent"},{"ref":"artifact:cds-caching","name":"cds-caching","json":"/artifacts/cds-caching.json","ecosystem":"cap","origin_ring":"independent"},{"ref":"artifact:cap-java-cds-services-bom","name":"com.sap.cds:cds-services-bom","json":"/artifacts/cap-java-cds-services-bom.json","ecosystem":"cap","origin_ring":"sap-official"},{"ref":"artifact:soontao-opentelemetry-cds","name":"opentelemetry-cds","json":"/artifacts/soontao-opentelemetry-cds.json","ecosystem":"cap","origin_ring":"independent"},{"ref":"artifact:btp-cloud-logging","name":"SAP Cloud Logging","json":"/artifacts/btp-cloud-logging.json","ecosystem":"btp","origin_ring":"sap-official"},{"ref":"artifact:btp-monitoring","name":"SAP Monitoring Service for SAP BTP","json":"/artifacts/btp-monitoring.json","ecosystem":"btp","origin_ring":"sap-official"}],"samples":[{"ref":"artifact:sap-samples-teched2025-cs261","name":"teched2025-CS261","json":"/artifacts/sap-samples-teched2025-cs261.json"},{"ref":"artifact:sap-samples-teched2025-xp264","name":"teched2025-XP264","json":"/artifacts/sap-samples-teched2025-xp264.json"},{"ref":"artifact:sap-samples-teched2025-xp265","name":"teched2025-XP265","json":"/artifacts/sap-samples-teched2025-xp265.json"}],"explained_by":[{"ref":"content:cap-in-the-age-of-ai-5-agents-wrap-up","name":"CAP in the age of AI #5 - agents wrap-up","json":"/content/cap-in-the-age-of-ai-5-agents-wrap-up.json"},{"ref":"content:s-4hana-observability-streaming-sap-cloud-alm-logserv-telemetry-to-bigquery-vert","name":"S/4HANA Observability: Streaming SAP Cloud ALM & LogServ Telemetry to BigQuery & Vertex AI","json":"/content/s-4hana-observability-streaming-sap-cloud-alm-logserv-telemetry-to-bigquery-vert.json"},{"ref":"content:autonomous-diagnostics-on-kyma-unplugged-goose-litellm-kro-sap-ai-core-in-produc","name":"Autonomous Diagnostics on Kyma Unplugged: Goose + LiteLLM + KRO + SAP AI Core in Production","json":"/content/autonomous-diagnostics-on-kyma-unplugged-goose-litellm-kro-sap-ai-core-in-produc.json"},{"ref":"content:implementation-of-observability-using-opentelemetry-in-sap-btp","name":"Implementation of Observability using OpenTelemetry in SAP BTP","json":"/content/implementation-of-observability-using-opentelemetry-in-sap-btp.json"},{"ref":"content:performance-trace-node-js-app-on-btp-with-dynatrace","name":"Performance Trace Node.js App on BTP with Dynatrace","json":"/content/performance-trace-node-js-app-on-btp-with-dynatrace.json"},{"ref":"content:adding-custom-metrics-to-a-cap-application-using-cap-js-telementry-plugin-and-sa","name":"Adding Custom Metrics to a CAP application using cap-js/telementry plugin and SAP Cloud Logging","json":"/content/adding-custom-metrics-to-a-cap-application-using-cap-js-telementry-plugin-and-sa.json"},{"ref":"content:kyma-integration-with-sap-cloud-logging-part-2-let-s-ship-some-traces","name":"Kyma Integration with SAP Cloud Logging. Part 2: Let's ship some traces","json":"/content/kyma-integration-with-sap-cloud-logging-part-2-let-s-ship-some-traces.json"},{"ref":"content:monitoring-cap-container-metrics-with-sap-cloud-logging-service","name":"SAP Cloud Logging Serviceでコンテナメトリクスを監視する","json":"/content/monitoring-cap-container-metrics-with-sap-cloud-logging-service.json"},{"ref":"content:teched-2026-bt115","name":"Monitor your AI agents with the SAP Cloud ALM solution","json":"/content/teched-2026-bt115.json"}],"normative_context":[]}}