fix(tracing): actually set the tracing options in the root context#5118
fix(tracing): actually set the tracing options in the root context#5118kodiakhq[bot] merged 12 commits intomainfrom
Conversation
1f4e0f0 to
d5c81a2
Compare
|
This pull request adds or modifies JavaScript ( |
| @@ -1,6 +1,5 @@ | |||
| import { HoneycombSDK } from '@honeycombio/opentelemetry-node' | |||
There was a problem hiding this comment.
The HoneycombSDK provides a couple of things out the box which make the initialisation simpler.
| // Sets the current trace ID and span ID based on the options received | ||
| // this is used as a way to propagate trace context from Buildbot | ||
| trace.setSpanContext(context.active(), { | ||
| return trace.setSpanContext(context.active(), { |
There was a problem hiding this comment.
This is the actual change that ensures the traceId and spanId are using when initialising the first span.
| // If there's no `coreStepId` then this is a plugin execution | ||
| const spanName = `run-step-${coreStepId || 'plugin'}` |
There was a problem hiding this comment.
coreStepId only exists for internal steps. We replace this for plugin for plugin executions and we can use the package_name to aggregate on the package.
There was a problem hiding this comment.
do you mind giving more information about the plugin vs steps?
For example in this comment, it mentions we have core steps, build commands or plugin. I understand the meaning of the steps we do in buildbot, but not in here. Maybe this is a question too broad, so we can catch up on "Making Moves"
| // tracing.apiKey defaults to '-' else we'll get warning logs if not using | ||
| // honeycomb directly - https://github.com/honeycombio/honeycomb-opentelemetry-node/issues/201 |
There was a problem hiding this comment.
Honeycomb emits a set of console.warn logs we can't skip if we don't provide an apiKey - honeycombio/honeycomb-opentelemetry-node#201. This is why for production we pass -, since we're going to use a collector.
| serviceName: ROOT_PACKAGE_JSON.name, | ||
| traceExporter, | ||
| instrumentations: [new HttpInstrumentation()], | ||
| protocol: 'grpc', |
There was a problem hiding this comment.
Both in prod and locally we'll always use grpc
| import { HoneycombSDK } from '@honeycombio/opentelemetry-node' | ||
| import { context, trace, propagation, SpanStatusCode, diag, DiagLogLevel, DiagLogger } from '@opentelemetry/api' | ||
| import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-grpc' | ||
| import { HttpInstrumentation } from '@opentelemetry/instrumentation-http' |
There was a problem hiding this comment.
Couldn't manage to setup auto instrumentation. Seems like it's now working for esm but it's fairly recent and requires us to pass additional node flags:
- feat: ESM support for instrumentation open-telemetry/opentelemetry-js#3698
- https://github.com/open-telemetry/opentelemetry-js/blob/dccd90603bf52ba3b52eced9e8a6489bbdc78388/examples/esm-http-ts/package.json#L10
I've been thinking a bit about this and I think in the future we might want to have this tracing initialisation happen in a separate module we can use via node --require @netlify/tracing-initialisation ./call-neltify/build (or node --import once we move to node 20 I believe?) since it would:
- Allow us to out of the box use the same initialisation process for any node process we startup in Buildbot
- Make
@netlify/buildand other packages only depend on@opentelemetry/api(see fix(deps): update netlify packages cli#5826 (comment))
750837c to
edf7b83
Compare
| const { bugsnagKey, tracingOpts, debug, systemLogFile, ...flagsA } = normalizeFlags(flags, logs) | ||
| const errorMonitor = startErrorMonitor({ flags: { tracingOpts, debug, systemLogFile, ...flagsA }, logs, bugsnagKey }) | ||
| startTracing(tracingOpts, getSystemLogger(logs, debug, systemLogFile)) | ||
| const rootTracingContext = startTracing(tracingOpts, getSystemLogger(logs, debug, systemLogFile)) |
There was a problem hiding this comment.
would it be: rootTrace? is "Context" a thing in the JS/TS world?
scratch that, I just saw the context bit on the other file
There was a problem hiding this comment.
Context in this case is specifc to the open-telemetry JS implementation. In this case we're returning a context from:
build/packages/build/src/tracing/main.ts
Lines 44 to 51 in edf7b83
See:
Also:
This context will hold the specific traceId, spanId, etc. That we pass over from Buildbot.
🎉 Thanks for submitting a pull request! 🎉
Summary
Follow up to #5100. This time I actually tested the whole flow e2e:
For us to review and ship your PR efficiently, please perform the following steps:
we can discuss the changes and get feedback from everyone that should be involved. If you`re fixing a typo or
something that`s on fire 🔥 (e.g. incident related), you can skip this step.
your code follows our style guide and passes our tests.
A picture of a cute animal (not mandatory, but encouraged)