Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Vendor instrumentations #280

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.

Sign up for GitHub

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

Jump to bottom
Merged
jeremydvoss merged 12 commits into from
Jun 12, 2023
Merged

Vendor instrumentations #280

jeremydvoss merged 12 commits into from
Jun 12, 2023

Conversation

@jeremydvoss
Copy link
Member

@jeremydvoss jeremydvoss commented May 18, 2023 •
edited
Loading

Vendored with the following logic:

  1. Checked out versions 0.38b0 of instrumentations and their dependencies (asgi, dbapi, wsgi, util-http). One dependency, wrapt, was just added as a dependency of the distro.
  2. Copied source code to vendor folder. opentelemetry.X -> azure.monitor.opentelemetry.vendor.opentelemetry.X)
  3. Updated import statements
  4. Copied optional dependencies for each instrumentation to _SUPPORTED_INSTRUMENTED_LIBRARIES_TO_INSTRUMENTS_MAP
  5. Copied entry points to new entry point group. Something like this is needed so that the instrumentation is ONLY loaded once the optional dependencies are confirmed. The group name needs to change to not mess with the customer's existing auto instrumentation environment.
  6. Use optional dependency ("instruments") tuple and get_dependency_conflicts instead of distribution dependency method.

Since I need code to be used to pass lint, I did not separate this pr. But I have separated the vendor folder as the first commit to make reviewing easier.

@jeremydvoss
Copy link
Member Author

jeremydvoss commented May 18, 2023

#282

@jeremydvoss jeremydvoss force-pushed the vendor-instrumentations branch 6 times, most recently from 200484b to 75044bb Compare May 22, 2023 22:57
@jeremydvoss jeremydvoss force-pushed the vendor-instrumentations branch from 75044bb to 9348ee4 Compare May 22, 2023 23:06
@jeremydvoss jeremydvoss marked this pull request as ready for review May 22, 2023 23:07
@jeremydvoss jeremydvoss requested review from a team and lzchen as code owners May 22, 2023 23:07
@jeremydvoss jeremydvoss mentioned this pull request May 22, 2023
Merged
6 tasks
lzchen
lzchen reviewed May 25, 2023
View reviewed changes
...ntelemetry/azure/monitor/opentelemetry/vendor/opentelemetry/instrumentation/asgi/__init__.py
@@ -0,0 +1,661 @@
# Copyright The OpenTelemetry Authors
Copy link
Contributor

@lzchen lzchen May 25, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

What are the legal implications of using two copyrights and will this affect us negatively in the future if we don't have the Microsoft license? I remember having issues with azure-sdk if the code isn't under the MiT license. Might be a good question to ask CELA/azure-sdk

Copy link
Member Author

@jeremydvoss jeremydvoss Jun 1, 2023

Choose a reason for hiding this comment

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

Asked Anna.

Copy link
Contributor

@lzchen lzchen Jun 1, 2023

Choose a reason for hiding this comment

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

What is the verdict?

Copy link
Member Author

@jeremydvoss jeremydvoss Jun 6, 2023

Choose a reason for hiding this comment

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

On vacation until June 15th. Will ask someone else.

Copy link
Member Author

@jeremydvoss jeremydvoss Jun 7, 2023

Choose a reason for hiding this comment

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

Kashif recommended I ask a lawyer.

lzchen
lzchen reviewed May 25, 2023
View reviewed changes
lzchen
lzchen reviewed May 25, 2023
View reviewed changes
@lzchen
Copy link
Contributor

lzchen commented May 25, 2023

Just to confirm, these were copied from the production version of the instrumentations on Pypi correct?

@jeremydvoss jeremydvoss force-pushed the vendor-instrumentations branch from 72897c4 to 3d0dc62 Compare May 31, 2023 21:50
@jeremydvoss jeremydvoss force-pushed the vendor-instrumentations branch from 748f0b7 to 58f20ec Compare June 1, 2023 00:17
lzchen
lzchen reviewed Jun 1, 2023
View reviewed changes
...elemetry/_vendor/v0_38b0/opentelemetry/instrumentation/auto_instrumentation/sitecustomize.py
@@ -0,0 +1,134 @@
# Copyright The OpenTelemetry Authors
Copy link
Contributor

@lzchen lzchen Jun 1, 2023

Choose a reason for hiding this comment

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

Would the existence of another sizecustomize.py mess up the autoinstrumentation we already have?

Copy link
Member Author

@jeremydvoss jeremydvoss Jun 2, 2023

Choose a reason for hiding this comment

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

No. Sitecustomize needs to be pointed to. They would have to manually set their python path to point here to intentionally use this script.

lzchen
lzchen reviewed Jun 1, 2023
View reviewed changes
@lzchen
Copy link
Contributor

lzchen commented Jun 1, 2023

What is the behavior when user uses the distro AND manually instruments with new versions of the supported instrumentations, now that we are vendoring current versions of the instrumentations?

@jeremydvoss
Copy link
Member Author

jeremydvoss commented Jun 7, 2023

What is the behavior when user uses the distro AND manually instruments with new versions of the supported instrumentations, now that we are vendoring current versions of the instrumentations?

After some testing, I have determined that our vendored instrumentation is considered different than any instrumentation the Cx may put on top of it. Because "_is_instrumented_by_opentelemetry" is a class level variable and our vendored instrumentations are in a different module, if the Cx uses our vendored instrumentation and then triggers there own, the 2nd will occur without the "Attempting to instrument while already instrumented" message. THe 2nd instrumentation seems to overwrite the vendored 1st one. I think this is the appropriate approach because it means our instrumentation does not interfere with the Cx's.

@lzchen
Copy link
Contributor

lzchen commented Jun 8, 2023

After some testing, I have determined that our vendored instrumentation is considered different than any instrumentation the Cx may put on top of it. Because "_is_instrumented_by_opentelemetry" is a class level variable and our vendored instrumentations are in a different module, if the Cx uses our vendored instrumentation and then triggers there own, the 2nd will occur without the "Attempting to instrument while already instrumented" message. THe 2nd instrumentation seems to overwrite the vendored 1st one. I think this is the appropriate approach because it means our instrumentation does not interfere with the Cx's.

Does that mean user will get duplicate telemetry?

@jeremydvoss
Copy link
Member Author

jeremydvoss commented Jun 8, 2023

After some testing, I have determined that our vendored instrumentation is considered different than any instrumentation the Cx may put on top of it. Because "_is_instrumented_by_opentelemetry" is a class level variable and our vendored instrumentations are in a different module, if the Cx uses our vendored instrumentation and then triggers there own, the 2nd will occur without the "Attempting to instrument while already instrumented" message. THe 2nd instrumentation seems to overwrite the vendored 1st one. I think this is the appropriate approach because it means our instrumentation does not interfere with the Cx's.

Does that mean user will get duplicate telemetry?

No duplication will occur.

@jeremydvoss jeremydvoss mentioned this pull request Jun 12, 2023
Closed
@jeremydvoss jeremydvoss merged commit 992d12d into microsoft:main Jun 12, 2023
@jeremydvoss jeremydvoss mentioned this pull request Jun 14, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@lzchen lzchen lzchen approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@jeremydvoss @lzchen