stats/opentelemetry: Add OpenTelemetry instrumentation component #7066

zasweq · 2024-03-29T02:59:52Z

This PR implements the gRPC-Go instrumentation component for OpenTelemetry, as outlined in https://github.com/grpc/proposal/blob/master/A66-otel-stats.md.

RELEASE NOTES:

stats/opentelemetry: Add OpenTelemetry instrumentation component

codecov · 2024-03-29T03:02:48Z

Codecov Report

Merging #7066 (9597843) into master (ba1bf9e) will decrease coverage by 1.23%.
Report is 35 commits behind head on master.
The diff coverage is n/a.

❗ Current head 9597843 differs from pull request most recent head 1f6a60c. Consider uploading reports for the commit 1f6a60c to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7066      +/-   ##
==========================================
- Coverage   82.39%   81.17%   -1.23%     
==========================================
  Files         305      345      +40     
  Lines       31389    33927    +2538     
==========================================
+ Hits        25864    27541    +1677     
- Misses       4463     5213     +750     
- Partials     1062     1173     +111

see 66 files with indirect coverage changes

dfawley

Will review the tests on the next pass; wanted to get this pass out ASAP.

stats/opentelemetry/opentelemetry.go

dfawley · 2024-04-01T20:33:46Z

stats/opentelemetry/opentelemetry.go

+// EmptyMetrics represents no metrics. To start from a clean slate if want to
+// pick a subset of metrics, use this and add onto it.


"if want to" - please fix. Or even just delete this bit. An example for how to enable/disable metrics would be more useful.

Switched to "// EmptyMetrics represents no metrics. To start from a clean slate if the
// intended effect is to pick a subset of metrics, use this and add onto it."

Hmmm let me look into this Example test.

I'll do this once we nail down this API.

Ping - it will be nice to show examples of initializing: with metrics disabled, with 1-2 metrics enabled, with the default set of metrics enabled, and with 1-2 metrics disabled.

stats/opentelemetry/opentelemetry.go

stats/opentelemetry/client_metrics.go

dfawley · 2024-04-01T22:47:38Z

stats/opentelemetry/client_metrics.go

