Files
Danijel Martinek 14762d4ba0 docs(library-decisions): backfill socketRisk in 2026-05-14 traces
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.
2026-05-20 17:02:13 +02:00

88 lines
3.4 KiB
Markdown

---
package: "@opentelemetry/instrumentation-http"
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/instrumentation-http license
- npm view @opentelemetry/instrumentation-http version
- pnpm audit --audit-level=moderate
accepted-cves: []
---
## Filter: license
<!-- Result: Apache-2.0 -->
`npm view @opentelemetry/instrumentation-http license` returns `Apache-2.0`. Apache-2.0 is on the allowlist.
## Filter: types
<!-- Result: native -->
`@opentelemetry/instrumentation-http` 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 as the first-party HTTP instrumentation plugin. The 0.55.x line is current and tracks the OTel SDK release cycle.
## Filter: boundary-fit
<!-- Result: pass -->
ADR-017 §11 explicitly enables HTTP auto-instrumentation in `initOtelServerNode`. The plugin is configured with query-string stripping on `http.url.path` and a path ignore list (`/_health`, `/_otel-export`) to prevent noise and PII leakage. Restricted to `core-shared/instrumentation/otel/` init paths.
## Filter: shadow-check
<!-- Result: pass -->
`@opentelemetry/instrumentation-http` is the standard OTel HTTP auto-instrumentation. No competing HTTP span emitter is present in the workspace.
## Filter: eu-residency
<!-- Result: n/a -->
`@opentelemetry/instrumentation-http` is a pure instrumentation plugin with no independent data transmission. Spans it emits are routed through the configured OTel exporter (Sentry via `@sentry/opentelemetry`). EU residency is governed by the exporter configuration.
## Filter: cve-scan
<!-- Result: clean -->
`pnpm audit --audit-level=moderate` reports no advisories against `@opentelemetry/instrumentation-http` at the time of this trace.
## Filter: named-consumer
<!-- Result: pass -->
`packages/core-shared/src/instrumentation/otel/init-otel-server-node.ts` registers `HttpInstrumentation` with query-string redaction and path ignore rules (ADR-017 §11). This eliminates manual span creation for every incoming HTTP request and outgoing HTTP call.
## Prompt: replaces
Manual `tracer.startSpan()` / `tracer.endSpan()` wrapping around every `http.IncomingMessage` handler and `http.request()` call site. The auto-instrumentation patches Node.js core `http` and `https` modules to emit spans automatically.
## Prompt: migration-cost-out
Low. `HttpInstrumentation` is registered in one init file. Removing it means disabling the plugin registration and optionally adding manual spans at HTTP boundaries — localized to the SDK init and any call sites that relied on automatic context propagation.
## Prompt: alternatives-considered
1. **Manual HTTP spans** — No plugin needed, but requires wrapping every `http.request` and route handler explicitly. Rejected: high boilerplate, easy to miss call sites, loses automatic context propagation headers.
2. **`dd-trace` HTTP plugin** — Datadog-specific. Rejected in ADR-017: vendor lock-in; OTel plugin achieves the same coverage with vendor-neutral output.
See ADR-017 for the full decision rationale.