-
Notifications
You must be signed in to change notification settings - Fork 83
fix(tracing): actually set the tracing options in the root context #5118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
// 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 return trace.setSpanContext(context.active(), { traceId: options.traceId, spanId: options.parentSpanId, traceFlags: options.traceFlags, isRemote: true, })
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)