Telemetry
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.
Showing artifacts, examples and content with confirmed Java applicability. View All CAP
Overview
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.
Not covered: 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.
A cds-plugin loads into the Node.js runtime, so the community cds-plugins on the CAP door sit on the Node.js flavor.
No community artifact is documented here.
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.
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.
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.
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.
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.
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.
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