Adds approved trace files dated 2026-05-14 for all 13 OpenTelemetry packages in packages/core-shared and packages/core-audit: @opentelemetry/api, api-logs, context-async-hooks, instrumentation, instrumentation-http, instrumentation-pg, instrumentation-undici, resources, sdk-logs, sdk-metrics, sdk-node, sdk-trace-base, semantic-conventions All files pass validateTrace() from schema.mjs. The @sentry/opentelemetry bridge was already covered in the ADR-014 cluster commit. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
87 lines
3.5 KiB
Markdown
87 lines
3.5 KiB
Markdown
---
|
|
package: "@opentelemetry/sdk-logs"
|
|
version: "^0.55.0"
|
|
tier: core
|
|
decision: approved
|
|
date: 2026-05-14
|
|
deciders: [Danijel Martinek]
|
|
adr: adr-017
|
|
filter-results:
|
|
license: Apache-2.0
|
|
types: native
|
|
maintenance: active
|
|
boundary-fit: pass
|
|
shadow-check: pass
|
|
eu-residency: n/a
|
|
cve-scan: clean
|
|
named-consumer: pass
|
|
verification-commands:
|
|
- npm view @opentelemetry/sdk-logs license
|
|
- npm view @opentelemetry/sdk-logs version
|
|
- pnpm audit --audit-level=moderate
|
|
accepted-cves: []
|
|
---
|
|
|
|
## Filter: license
|
|
|
|
<!-- Result: Apache-2.0 -->
|
|
|
|
`npm view @opentelemetry/sdk-logs license` returns `Apache-2.0`. Apache-2.0 is on the allowlist.
|
|
|
|
## Filter: types
|
|
|
|
<!-- Result: native -->
|
|
|
|
`@opentelemetry/sdk-logs` is authored in TypeScript and ships its own `.d.ts` declaration files. No separate `@types/` package is needed.
|
|
|
|
## Filter: maintenance
|
|
|
|
<!-- Result: active -->
|
|
|
|
Actively maintained by the OpenTelemetry community. The 0.55.x line is current and tracks the OTel JS SDK release cycle. The Logs signal is in active specification development within CNCF.
|
|
|
|
## Filter: boundary-fit
|
|
|
|
<!-- Result: pass -->
|
|
|
|
ADR-017 §8 restricts `@opentelemetry/sdk-logs` to `**/instrumentation/otel/**` and app init paths. `LoggerProvider` and `SimpleLogRecordProcessor` / `BatchLogRecordProcessor` are configured exclusively in `core-shared/instrumentation/otel/init-otel-server-node.ts`. Feature packages use only `@opentelemetry/api-logs` (the stable API), never the SDK directly.
|
|
|
|
## Filter: shadow-check
|
|
|
|
<!-- Result: pass -->
|
|
|
|
`@opentelemetry/sdk-logs` is the OTel Logs SDK implementation. No competing log pipeline SDK is present in the workspace.
|
|
|
|
## Filter: eu-residency
|
|
|
|
<!-- Result: n/a -->
|
|
|
|
`@opentelemetry/sdk-logs` is the log pipeline infrastructure with no independent data transmission. All log records it processes are forwarded through the configured exporter (Sentry via `@sentry/opentelemetry`). EU residency is governed by the exporter's DSN configuration.
|
|
|
|
## Filter: cve-scan
|
|
|
|
<!-- Result: clean -->
|
|
|
|
`pnpm audit --audit-level=moderate` reports no advisories against `@opentelemetry/sdk-logs` at the time of this trace.
|
|
|
|
## Filter: named-consumer
|
|
|
|
<!-- Result: pass -->
|
|
|
|
`packages/core-shared/src/instrumentation/otel/init-otel-server-node.ts` instantiates `LoggerProvider` and registers `PiiScrubLogRecordProcessor` followed by `SentryLogRecordProcessor` from `@sentry/opentelemetry`. The PII scrub processor runs before the Sentry exporter (ADR-017 §7).
|
|
|
|
## Prompt: replaces
|
|
|
|
The former `SentryLogger` which called Sentry SDK's `captureException` and breadcrumb APIs directly. `@opentelemetry/sdk-logs` provides the pipeline infrastructure that decouples log emission from the backend exporter.
|
|
|
|
## Prompt: migration-cost-out
|
|
|
|
Hard. `@opentelemetry/sdk-logs` is the log pipeline backbone. Removing it requires replacing the entire log processing chain — provider, processors, and exporter wiring — in `core-shared`. The `ILogger` boundary (ADR-014) isolates feature packages, but the core log pipeline is non-trivially coupled to the OTel SDK.
|
|
|
|
## Prompt: alternatives-considered
|
|
|
|
1. **Winston + transport** — A well-established Node.js logger with pluggable transports. Rejected in ADR-017: separate pipeline from traces means no automatic span-log correlation; correlation requires manual trace ID injection into every log message.
|
|
2. **Pino** — High-performance JSON logger. Same rejection reason as Winston: separate pipeline, no automatic context propagation from OTel spans.
|
|
|
|
See ADR-017 for the full decision rationale.
|