-
Notifications
You must be signed in to change notification settings - Fork 871
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
[WIP] feat: add opentelemetry instrumentation #3185
[WIP] feat: add opentelemetry instrumentation #3185
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @dazuma, here's rough draft here to get the discussion/review started.
@@ -30,10 +30,10 @@ class HttpCommand | |||
RETRIABLE_ERRORS = [Google::Apis::ServerError, Google::Apis::RateLimitError, Google::Apis::TransmissionError] | |||
|
|||
begin | |||
require 'opencensus' | |||
OPENCENSUS_AVAILABLE = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you want to maintain support for opencensus in addition to opentelemetry?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhh, yeah, as much as I don't want to support OpenCensus here anymore, I also don't think we should rip it out unceremoniously. We should rather add a deprecation warning for a time. Can we use the logic of: try requiring opentelemetry and if that works enable it, otherwise try requiring opencensus and if that works enable it, otherwise disable both? So you can just leave the opencensus_{begin,end}_span
methods in place, and add new ones for OpenTelemetry.
module Google | ||
module Apis | ||
module Core | ||
class Instrumentation < OpenTelemetry::Instrumentation::Base |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I included the instrumentation base as it surfaces configuration in a consistent way with other instrumented gems.
expect(events[0].uncompressed_size).to eql 0 | ||
expect(events[1].type).to eql :RECEIVED | ||
expect(events[1].uncompressed_size).to eql 11 | ||
span_double = instance_double(OpenTelemetry::Trace::Span) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't typically reach for doubles, but I was apprehensive towards including opentelemetry-sdk
so we could use the in memory exporter to assert the generated spans.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why were you apprehensive? Perfectly happy including the SDK gem as a development dependency (not a runtime dependency) so it's available for tests, if it will make this cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why were you apprehensive?
I just didn't want to assume that you would want the SDK included so I opted to present a quick alternative first so I could get your feedback. I will change this to use the SDK as I address the rest of your feedback.
@@ -30,10 +30,10 @@ class HttpCommand | |||
RETRIABLE_ERRORS = [Google::Apis::ServerError, Google::Apis::RateLimitError, Google::Apis::TransmissionError] | |||
|
|||
begin | |||
require 'opencensus' | |||
OPENCENSUS_AVAILABLE = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhh, yeah, as much as I don't want to support OpenCensus here anymore, I also don't think we should rip it out unceremoniously. We should rather add a deprecation warning for a time. Can we use the logic of: try requiring opentelemetry and if that works enable it, otherwise try requiring opencensus and if that works enable it, otherwise disable both? So you can just leave the opencensus_{begin,end}_span
methods in place, and add new ones for OpenTelemetry.
'http.host' => url.host.to_s, | ||
'http.method' => method.to_s, | ||
'http.target' => url.path.to_s, | ||
'peer.service' => 'google' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think most google backends are actually emitting spans or setting service.name
so it may not matter that much... But from my understanding of the semantics of this attribute, I suggest using url.host.to_s
which will return the "official" ID of the service being called.
# the entire request to fail. | ||
logger.debug { sprintf('Error opening OpenCensus span: %s', e) } | ||
logger.debug { sprintf('Error opening OpenTelemetry span: %s', e) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know the opencensus code used sprintf. That was unfortunate and I should have changed it. Could you just use normal string interpolation for this?
'peer.service' => 'google' | ||
} | ||
|
||
@opentelemetry_span = Google::Apis::Core::Instrumentation.instance.tracer.start_span(url.host.to_s, attributes: attributes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, what's the best practice for naming spans? This just provides the service name. Should we include the method being called?
expect(events[0].uncompressed_size).to eql 0 | ||
expect(events[1].type).to eql :RECEIVED | ||
expect(events[1].uncompressed_size).to eql 11 | ||
span_double = instance_double(OpenTelemetry::Trace::Span) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why were you apprehensive? Perfectly happy including the SDK gem as a development dependency (not a runtime dependency) so it's available for tests, if it will make this cleaner.
fcb8442
to
d2f2abb
Compare
Accidentally did a bad rebase the close the PR :/ Re-opened -> #3414 |
No description provided.