The Socket supply-chain filter (ADR-023) was added after the initial library-trace backfill, leaving the 36 traces dated 2026-05-14 without the socketRisk filter-results field the trace schema now expects. Backfill it as `clean` — all are mainstream packages, and the weekly revalidation cron re-verifies supply-chain status.
88 lines
3.4 KiB
Markdown
88 lines
3.4 KiB
Markdown
---
|
|
package: "@opentelemetry/api-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
|
|
socketRisk: clean
|
|
verification-commands:
|
|
- npm view @opentelemetry/api-logs license
|
|
- npm view @opentelemetry/api-logs version
|
|
- pnpm audit --audit-level=moderate
|
|
accepted-cves: []
|
|
---
|
|
|
|
## Filter: license
|
|
|
|
<!-- Result: Apache-2.0 -->
|
|
|
|
`npm view @opentelemetry/api-logs license` returns `Apache-2.0`. Apache-2.0 is on the allowlist.
|
|
|
|
## Filter: types
|
|
|
|
<!-- Result: native -->
|
|
|
|
`@opentelemetry/api-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 under the CNCF as part of the unified OTel JS repository. Versioned alongside the SDK packages; the 0.55.x line is current and aligns with the SDK release cycle.
|
|
|
|
## Filter: boundary-fit
|
|
|
|
<!-- Result: pass -->
|
|
|
|
ADR-017 §4 designates `@opentelemetry/api-logs` as the Logs API for `OtelLogger` in `core-shared/instrumentation/`. Feature packages interact with logging only via the `ILogger` interface (ADR-014 R34); they do not import this package directly.
|
|
|
|
## Filter: shadow-check
|
|
|
|
<!-- Result: pass -->
|
|
|
|
`@opentelemetry/api-logs` is the only OTel Logs API in the workspace. It complements `@opentelemetry/api` (traces) and `@opentelemetry/sdk-metrics` (metrics) to form the complete three-signal OTel pipeline. No competing logging API is present.
|
|
|
|
## Filter: eu-residency
|
|
|
|
<!-- Result: n/a -->
|
|
|
|
`@opentelemetry/api-logs` is a pure API package with no network communication or data transmission. EU residency does not apply.
|
|
|
|
## Filter: cve-scan
|
|
|
|
<!-- Result: clean -->
|
|
|
|
`pnpm audit --audit-level=moderate` reports no advisories against `@opentelemetry/api-logs` at the time of this trace.
|
|
|
|
## Filter: named-consumer
|
|
|
|
<!-- Result: pass -->
|
|
|
|
`packages/core-shared/src/instrumentation/otel/otel-logger.ts` implements `ILogger` using `@opentelemetry/api-logs` to emit log records via the OTel Logs API (ADR-017 §4). `packages/core-audit` also depends on it for structured audit log emission.
|
|
|
|
## Prompt: replaces
|
|
|
|
`OtelLogger` replaces the former `SentryLogger` which called Sentry SDK methods directly. `@opentelemetry/api-logs` provides the vendor-neutral log emission surface so that the downstream exporter (Sentry via `@sentry/opentelemetry`) can be swapped without touching logger code.
|
|
|
|
## Prompt: migration-cost-out
|
|
|
|
Hard. `@opentelemetry/api-logs` is called in every `OtelLogger` log-emission path in `core-shared`. Moving to a different logs API (e.g., a custom abstraction) would require rewriting both the logger implementation and the OTel SDK initialization. The `ILogger` interface boundary (ADR-014) limits blast radius to `core-shared`.
|
|
|
|
## Prompt: alternatives-considered
|
|
|
|
1. **Winston / Pino as the log API** — Considered before ADR-017. Rejected because a separate log library alongside OTel would create a split-pipeline problem: traces and logs would travel through different channels, losing correlation.
|
|
2. **Sentry SDK breadcrumb API directly** — Rejected in ADR-017: direct Sentry coupling prevents vendor swap without code changes.
|
|
|
|
See ADR-017 for the full decision rationale.
|