exporter/metric: Allow callers to provide a Cloud Monitoring client

[enocom]

Currently, the metric exporter creates a client based on configured options:

opentelemetry-operations-go/exporter/metric/metric.go

Line 114 in 19c4db6

client, err := monitoring.NewMetricClient(ctx, clientOpts...)

In some cases, callers may prefer to initialize their own Cloud Monitoring client and configure the exporter to use that client instead.

This would mean adding a new option like:

func WithMonitoringClient(cl *monitoring.MetricClient) func(o *options) {
	return func(o *options) {
		o.monitoringClient = cl
	}
}

This option would be mutually exclusive with WithMonitoringClientOptions, i.e., you provide one but not the other, and if both were provided WithMonitoringClient would be preferred.

cc @ridwanmsharif

[enocom]

Can you give some examples of why this is useful, I'm wondering what settings were useful that weren't already settable with the WithMonitoringClientOptions option (from here).

The AlloyDB Go Connector recently added support for built-in metrics following Bigtable and Spanner. Instead of having clients configure their own OTel exporter in the typical case, the Go Connector configures an exporter internally to send metrics about its internal operations. See GoogleCloudPlatform/alloydb-go-connector@508a7a4 for details.

What makes this more complicated is that we don't have all the necessary information to configure our exporter at initialization time. So we have to lazy initialize the exporter when a client calls our "Dial" method. The Dial method takes an instance URI that includes the project ID and other data necessary for the exporter. If callers only dial a single instance, we would have only one exporter and one metrics client. However, many callers use the Go Connector to connect to many instances. So we have to initialize a metric exporter for each unique instance.

The exporter isn't resource heavy, so it's a small cost to run multiple exporters. However, the metrics client runs a number of gRPC goroutines which may increase the resource usage when a caller uses the Go Connector for many instances. As a result, we'd like to use one metrics client across all the exporter instances.

FWIW, it's a common practice to allow configuration of an HTTP client in all the Google Cloud Go client libraries. So extending this library to support passing in the metrics client wouldn't be a departure from convention.