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

feat: add OTEL_NO_PATCH_MODULES #1153

Merged
merged 13 commits into from
Jun 12, 2020

Conversation

markwolff
Copy link
Member

Which problem is this PR solving?

Short description of the changes

  • Reads new environment variable OPENTELEMETRY_NO_PATCH_MODULES in PluginLoader to selectively disable plugins for certain modules
  • Environment variable is parsed as a comma separated list of library names, e.g https,mongodb,@grpc/grpc-js will disable plugins (if installed) for these 3 modules

@codecov
Copy link

codecov bot commented Jun 9, 2020

Codecov Report

Merging #1153 into master will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1153      +/-   ##
==========================================
+ Coverage   92.33%   92.37%   +0.03%     
==========================================
  Files         119      119              
  Lines        3433     3447      +14     
  Branches      696      700       +4     
==========================================
+ Hits         3170     3184      +14     
  Misses        263      263              
Impacted Files Coverage Δ
...telemetry-node/src/instrumentation/PluginLoader.ts 93.82% <100.00%> (+1.28%) ⬆️

@obecny
Copy link
Member

obecny commented Jun 9, 2020

@open-telemetry/javascript-maintainers & @open-telemetry/javascript-approvers I think we will soon have more and more new env variables we already have 3 PR opened all of them implementing more less the same functionality. I think we should unify all the environment properties to keep them in one place and have some environment class that will be created using the platform approach to either read values from process.env, global, window etc. and then to have enum for all env properties. We should unify this the sooner the better.
the mentioned PR:
#1069
#974

@dyladan
Copy link
Member

dyladan commented Jun 9, 2020

Can we add a special case of some kind which disables all? Possibly * or something

edit: * might not be great because shell expansion may interfere

@markwolff
Copy link
Member Author

I think we will soon have more and more new env variables we already have 3 PR opened all of them implementing more less the same functionality. I think we should unify all the environment properties to keep them in one place and have some environment class that will be created using the platform approach to either read values from process.env, global, window etc. and then to have enum for all env properties. We should unify this the sooner the better.

@obecny I agree. Something like getPlatformVariable(name: PlatformVariableEnum) seems good to me.

Can we add a special case of some kind which disables all? Possibly * or something

@dyladan do you know where shell expansion would be an issue? I tried on a few different environments and didn't run into any issues.

@dyladan
Copy link
Member

dyladan commented Jun 9, 2020

Can we add a special case of some kind which disables all? Possibly * or something

@dyladan do you know where shell expansion would be an issue? I tried on a few different environments and didn't run into any issues.

I was just envisioning a scenario where someone does like VAR=* npm start and somehow their shell expands the * to be all the files in the directory. Maybe this isn't a concern, I'm just not a shell expansion guru.

@@ -46,6 +52,14 @@ function filterPlugins(plugins: Plugins): Plugins {
}, {});
}

function getIgnoreList(): string[] | '*' {
const envIgnoreList: string = process.env[envPluginDisabledList] || '';
if (envIgnoreList === '*') {
Copy link
Member

Choose a reason for hiding this comment

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

Can we pull this out to a constant?

Copy link
Member Author

Choose a reason for hiding this comment

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

Updated

`OPENTELEMETRY_NO_PATCH_MODULES` accepts a
comma separated list of module names to disabled specific plugins.
The names should match what you use to `require` the module into your application.
For example, `OPENTELEMETRY_PATCH_MODULES=pg,https` will disable the postgres plugin and the https plugin. To disable **all** plugins, set the environment variable to `*`.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
For example, `OPENTELEMETRY_PATCH_MODULES=pg,https` will disable the postgres plugin and the https plugin. To disable **all** plugins, set the environment variable to `*`.
For example, `OPENTELEMETRY_NO_PATCH_MODULES=pg,https` will disable the postgres plugin and the https plugin. To disable **all** plugins, set the environment variable to `*`.

Copy link
Member Author

Choose a reason for hiding this comment

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

updated. thanks!

Copy link
Member

@mayurkale22 mayurkale22 left a comment

Choose a reason for hiding this comment

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

Added a minor comment, otherwise LGTM

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.

LGTM. Just one comment.

We currently have an OTEL_RESOURCE_LABELS environment variable here. It appears from open-telemetry/opentelemetry-specification#572 that most languages are using OTEL_ as a prefix. Should we consider calling this OTEL_NO_PATCH_MODULES?

@markwolff
Copy link
Member Author

LGTM. Just one comment.

We currently have an OTEL_RESOURCE_LABELS environment variable here. It appears from open-telemetry/opentelemetry-specification#572 that most languages are using OTEL_ as a prefix. Should we consider calling this OTEL_NO_PATCH_MODULES?

Yes this is a good point, naming alignment would be great. I think shorter is better. @open-telemetry/javascript-approvers

Copy link
Member

@vmarchaud vmarchaud left a comment

Choose a reason for hiding this comment

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

lgtm

@dyladan dyladan merged commit 8c56442 into open-telemetry:master Jun 12, 2020
@dyladan dyladan added the enhancement New feature or request label Jun 12, 2020
@markwolff markwolff changed the title feat: add OPENTELEMETRY_NO_PATCH_MODULES feat: add OTEL_NO_PATCH_MODULES Jun 17, 2020
@markwolff markwolff deleted the add-plugin-ignore-env-var branch June 17, 2020 19:00
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.

Allow to disable plugin via environment variable
6 participants