@sanjay-sde/cap-js-log-control
A CAP plugin for controlling CDS logger verbosity and OpenTelemetry DiagLogger noise, reducing log clutter so that real errors surface.
Facts
Where it sits
Who is behind it
In the atlas: maintains 1, contributes to 1@SanjayBabuSPmaintainer
Before choosing this
Conditions
LicenceSAP Developer License Agreement 3.2 CAP§ 1, 2, 3A cds-plugin is used with SAP CAP materials, or an artifact is explicitly identified as a CAP plugin or application.
- § 1 License. Productive customer applications are limited to SAP BTP or another SAP-licensed platform, and mass extraction to a non-SAP product is restricted except where solely required for SAP interoperability.
- § 2 Intellectual Property. The agreement retains SAP's rights in the covered materials and limits making APIs, tools or software available to third parties, while preserving ownership of customer applications subject to SAP's underlying rights.
- § 3 Artificial Intelligence Training. The agreement prohibits use of the covered materials and customer applications for training artificial-intelligence models or systems.
What it declares
Every artifact
- Type
- CDS plugin
- Origin
- Independently maintained
As a CDS plugin
- Declared for
- >=7.0.0
- Distributed through
- npm
Connections
Traces, metrics and correlation for a running service
Download
Install
npm add @sanjay-sde/cap-js-log-controlDerived from the package name. No recipe recorded; the README has the configuration.
README
quoted from SanjayBabuSP/cap-js-log-control under MIT, readcap-js-log-control
CAP plugin for controlling CDS logger verbosity and OpenTelemetry DiagLogger noise — reduce log clutter, surface real errors.
Problem
SAP CAP applications on Cloud Foundry generate excessive log noise that buries real errors:
odatalogger — logs every incoming OData request with full HTTP headers JSON blobsremotelogger — logs every outgoing remote service call with full headers- OpenTelemetry DiagLogger —
@cap-js/telemetryOTLP gRPC exporters emit diagnostic logs that bypasscds.logentirely
Before:
STDOUT {"level":"info","logger":"odata","msg":"POST /assets/$batch",...<3KB of headers>}
STDOUT {"level":"debug","logger":"remote","msg":"GET <api>/... Executing via @sap-cloud-sdk",...}
STDERR ExporterError: Export... failed [repeated 50x from OTel gRPC]
STDERR Error: The request has no query ← REAL error, buried
After:
STDERR Error: The request has no query ← now visible immediately
Installation
npm install cap-js-log-control
CAP auto-discovers the plugin via cds-plugin.js — no code changes needed.
Configuration
Quick Start (zero config)
The plugin works out of the box with sensible defaults:
odata→warnremote→warntelemetry→warn- OpenTelemetry DiagLogger →
ERROR
Plugin Config (cds.logControl)
Add to package.json or .cdsrc.json:
{
"cds": {
"logControl": {
"enabled": true,
"otelDiagLevel": "ERROR",
"levels": {
"odata": "warn",
"remote": "warn",
"telemetry": "warn"
}
}
}
}
Native CDS Log Levels (also supported)
You can also use the standard CDS log.levels format — the plugin reads both:
{
"cds": {
"[development]": {
"log": {
"levels": {
"odata": "error",
"remote": "error"
}
}
}
}
}
Priority:
cds.logControl.levelsoverridescds.log.levelswhen both are set for the same logger.
Per-Profile Overrides
Use CAP profiles to tune log levels per environment:
{
"cds": {
"logControl": {
"enabled": true,
"levels": {
"odata": "warn",
"remote": "warn"
}
},
"[development]": {
"logControl": {
"levels": {
"odata": "error",
"remote": "error"
}
}
},
"[production]": {
"logControl": {
"otelDiagLevel": "WARN"
}
}
}
}
Disable the Plugin
{
"cds": {
"logControl": {
"enabled": false
}
}
}
Config Reference
| Option | Type | Default | Description |
|---|---|---|---|
logControl.enabled | boolean | true | Master switch — set false to disable all log control |
logControl.levels | Record<string, string> | { odata: 'warn', remote: 'warn', telemetry: 'warn' } | Map of CDS logger names to log levels |
logControl.otelDiagLevel | string | 'ERROR' | OpenTelemetry DiagLogger level |
CDS Log Levels
silent | error | warn | info | debug | verbose | silly
OTel DiagLogger Levels
NONE | ERROR | WARN | INFO | DEBUG | VERBOSE | ALL
How It Works
- Runs at module load time — not inside a lifecycle hook — because logger noise starts during CDS bootstrap before
cds.once('served')fires. - Controls CDS loggers — calls
cds.log(name).setLevel(level)for each configured logger. - Controls OTel DiagLogger — sets
diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.ERROR)to suppress OTLP exporter retry chatter. - Does NOT redirect stdout/stderr — all logs still flow to CF Loggregator for cloud logging.
- Does NOT patch
console.log— only reduces log generation at the source.
What This Plugin Does NOT Do
- Does NOT redirect or wrap
process.stdout/process.stderr - Does NOT patch
console.log/console.error - Does NOT affect cloud logging — all generated logs still flow to CF Loggregator
- Does NOT disable
@cap-js/telemetryor OTLP exporters — only reduces their diagnostic output
Development
npm install
npm run build
npm test
License
History
Others providing
Compare all 9 on the Telemetry page →- com.sap.cds:cds-services-bomcom.sap.cds:cds-services-bomThe Maven bill of materials for CAP Java, pinning every com.sap.cds module in a release, from the API and core runtime to the Spring Boot starters and the CQN engine, to the same version.sap official, capMaven bill of materials pinning CAP Java module versions
- @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, capBusiness-level metrics from CDS annotations via @cap-js/telemetry
- @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, capOpenTelemetry instrumentation for CAP services
- cds-cachingcds-cachingA caching plugin for CAP covering queries, requests, function results and remote service responses, through a read-through API or @cache annotations, with HCQL and MCP support.independent, capCAP caching plugin for query results and remote service responses
- 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, capPolicy enforcement and field masking for MCP-enabled CAP apps
- @sap-ux/telemetry@sap-ux/telemetryLibrary for sending usage telemetry datasap official, capLibrary for sending usage telemetry data
- 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, capUI5 frontend performance and error capture for CAP
- opentelemetry-cdsopentelemetry-cdsopentelemetry support for CDS nodejs runtimeindependent, capOpenTelemetry support for the CDS Node.js runtime
Details
Sources
Sources are graph entities: the same page may back several entries, and an unreachable source flags every row that rests on it.
Compatibility and provenance
History in the atlas
- what it does for telemetry
- First seen.
For your agent
- Ref
artifact:sanjay-sde-cap-js-log-control- JSON
- /artifacts/sanjay-sde-cap-js-log-control.json
- MCP
- Connecting an agent