[go: up one dir, main page]

Workers: propagate Opentelemetry scopes on requests

What

This MR attach optional scope when pushing requests to the worker. This is a specialization of !16139 (closed) for Opentelemetry that avoids any API change.

Why

When profiling, especially to try to have consistent traces with Opentelemetry, it can be useful to propagate the scope of the current trace. Opentelemetry works with a "global" context that contains its current "scope": the current trace id, the last "span", etc. When pushing the request in a worker's queue, this request is handled concurrently in another context and the scope is lost.

How

  • Each message would contain its scope.
  • When pushing a request, take the scope and put it in the message.
  • When handling a new message, take its scope and update the "global context" of Opentelemetry.

It doesn't require an API change of the worker, and the worker is responsible for maintaining the scope when the profiler is enabled.

Manually testing the MR

This MR is based on !16040 (merged), you can reuse the instructions to test it and see what it changes exactly: image

As you can see, now Validator.inject is directly linked to Prevalidator.on_inject, as it can successfully go through the worker barrier. The trace id was already the same as its ID is computed from the operation hash. It wouldn't be useful anymore.

Checklist

  • Document the interface of any function added or modified (see the coding guidelines)
  • Document any change to the user interface, including configuration parameters (see node configuration)
  • Provide automatic testing (see the testing guide).
  • For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
  • Select suitable reviewers using the Reviewers field below.
  • Select as Assignee the next person who should take action on that MR
Edited by Pierrick Couderc

Merge request reports

Loading