Skip to content
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

Plugins refactoring - new instrumentation package for plugins #1540

Merged
merged 19 commits into from
Sep 30, 2020

Conversation

obecny
Copy link
Member

@obecny obecny commented Sep 16, 2020

!Important! -> the only thing that left is test coverage, but I want this to be reviewed before adding many more tests as especially the tests for node will require more effort, so would rather avoid massive refactoring if there is anything here that will need to be changed before that.

This is continuation of plugin refactoring. #1449

This new plugin base is completely decoupled from the SDK and relies only on the API. After #1448 plugins using this base class will be able to be fully standalone, and will support instrumenting modules very early in the load process, even before the tracer provider is set up.

  • Solves load order issue
  • Solves yarn pnp issue by using a more direct dependency model
  • Removes need for plugin manager
  • One instrumentation can patch multiple modules
  • Can use different plugins for different versions of a module
  • Supports tracers and meters
  • Support for patching multiple files before they are loaded by main module. For example graphql doesn't allow to patch main file as it defines all methods as read only so they cannot be override. This will fix the problem allowing to patch files and methods before.

For some time we will allow for 2 plugins types until all plugins will be moved to use new class.

FYI
After this change the plugins http and https can be merged into one plugin too

@codecov
Copy link

codecov bot commented Sep 16, 2020

Codecov Report

Merging #1540 into master will decrease coverage by 0.12%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##           master    #1540      +/-   ##
==========================================
- Coverage   93.18%   93.05%   -0.13%     
==========================================
  Files         156      158       +2     
  Lines        4854     4882      +28     
  Branches      986      988       +2     
==========================================
+ Hits         4523     4543      +20     
- Misses        331      339       +8     
Impacted Files Coverage Δ
...entelemetry-instrumentation/src/instrumentation.ts 63.63% <63.63%> (ø)
packages/opentelemetry-api/src/trace/NoopLogger.ts 100.00% <100.00%> (ø)

@obecny obecny self-assigned this Sep 17, 2020
Copy link
Member

@dyladan dyladan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really solid. I left some comments mostly to do with the README since I think writing instrumentation will be difficult for people their first time. The actual implementation is more or less exactly what I was thinking.

packages/opentelemetry-instrumentation/README.md Outdated Show resolved Hide resolved
packages/opentelemetry-instrumentation/README.md Outdated Show resolved Hide resolved
packages/opentelemetry-instrumentation/README.md Outdated Show resolved Hide resolved
packages/opentelemetry-instrumentation/README.md Outdated Show resolved Hide resolved
@dyladan
Copy link
Member

dyladan commented Sep 22, 2020

LGTM right now. Are you planning on getting reviews on this and merging, then doing tests in a follow up PR?

@obecny
Copy link
Member Author

obecny commented Sep 22, 2020

LGTM right now. Are you planning on getting reviews on this and merging, then doing tests in a follow up PR?

Ideally I would add more tests in following up PR after getting more reviews too. It will be easier also to add tests then and make some adjustments if required as the PR is already not the smallest one so might be harder to make reviews with more code on board.

@obecny
Copy link
Member Author

obecny commented Sep 22, 2020

@dyladan just to be sure, the NoopLogger can stay in api right ?

@dyladan
Copy link
Member

dyladan commented Sep 22, 2020

@dyladan just to be sure, the NoopLogger can stay in api right ?

I think that's fine, but it is a little weird to me that the logger is only used in the SDK but has a noop in the API. I think I am fine either way on this one. The biggest strike against for me is that it is harder to remove things from the API later if we decide it was a bad idea, but easy to add it later if it causes a problem not having it.

@obecny
Copy link
Member Author

obecny commented Sep 22, 2020

@dyladan just to be sure, the NoopLogger can stay in api right ?

I think that's fine, but it is a little weird to me that the logger is only used in the SDK but has a noop in the API. I think I am fine either way on this one. The biggest strike against for me is that it is harder to remove things from the API later if we decide it was a bad idea, but easy to add it later if it causes a problem not having it.

It will be used now in Instrumentation so all plugins will need that

Copy link
Member

@dyladan dyladan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. It may need some modifications as we actually start writing plugins, but I think we can merge this and try to port one of the plugins or write a new one.

@dyladan dyladan added the enhancement New feature or request label Sep 23, 2020
Copy link
Member

@mwear mwear left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One comment, but otherwise, LGTM.

packages/opentelemetry-instrumentation/README.md Outdated Show resolved Hide resolved
@obecny obecny changed the title Plugins Plugins refactoring - new instrumentation package for plugins Sep 29, 2020
@obecny obecny merged commit c6c993b into open-telemetry:master Sep 30, 2020
@obecny obecny deleted the plugins branch September 30, 2020 12:10
@sk- sk- mentioned this pull request Dec 10, 2020
dyladan added a commit to dyladan/opentelemetry-js that referenced this pull request Sep 9, 2022
…elemetry#1540)

* feat: add a new plugin base decoupled from the sdk

* chore: web and node version that supports patching more files

* chore: updating readme

* chore: lint

* chore: missing noop logger

* chore: linting

* chore: updating readme with info about many modules

* chore: supporting calling enable and disable multiple times for node plugins

* chore: simplifying readme example

* chore: reviews

* chore: moving interface Instrumentation to package instrumentation

* chore: adding function for safe executing in plugins

* chore: fixing typo

Co-authored-by: Daniel Dyla <[email protected]>
dyladan added a commit to dyladan/opentelemetry-js that referenced this pull request Sep 9, 2022
…elemetry#1540)

* feat: add a new plugin base decoupled from the sdk

* chore: web and node version that supports patching more files

* chore: updating readme

* chore: lint

* chore: missing noop logger

* chore: linting

* chore: updating readme with info about many modules

* chore: supporting calling enable and disable multiple times for node plugins

* chore: simplifying readme example

* chore: reviews

* chore: moving interface Instrumentation to package instrumentation

* chore: adding function for safe executing in plugins

* chore: fixing typo

Co-authored-by: Daniel Dyla <[email protected]>
pichlermarc pushed a commit to dynatrace-oss-contrib/opentelemetry-js that referenced this pull request Dec 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants