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

[WIP] feat: add opentelemetry instrumentation #3185

Closed

Conversation

robertlaurin
Copy link

No description provided.

@google-cla
Copy link

google-cla bot commented Mar 8, 2021

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 @googlebot I signed it! and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

@google-cla google-cla bot added the cla: no This human has *not* signed the Contributor License Agreement. label Mar 8, 2021
Copy link
Author

@robertlaurin robertlaurin left a 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
Copy link
Author

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?

Copy link
Member

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
Copy link
Author

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)
Copy link
Author

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.

Copy link
Member

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.

Copy link
Author

@robertlaurin robertlaurin Mar 17, 2021

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
Copy link
Member

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'
Copy link
Member

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) }
Copy link
Member

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)
Copy link
Member

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)
Copy link
Member

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.

@dazuma dazuma added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Mar 11, 2021
@yoshi-kokoro yoshi-kokoro removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Mar 11, 2021
@robertlaurin
Copy link
Author

Accidentally did a bad rebase the close the PR :/

Re-opened -> #3414

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: no This human has *not* signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants