Repository navigation
Conversation
Adds experimental OpenTelemetry tracing support, as described in the included docs. Tracing is activated via environment variables only and requires the --experimental-otel flag. There is no programmatic API yet. Custom instrumentation is not supported. Assisted-by: pi:glm-5.3 Signed-off-by: Bryan English <bryan@bryanenglish.com>
|
Review requested:
|
| ### `NODE_OTEL_ENDPOINT=url` | ||
|
|
||
| <!-- YAML | ||
| added: REPLACEME | ||
| --> | ||
|
|
||
| > Stability: 1 - Experimental | ||
|
|
||
| When set to a non-empty value while the [`--experimental-otel`][] flag is | ||
| enabled, activates the built-in OpenTelemetry tracing subsystem and directs | ||
| spans to the specified OTLP/HTTP collector endpoint. The endpoint must be | ||
| the base URL of the collector: any path present in the endpoint is | ||
| replaced with `/v1/traces`, and an endpoint that already ends with | ||
| `/v1/traces` is used as is. If `NODE_OTEL` is also set, `NODE_OTEL_ENDPOINT` | ||
| takes precedence for the endpoint. See the [OpenTelemetry][] documentation | ||
| for details. |
There was a problem hiding this comment.
Probably should also mention the default is http://localhost:4318?
| filter); | ||
| } | ||
|
|
||
| function start(options = { __proto__: null }) { |
There was a problem hiding this comment.
Require and use kEmptyObject from internal/util?
| function start(options = { __proto__: null }) { | |
| function start(options = kEmptyObject) { |
| ### `NODE_OTEL_ENDPOINT` | ||
|
|
||
| When set to a non-empty value, activates the tracing subsystem and directs | ||
| spans to the specified OTLP collector endpoint. The endpoint should be the | ||
| base URL of an OTLP/HTTP collector (e.g. `http://localhost:4318`) without | ||
| a path: any path present in the endpoint is replaced with `/v1/traces`, | ||
| and an endpoint that already ends with `/v1/traces` is used as is. | ||
|
|
||
| ```bash | ||
| NODE_OTEL_ENDPOINT=http://collector.example.com:4318 \ | ||
| node --experimental-otel app.js | ||
| ``` |
There was a problem hiding this comment.
Here too, I think it should explicitly mention the default, even though the NODE_OTEL section mentions its default
Maybe
| ### `NODE_OTEL_ENDPOINT` | |
| When set to a non-empty value, activates the tracing subsystem and directs | |
| spans to the specified OTLP collector endpoint. The endpoint should be the | |
| base URL of an OTLP/HTTP collector (e.g. `http://localhost:4318`) without | |
| a path: any path present in the endpoint is replaced with `/v1/traces`, | |
| and an endpoint that already ends with `/v1/traces` is used as is. | |
| ```bash | |
| NODE_OTEL_ENDPOINT=http://collector.example.com:4318 \ | |
| node --experimental-otel app.js | |
| ``` | |
| ### `NODE_OTEL_ENDPOINT` | |
| When set to a non-empty value, activates the tracing subsystem and directs | |
| spans to the specified OTLP collector endpoint. The endpoint should be the | |
| base URL of an OTLP/HTTP collector (defaults to `http://localhost:4318`) without | |
| a path: any path present in the endpoint is replaced with `/v1/traces`, | |
| and an endpoint that already ends with `/v1/traces` is used as is. | |
| ```bash | |
| NODE_OTEL_ENDPOINT=http://collector.example.com:4318 \ | |
| node --experimental-otel app.js | |
| ``` |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #66587 +/- ##
==========================================
- Coverage 92.79% 90.44% -2.35%
==========================================
Files 422 796 +374
Lines 193669 277600 +83931
Branches 29886 53321 +23435
==========================================
+ Hits 179712 251082 +71370
- Misses 13630 16921 +3291
- Partials 327 9597 +9270
🚀 New features to boost your workflow:
|
jasnell
left a comment
There was a problem hiding this comment.
First pass... Generally looks reasonable. Main concern is on instrumentation cost. Left a couple comments.
| } | ||
|
|
||
| setAttribute(key, value) { | ||
| this.#attributes[key] = value; |
There was a problem hiding this comment.
#attributes is going to be put into a slow dictionary mode with a internal shape transition every time an attribute is set... Meaning this is going to have a non-trivial cost.
Could this use a SafeMap instead?
Obviously that makes getAttributes trickier below but I would assume that setAttribute is the hotter path?
| } | ||
|
|
||
| addEvent(name, attributes) { | ||
| ArrayPrototypePush(this.#events, { |
There was a problem hiding this comment.
How many events might we expect? If it's a lot, or completely unbounded, this becomes quadratic after a while.
| The subsystem is independent of the OpenTelemetry JavaScript packages. It | ||
| is not interoperable with `@opentelemetry/api`, and spans created by one | ||
| are not visible to the other. Running both in the same process produces | ||
| duplicate trace and span IDs. The built-in instrumentation also | ||
| overwrites the `traceparent` (and, when present, `tracestate`) header on | ||
| outgoing HTTP requests, discarding whatever a userland propagator may | ||
| have set. Users should run either the built-in subsystem or a userland | ||
| OpenTelemetry SDK, not both. |
There was a problem hiding this comment.
Then I wonder what the purpose of this is. From my perspective, this feature should work in one of two ways:
- Provides an implementation of the API such that compliant instrumentations can register with it and it delivers the appropriate signals data to a collector.
- Registers with whatever OTEL implementation is present such that the signals data is inlined correctly.
With the caveats highlighted in this paragraph, I'm just not clear what this accomplishes.
Adds experimental OpenTelemetry tracing support, as described in the included docs. Tracing is activated via environment variables only and requires the --experimental-otel flag.
There is no programmatic API yet. Custom instrumentation is not supported.
Assisted-by: pi:glm-5.3
This is a re-hash of #61907 restricting it to the OOTB behaviour only, leaving any API surface as an exercise for future PRs (and decisions around them). All configuration is currently through env vars. Most if not all still-relevant review comments from the previous PR are addressed here. In addition, a benchmark is added to measure future improvements.
Metrics and logging signals are also left to future PRs.