feat: add gem for zero-code-instrumentation in otel-operator #1384
Conversation
xuan-cao-swi
requested review from
fbogsany,
mwear,
robertlaurin,
dazuma,
ericmustin,
arielvalentin,
ahayworth,
plantfansam,
robbkidd,
simi,
kaylareopelle and
a team
as code owners
|
We don't need to push to make the gem ready/release, but the script file need to get some review first. |
|
👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the |
|
👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the |
kaylareopelle
added
keep
| _(registry.size).must_equal 1 | ||
| _(registry.first.first.name).must_equal 'OpenTelemetry::Instrumentation::Net::HTTP' | ||
|
|
||
| ENV['OTEL_RUBY_ENABLED_INSTRUMENTATIONS'] = nil |
There was a problem hiding this comment.
Add this to the before or after block or in an ensure block to make sure that it is reset after every test
| spec.require_paths = ['lib'] | ||
| spec.required_ruby_version = '>= 3.1' | ||
|
|
||
| spec.add_dependency 'opentelemetry-api', '1.4.0' |
There was a problem hiding this comment.
Do you want these to always use strict versions vs pessemistic versioning to allow for bug fixes in dependencies without requiring a new version of this gem?
There was a problem hiding this comment.
I believe we can opt for a non-strict version of the gem. Initially, I was concerned because opentelemetry-operator prefers strict versioning to prevent unexpected failures. However, since the auto-instrumentation image will be built upstream and is expected to remain stable for a while, using a non-strict version should be safe.
There was a problem hiding this comment.
Is there going to be a process that bumps this version when the API and SDK versions are updated?
There was a problem hiding this comment.
Yes, I think it's auto-update-agent.yaml from their repo.
Co-authored-by: Kayla Reopelle <87386821+kaylareopelle@users.noreply.github.com>
Co-authored-by: Kayla Reopelle <87386821+kaylareopelle@users.noreply.github.com>
Co-authored-by: Kayla Reopelle <87386821+kaylareopelle@users.noreply.github.com>
Co-authored-by: Kayla Reopelle <87386821+kaylareopelle@users.noreply.github.com>
Co-authored-by: Kayla Reopelle <87386821+kaylareopelle@users.noreply.github.com>
Co-authored-by: Kayla Reopelle <87386821+kaylareopelle@users.noreply.github.com>
Co-authored-by: Kayla Reopelle <87386821+kaylareopelle@users.noreply.github.com>
Co-authored-by: Ariel Valentin <arielvalentin@users.noreply.github.com>
Co-authored-by: Ariel Valentin <arielvalentin@users.noreply.github.com>
Description
This PR aims to contribute a script/gem that can load the necessary OpenTelemetry-related gems and initialize the SDK for the opentelemetry-operator. The script/gem also includes a resource detector as part of its features.
The main idea was inspired by new_relic, which prepends the bundler.require function and places the loading script at the end of the loading procedure. For apps or scripts that don't use Bundler or a Gemfile, more details on variations of app loading can be found in the README. Currently, the goal is to ensure that Rails apps can work, with future improvements in mind.
The reason behind creating this gem is to facilitate easy installation and dependency enforcement. Although for the OpenTelemetry-Operator Node.js, it puts the loading script directly in the src folder (and then copy over to binding volume), it still relies on the auto-instrumentation-node package to install all required packages (e.g., API/SDK and instrumentation packages).
The main purpose of the gem is to serve the OpenTelemetry-Operator, which requires more configuration changes (see the configuration section in the README). Users don't need to modify their Ruby app codebase while using the instrumentation from OpenTelemetry-Ruby, but anyone can still use it in any environment.
The gem name, file structure, and implementation need more suggestions to make them more reasonable. I have tested it with rails and sinatra (through rackup), and I currently still in the process of testing against the opentelemetry operator cluster locally. Once the operator testing done, I will mark the pr as ready.