+	case *stats.Begin:
+		ci := getCallInfo(ctx)
+		if ci == nil {
+			// Shouldn't happen, set by interceptor, defensive programming. Log it won't record?


Yeah log.Error SGTM. And in HandleRPC above, processRPCEnd below, etc.

And everywhere if you log.Error with "___ unexpected ___" then you shouldn't need a comment to double-explain it.

Alright I'll add errors in logs. I'll leave the comment that it shouldn't happen?

stats/opentelemetry/client_metrics.go

dfawley · 2024-04-01T22:49:35Z

stats/opentelemetry/client_metrics.go

+	metrics: map[string]bool{
+		"grpc.client.attempt.started":                            true,
+		"grpc.client.attempt.duration":                           true,
+		"grpc.client.attempt.sent_total_compressed_message_size": true,
+		"grpc.client.attempt.rcvd_total_compressed_message_size": true,
+		"grpc.client.call.duration":                              true,
+	},


use Metrics.Empty.Add()? (Or create a NewMetrics(...)?)

I would rather do the NewMetrics, but I think the decided API restricts the operations of construction enough (can't just pass in a list[], you have a default list you scale up and down by single metrics) that we should do a metrics.Empty.Add() here.

Add has, and NewMetrics can have a variadic parameter. So this could be NewMetrics("grpc.client.attempt.started", "grpc.client.attempt.duration", ....).

Please use consts for these metric strings (as above). I think we can just delete EmptyMetrics.

I think NewMetrics having a variadic parameter breaks the API that we discussed...Add Remove or Empty() than add. I understand what you're going for, but in that case I might as well have passed a slice of metrics to initialize like I originally wanted but they pushed back wrt API on.

I don't see how EmptyMetrics.Add(...) is any different than NewMetrics(...) except that one is much more obvious how to use it and doesn't have the weird loophole of someone doing (otel.EmptyMetrics = <something else>).

Ping on this comment.

Discussed offline; switched.

stats/opentelemetry/server_metrics.go

dfawley · 2024-04-05T16:21:56Z

stats/opentelemetry/client_metrics.go

+var DefaultClientMetrics = *EmptyMetrics.Add("grpc.client.attempt.started").
+	Add("grpc.client.attempt.duration").
+	Add("grpc.client.attempt.sent_total_compressed_message_size").
+	Add("grpc.client.attempt.rcvd_total_compressed_message_size").
+	Add("grpc.client.call.duration")


Please export consts for the metric names (with type MetricName).

stats/opentelemetry/opentelemetry.go

dfawley · 2024-04-05T16:23:45Z

stats/opentelemetry/opentelemetry.go

+// Users of this component should use these bucket boundaries as part of their
+// SDK MeterProvider passed in. This component sends this as "advice" to the
+// API, which works, however this stability is not guaranteed, so for safety the
+// SDK Meter Provider should set these bounds.


Please remove any lingering duplication from this where it's also repeated below. E.g. the bit about how users should set it in their SDK MeterProvider.

dfawley · 2024-04-05T16:30:53Z

stats/opentelemetry/opentelemetry.go

+	// the string "other". If unset, will use the method string as is. This is
+	// intended to be used only for generic methods (see
+	// grpc.UnknownServiceHandler), and not registered static methods (from
+	// generated service protos).


Maybe something like Set this to record the method name of RPCs handled by grpc.UnknownServiceHandler, but take care to limit the values allowed, as allowing too many will increase cardinality and could cause severe memory or performance problems. ?

I appended "Take care to limit the values allowed, as allowing too many will increase cardinality and could cause severe memory or performance problems." If you feel strongly about switching the whole comment, let me know, I felt like it was important to call out generic vs. static.

This option is settable for both the server and client-side stats handler, right?

Is it only honored on server-side? If so, that should be included.

And then the bit about "from generated service protos" is too specific, since you can register handlers without using protobuf.

Alright I'll switch over to your comment.

Wait no this is client and server side. Client side you also can want a knob for filtering arbitrary method names. Generated service protos applies to client side, server side is registered protos + registered handlers.

Client side you also can want a knob for filtering arbitrary method names.

I thought that was what the call option was for?

https://github.com/grpc/proposal/blob/master/A66-otel-stats.md calls for the flow to be something like -
Is the method registered/known?
-- If it's registered/known, record it
-- If it's not, use the method filter to record it.

But, yeah, in your case, you can achieve this with the knob since the knob is available to the users. Your call

As per offline discussion, we decided to go the route you mentioned server side (really no other option). On client side, generic methods also go through StaticMethodCallOption exposed to users (i.e. Invoke() or NewStream()).

Wrote a new documentation comment.

dfawley · 2024-04-05T16:35:09Z

stats/opentelemetry/opentelemetry.go

+// rpcInfo is RPC information scoped to the RPC attempt life span client side,
+// and the RPC life span server side.
+type rpcInfo struct {
+	mi *metricsInfo
+}


If rpcInfo is meant to be per-attempt then it should probably be attemptInfo instead.

yashykt · 2024-04-05T22:32:43Z

stats/opentelemetry/client_metrics.go

+		return
+	}
+
+	meter := csh.mo.MeterProvider.Meter("gRPC-Go")


As per https://github.com/grpc/proposal/blob/master/A66-otel-stats.md#language-specific-details, you should specify the version as well

Ah ok just saw this section. Added version to both client and server side. I remember talking last year about how this name is a no-op and trying to figure out what to do with this.

yashykt · 2024-04-05T22:33:44Z

stats/opentelemetry/client_metrics.go

+	}
+
+	meter := csh.mo.MeterProvider.Meter("gRPC-Go")
+	if meter == nil {


what's the behavior over here? Can this actually happen?

This is the no-op meter provider thingy. It just doesn't record metrics. I don't think this can actually happen, this is mainly for defensive programming.

yashykt · 2024-04-05T22:34:30Z

stats/opentelemetry/client_metrics.go

+	clientMetrics := clientMetrics{}
+
+	if _, ok := setOfMetrics["grpc.client.attempt.started"]; ok {
+		asc, err := meter.Int64Counter("grpc.client.attempt.started", metric.WithUnit("attempt"), metric.WithDescription("The total number of RPC attempts started, including those that have not completed."))


Description - "Number of client call attempts started"
Unit - "{attempt}"

yashykt · 2024-04-05T22:34:57Z

stats/opentelemetry/client_metrics.go

+	}
+
+	if _, ok := setOfMetrics["grpc.client.attempt.duration"]; ok {
+		cad, err := meter.Float64Histogram("grpc.client.attempt.duration", metric.WithUnit("s"), metric.WithDescription("End-to-end time taken to complete an RPC attempt including the time it takes to pick a subchannel."), metric.WithExplicitBucketBoundaries(DefaultLatencyBounds...))


Description - "End-to-end time taken to complete a client call attempt"

yashykt · 2024-04-05T22:35:16Z

stats/opentelemetry/client_metrics.go

+	}
+
+	if _, ok := setOfMetrics["grpc.client.attempt.sent_total_compressed_message_size"]; ok {
+		cas, err := meter.Int64Histogram("grpc.client.attempt.sent_total_compressed_message_size", metric.WithUnit("By"), metric.WithDescription("Total bytes (compressed but not encrypted) sent across all request messages (metadata excluded) per RPC attempt; does not include grpc or transport framing bytes."), metric.WithExplicitBucketBoundaries(DefaultSizeBounds...))


Description - "Compressed message bytes sent per client call attempt"

yashykt · 2024-04-05T22:36:21Z

stats/opentelemetry/server_metrics.go

+
+	serverMetrics := serverMetrics{}
+	if _, ok := setOfMetrics["grpc.server.call.started"]; ok {
+		scs, err := meter.Int64Counter("grpc.server.call.started", metric.WithUnit("call"), metric.WithDescription("The total number of RPCs started, including those that have not completed."))


Description - "Number of server calls started"
Unit - "{call}"

yashykt · 2024-04-05T22:36:47Z

stats/opentelemetry/server_metrics.go

+	}
+
+	if _, ok := setOfMetrics["grpc.server.call.sent_total_compressed_message_size"]; ok {
+		ss, err := meter.Int64Histogram("grpc.server.call.sent_total_compressed_message_size", metric.WithUnit("By"), metric.WithDescription("Total bytes (compressed but not encrypted) sent across all response messages (metadata excluded) per RPC; does not include grpc or transport framing bytes."), metric.WithExplicitBucketBoundaries(DefaultSizeBounds...))


Description - "Compressed message bytes sent per server call"

yashykt · 2024-04-05T22:36:59Z

stats/opentelemetry/server_metrics.go

+	}
+
+	if _, ok := setOfMetrics["grpc.server.call.rcvd_total_compressed_message_size"]; ok {
+		sr, err := meter.Int64Histogram("grpc.server.call.rcvd_total_compressed_message_size", metric.WithUnit("By"), metric.WithDescription("Total bytes (compressed but not encrypted) received across all request messages (metadata excluded) per RPC; does not include grpc or transport framing bytes."), metric.WithExplicitBucketBoundaries(DefaultSizeBounds...))


Description - "Compressed message bytes received per server call"

yashykt · 2024-04-05T22:37:24Z

stats/opentelemetry/server_metrics.go

+	}
+
+	if _, ok := setOfMetrics["grpc.server.call.duration"]; ok {
+		scd, err := meter.Float64Histogram("grpc.server.call.duration", metric.WithUnit("s"), metric.WithDescription("This metric aims to measure the end2end time an RPC takes from the server transport’s perspective."), metric.WithExplicitBucketBoundaries(DefaultLatencyBounds...))


Description - End-to-end time taken to complete a call from server transport's perspective

yashykt · 2024-04-05T22:38:40Z

stats/opentelemetry/client_metrics.go

+	}
+
+	if _, ok := setOfMetrics["grpc.client.call.duration"]; ok {
+		ccs, err := meter.Float64Histogram("grpc.client.call.duration", metric.WithUnit("s"), metric.WithDescription("This metric aims to measure the end-to-end time the gRPC library takes to complete an RPC from the application’s perspective."), metric.WithExplicitBucketBoundaries(DefaultLatencyBounds...))


Description - "Time taken by gRPC to complete an RPC from application's perspective"

ash2k · 2024-04-08T23:05:09Z

Hi all. So the proposal only talks about metrics. What about tracing? Would be nice to have both as an officially maintained package. Thank you!

zasweq · 2024-04-08T23:15:32Z

The gRPC OpenTelemetry Tracing gRFC is in flight: grpc/proposal#389. Eventually, the plan is to add tracing as part of this same module, as part of the client and server stats handler. This is like our OpenCensus instrumentation component, which does both: https://github.com/grpc/grpc-go/blob/master/stats/opencensus/opencensus.go. :)

ash2k · 2024-04-08T23:35:20Z

This is great! Thank you for the hard work!

ash2k · 2024-04-08T23:37:29Z

One more question: is the plan to replace https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/instrumentation/google.golang.org/grpc/otelgrpc? Two implementations would not benefit anyone, clearly.

dfawley · 2024-04-16T16:07:38Z

stats/opentelemetry/opentelemetry.go

+
+var joinDialOptions = internal.JoinDialOptions.(func(...grpc.DialOption) grpc.DialOption)
+
+// MetricName is a name of a metric.


Nit: MetricName is an identifier for a metric provided by this package. or something?

Also peeking at the godoc might help you see things from your users' eyes:

$ ~/go/bin/godoc # open browser at http://localhost:6060

Maybe just Metric?

Switched to Metric. Switched docstring.

dfawley · 2024-04-16T16:12:35Z

stats/opentelemetry/client_metrics.go

+const (
+	// ClientAttemptStartedName is the name of the client attempt started
+	// metric.
+	ClientAttemptStartedName = MetricName("grpc.client.attempt.started")


Nit: These will look slightly better as ClientAttemptStartedName MetricName = "grpc.client.attempt.started" (which mimics how time.Durations are declared).

Done. Yeah that looks nicer.

dfawley · 2024-04-16T16:19:41Z

stats/opentelemetry/opentelemetry.go

+	metrics map[MetricName]bool
+}
+
+// NewMetrics returns a Metrics with the metrics provided specified.


"provided specified" -> please fix

Yeah I didn't know what to say here really for this docstring, so I said "provided" which become "specified". I'll just drop the specified part and switch to "NewMetrics returns a Metrics containing the MetricName's provided".

switch to "NewMetrics returns a Metrics containing the MetricName's provided".

That's fine, but note that adding 's is not how we make things plural. MetricNames please. (Or with markdown, MetricNames is preferred but godoc doesn't support that.)

Comment also talked about below, this switched to "NewMetrics returns a Metrics containing Metrics".

dfawley · 2024-04-16T16:21:14Z

stats/opentelemetry/client_metrics.go

+const (
+	// ClientAttemptStartedName is the name of the client attempt started
+	// metric.
+	ClientAttemptStartedName = MetricName("grpc.client.attempt.started")


s/Name// please. Note that several of your defined metrics don't have the Name suffix already.

dfawley · 2024-04-16T16:22:01Z

stats/opentelemetry/client_metrics.go

+	// ClientAttemptStartedName is the name of the client attempt started
+	// metric.


Instead of saying "BlahBlahBlah is the name of the blah blah blah metric" which gives no information, specify what the metric actually measures, etc.

Good point. Pulled Yashes consice description strings to these docstrings. @yashykt you should add these description strings to gRFC to officially spec them :).

dfawley · 2024-04-16T16:25:18Z

stats/opentelemetry/opentelemetry.go

+	// Metrics are the metrics to instrument. Will turn on the corresponding
+	// metric supported by the client and server instrumentation components if
+	// applicable.


What does "Will turn on ________" mean?

Also: "If not set, the default metrics will be recorded"?

Added If not set, the default metrics will be recorded. Switched language to "will create instrument and record telemetry".

dfawley · 2024-04-16T16:26:09Z

stats/opentelemetry/opentelemetry.go

+	// Metrics are the metrics to instrument. Will turn on the corresponding
+	// metric supported by the client and server instrumentation components if
+	// applicable.
+	Metrics *Metrics


What happens if a user sets an unsupported metric? (E.g. if they specify server metrics when they initialize the client)? Ideally DialOption would error??

I remembering discussing this with Yash, and I think the decision was just to leave this as a no-op in this scenario (I.e. just ignore the metrics). Right @yashykt?

yeah, no-op is what i'm thinking. Consider the case of experimental metrics. There might be a case where we decide to remove experimental metrics and we don't want removal of metrics to break user code (if they had enabled the experimental metrics).

Yeah sounds good to me. Let me know what you think Doug.

OTOH, consider the case where they're initializing a DialOption and accidentally passing the default server metrics object. I could easily see this happening, as all the types line up and everything. In this scenario, they'll get no metrics at all.

If we remove an experimental metric, maybe the user wants an init-time error so they know it was removed?

And in our case, that's what will happen anyway, unless we leave the const behind for the removed metric.

I think we're calling the metrics in A66 stable, which is why we have default + exported consts. I think the goal was the defaults now are stable (i.e. ones defined in A66).

Why would a user set Server Metrics for Dial Option :)? I guess the tradeoff is the scenario you mentioned earlier vs. being defensive now.

By accident. Spot the bug:

opentelemetry.DialOption(opentelemetry.Options{ LoggingOptions: ..., MetricsOptions: opentelemetry.MetricsOptions{ MeterProvider: blahblahblah, Metrics: opentelemetry.DefaultServerMetrics, TargetAttributeFilter: func(t target) bool { return allowedTargets[t] }, }, TracingOptions: ..., })

Let's separate the metrics field to client and server metrics then for type safety? not entirely type safe but at least the user knows whether setting for client or sever and not tied to DialOption/ServerOption?

Discussed offline; decided to make it DefaultMetrics that contains both client and server, which will be ignored on the other side to the initialized option.

stats/opentelemetry/opentelemetry.go

dfawley · 2024-04-16T16:30:03Z

stats/opentelemetry/opentelemetry.go

+// Users of this component should use these bucket boundaries as part of their
+// SDK MeterProvider passed in. This component sends this as "advice" to the
+// API, which works, however this stability is not guaranteed, so for safety the
+// SDK Meter Provider should set these bounds.


Oh, this does show up in godoc. Please check out the godoc view.

Also, please remove duplication. We don't want the same "Users of this component should..." message appearing 3x.

dfawley · 2024-04-16T16:31:20Z

stats/opentelemetry/opentelemetry.go

+// EmptyMetrics represents no metrics. To start from a clean slate if want to
+// pick a subset of metrics, use this and add onto it.


Ping - it will be nice to show examples of initializing: with metrics disabled, with 1-2 metrics enabled, with the default set of metrics enabled, and with 1-2 metrics disabled.

dfawley · 2024-04-17T15:59:29Z

stats/opentelemetry/e2e_test.go

+func ExampleMetric_Remove() {
+	// Use DefaultClientMetrics without ClientAttemptDuration and
+	// ClientCallDurationName.
+	DefaultClientMetrics.Remove(ClientAttemptDuration, ClientCallDurationName)
+}


I think these would be more useful on the DialOption / ServerOption, or Options, and should show how to build the DialOption. Just one line of code isn't super useful.

E.g. something like:

func ExampleDialOption_ExcludeMetrics() { // To exclude specific metrics, initialize Options as follows: otelOpts := opentelemetry.Option{ MetricsOptions: MetricsOptions{ Metrics: DefaultClientMetrics.Remove(opentelemetry.ClientAttemptDuration, }, } dialOption := opentelemetry.DialOption(otelOpts) cc, _ := grpc.Dial("<target string>", dialOption) // Handle err. defer cc.Close() }

Don't the examples technically have to be linked to a single exported function from the package?

No, there are many ways of attaching examples at different places in the package. Check the testing documentation for more details: https://pkg.go.dev/testing#hdr-Examples

Added numerous examples.

dfawley · 2024-04-17T16:01:26Z

stats/opentelemetry/opentelemetry.go

-// NewMetrics returns a Metrics with the metrics provided specified.
-func NewMetrics(metrics ...MetricName) *Metrics {
-	newMetrics := make(map[MetricName]bool)
+// NewMetrics returns a Metrics containing the Metric's provided.


Another choice is to say "containing metrics." - directly referencing the parameter's name.

Good point, switched.

dfawley · 2024-04-17T16:02:36Z

stats/opentelemetry/opentelemetry.go

-	// DefaultLatencyBounds are the default bounds for latency metrics. Users of
-	// this component should set these bucket boundaries as part of their SDK
-	// MeterProvider passed in for desired latency metrics.
+	// DefaultLatencyBounds are the default bounds for latency metrics.
 	DefaultLatencyBounds = []float64{0, 0.00001, 0.00005, 0.0001, 0.0003, 0.0006, 0.0008, 0.001, 0.002, 0.003, 0.004, 0.005, 0.006, 0.008, 0.01, 0.013, 0.016, 0.02, 0.025, 0.03, 0.04, 0.05, 0.065, 0.08, 0.1, 0.13, 0.16, 0.2, 0.25, 0.3, 0.4, 0.5, 0.65, 0.8, 1, 2, 5, 10, 20, 50, 100} // provide "advice" through API, SDK should set this too


It would also be nice to show users how to do this, too.

Added as part of example. Verified it worked by playing around with example configuration wrt bounds and seeing the result.

dfawley · 2024-04-17T16:03:15Z

stats/opentelemetry/client_metrics.go

+	ClientAttemptRcvdCompressedTotalMessageSize Metric = "grpc.client.attempt.rcvd_total_compressed_message_size"
+	// ClientCallDurationName is the time taken by gRPC to complete an RPC from
+	// application's perspective.
+	ClientCallDurationName Metric = "grpc.client.call.duration"


This one is still named Name

Argh, whoops. Removed.

zasweq · 2024-04-20T00:50:42Z

Sorry for the delay on the example, it's pretty complicated. I need to set bounds and instruments, and it also seems like it needs to output something so should I set up a whole RPC system? That's the only way the example can really "do" something. Showing users how to use default bounds links in MeterProvider SDK, and a reader which to show how to use I need to do a full RPC. And then each knob you want to show how it works (i.e. add/delete metrics is a whole other contained example that needs to spin up a server and do an rpc etc.). Is the e2e test with Defaults explicitly set and a manual reader set/read from an asserted on a good enough example? I'm fine adding an example, but to have it do anything (esp with default bounds) feels incredibly verbose compared to the examples I've seen. If you think it's not too verbose, what would be scope of your example? Can you review the e2e tests while you're at it while I'm writing example?

dfawley · 2024-04-22T19:57:49Z

The example doesn't have to be a complete system. Just show the code users need to do a thing.

An example showing how users set the bounds on the meter should be a couple function calls in theory? They don't need to actually do anything.

zasweq · 2024-04-23T02:28:45Z

Added numerous examples and got to all comments from last pass. Examples and tests are ready to be looked at.

dfawley · 2024-04-23T17:35:33Z

Sorry, can you create a new PR for this and squash your commits? There are 180+ comments and github is getting bogged down. Thanks!

zasweq · 2024-04-23T18:29:48Z

Done in #7166.

zasweq requested a review from dfawley March 29, 2024 02:59

zasweq assigned dfawley Mar 29, 2024

zasweq requested a review from yashykt March 29, 2024 03:00

zasweq added the Type: Feature New features or improvements in behavior label Mar 29, 2024

zasweq modified the milestones: 1.63 Release, 1.64 Release Mar 29, 2024

Add OpenTelemetry instrumentation component

d60d637

zasweq force-pushed the opentelemetry-instrumentation-component branch from a417898 to d60d637 Compare March 29, 2024 03:02

dfawley reviewed Apr 1, 2024

View reviewed changes

dfawley assigned zasweq and unassigned dfawley Apr 1, 2024

Responded to Doug's comments

78fef76

zasweq assigned dfawley and unassigned zasweq Apr 2, 2024

dfawley reviewed Apr 5, 2024

View reviewed changes

Responded to Doug's comments

796d697

zasweq assigned zasweq and unassigned dfawley Apr 5, 2024

yashykt reviewed Apr 5, 2024

View reviewed changes

Responded to all of Yashes comments and some of Doug's comments

9597843

zasweq assigned yashykt and dfawley and unassigned zasweq Apr 6, 2024

dfawley assigned zasweq and unassigned yashykt and dfawley Apr 15, 2024

Responded to Doug's comments

84eae8c

zasweq assigned dfawley and unassigned zasweq Apr 15, 2024

dfawley reviewed Apr 16, 2024

View reviewed changes

dfawley assigned zasweq and unassigned dfawley Apr 16, 2024

Responded to Doug's comments

196e201

zasweq assigned dfawley and unassigned zasweq Apr 16, 2024

Vet

4a14a16

dfawley reviewed Apr 17, 2024

View reviewed changes

dfawley assigned zasweq and unassigned dfawley Apr 17, 2024

zasweq assigned dfawley and unassigned zasweq Apr 20, 2024

dfawley assigned zasweq Apr 22, 2024

Responded to Doug's comments

1f6a60c

zasweq removed their assignment Apr 23, 2024

dfawley closed this Apr 23, 2024

		// EmptyMetrics represents no metrics. To start from a clean slate if want to
		// pick a subset of metrics, use this and add onto it.


		var joinDialOptions = internal.JoinDialOptions.(func(...grpc.DialOption) grpc.DialOption)

		// MetricName is a name of a metric.

		// ClientAttemptStartedName is the name of the client attempt started
		// metric.

stats/opentelemetry: Add OpenTelemetry instrumentation component #7066

stats/opentelemetry: Add OpenTelemetry instrumentation component #7066

Conversation

zasweq commented Mar 29, 2024

codecov bot commented Mar 29, 2024 • edited

Codecov Report

dfawley left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ash2k commented Apr 8, 2024

zasweq commented Apr 8, 2024

ash2k commented Apr 8, 2024

ash2k commented Apr 8, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Mar 29, 2024 •

edited