💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• run module tests for <modules> : Run TAV tests for one or more modules, where <modules> can be either a comma separated list of modules (e.g. memcached,redis) or the string literal ALL to test all modules

• run benchmark tests : Run the benchmark test only.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

The user docs and changelog entry remain, but otherwise this is ready for review.

This may be a good reason for us to eventually cordon the OpenTelemetry Bridge off into its own module that users can add to their project if they want. That would keep the 2.6MB out of the agent proper.

I'd considered a separate package, but ultimately rejected it. Here are my notes from that:

Notes on whether to have a separate package for the OTel Bridge

(For comparison, the old OpenTracing bridge is/was a separate package.)

Separate package, e.g. '@elastic/opentelemetry-sdk-node' or whatever name, or just a part of current 'elastic-apm-node'?

Pros (for a separate package):

• Package size. npm install @opentelemetry/api adds about 1.4M to our current install size of ~16M. While not a huge concern, this could be relevant for Lambda environments where the size of all layers is limited.
• Supporting multiple major versions of OpenTelemetry is cleaner. If/when @opentelemetry/api@2.x is released, to support both with a given release of the APM Agent would require the agent (a) installing both major vers of the OTel API package and (b) registering global providers for both major versions.
• Might facilitate writing the otel bridge in TypeScript, making the whole repo a TypeScript project. This assumes writing this in TypeScript is considered a good/helpful thing. :) The type checking against OTel API interfaces would likely be nice. Compilation/source-maps etc. would be a pain... but that's mostly learning curve.

Cons:

• Will it be possible to implement the Bridge using just the public APM agent API? Seems unlikely. Do we need to restrict to a public API? For this reason we are using the same package. There is a fair amount of internal API usage for bridging.
• Maintaining more packages can be a pain. For example, fixes/changes to dependent behaviour can often lead to two PRs (one in each repo) and release coordination, rather than just a single PR to one repo. (There are monorepos. Possible, but might be a big change.)

Pro or Con? Not sure:

• Would OTel-specific compatiblity tests be easier in a separate package and repo?
• What user experience do we want for users that are going to use the OTel Bridge? If the eventual goal or expectation is OTel API preference, then the "start the agent as an OTel provider" will become more important. Is that user experience nicer or more obtuse with a separate package? If the API available from require('whatever our package name') is just about OTel APIs, then maybe that is less confusing for the user.
• Adding more packages that can be an entry point for the agent can be confusing for users, take this state, for example:

  @opentelemetry/node
  @opentelemetry/api
  @opentelemetry/core
  @opentelemetry/auto-instrumentations-node
  @opentelemetry/sdk-node
  @opentelemetry/node-sdk
  @opentelemetry/sdk-trace-node
  @sumologic/opentelemetry-node
  lightstep-opentelemetry-launcher-node
  @aspecto/opentelemetry
  @newrelic/telemetry-sdk
  @splunk/otel
  

... once ...

1. Documented the new configuration for enabling/disabling

Added in 8ed5623

Rendered version here: https://apm-agent-nodejs_2641.docs-preview.app.elstc.co/diff
The main added doc page is: https://apm-agent-nodejs_2641.docs-preview.app.elstc.co/guide/en/apm/agent/nodejs/master/opentelemetry-bridge.html