Adding metric collection as part of instrumentations - Requests

[lzchen]

Adding the ability to collect metrics from instrumentation, starting with the requests instrumentation.

Semantic conventions for metrics can be found here

This is similar to what we did for grpc but abstracted in a way where we can extend this to all instrumentations.

The meter can be obtained by RequestsInstrumentor().meter and users can do what they want with the metrics.

Currently, there is only HTTPMetricRecorder which takes in a HTTPMetricType to indicate what kind of metrics it will generate. As more metric types and semantic conventions are defined, we can add more MetricRecorder s.

[owais]

Users pass in optional metric_exporter and metric_interval arguments to RequestsInstrumentor().instrument(), which will automatically start exporting metrics. If these are not supplied, metrics are simply collected but not exported. In this case, the meter can be obtained by RequestsInstrumentor().meter and users can do what they want with the metrics.

Is it possible today to register an exporter globally so automatically defined meters without explicit exporters can fallback on such an exporter?

[lzchen]

Is it possible today to register an exporter globally so automatically defined meters without explicit exporters can fallback on such an exporter?

I do not believe so. The lack of passing in an explicit exporter is also a signal to not have an export pipeline (but still capture the metrics data). This is useful if any post processing with the metrics is needed (such as combining the separate count metrics from different instrumentations to a single metric).

[aabmass]

What do you think about only exposing the meter property and removing this code, so users would have to do:

requests_instrumentor = RequestsInstrumentor(...)
metrics.get_meter_provider().start_pipeline(requests_instrumentor.meter, exporter, 5)

Then you can remove the opentelemetry-sdk dependency for the instrumentation. This might be overly pedantic, but depending on the opentelemetry-sdk prevents people from using a third-party SDK (if one ever existed).

[lzchen]

I was actually thinking about this approach originally, just expose the meter so users can decide what they want to do with it. I'm okay with t removing the automatically started pipeline. However, this feature requires the dependency on opentelemetry-sdk regardless, because of line 63 in metric.py in opentelemetry-instrumentation. To enable this, the sdk implementation of ValueRecorder must be used, so we MUST have a dependency on it. I think the message is: if you want to autocollect these metrics, this will be a feature offered by the default sdk and so you have to install it. I also don't know if the api and sdk separation of metrics makes sense today. Will we ever even have a different implementation of the metrics sdk? It's not really the same as the tracer, in which we would.

If there is a big push to not take a dependency on the sdk, we would probably have to change our metrics api implementation and create an explicit create_value_recorder method for the meter s. I'm actually okay with this, but might want to leave this for another pr. Thoughts?

[aabmass]

If there is a big push to not take a dependency on the sdk, we would probably have to change our metrics api implementation and create an explicit create_value_recorder method for the meter s. I'm actually okay with this, but might want to leave this for another pr. Thoughts?

Ya I agree it would be easy to work around that use of ValueRecorder later if we decide the instrumentation shouldn't take dependency on the SDK (it would be breaking change to the Instrumentor constructor though?). Could you explain why the api/sdk separation isn't the same with metrics as it is with tracer (I think I'm missing some background info)?

Would be great to get other Python SIG folks' thoughts on this too

[lzchen]

Could you explain why the api/sdk separation isn't the same with metrics as it is with tracer

I feel like we don't expect people to implement their own sdk to record + export metrics. It's as if we introduced the api + sdk separation simply to match what trace is doing.

[codeboten]

This discussion makes me wonder if the behaviour exposed in the ValueRecorder by the SDK should just be in the API then, instead of having an interface that is not usable with the SDK. If this isn't already being discussed in the metrics SIG, it should, I would suspect other SIGs are running into similar issues.

[lzchen]

Java implementation and Go implementation both have constructors for each metric instrument. So depending on whether they are using the sdk MeterProvider or not, it returns different implementations of the instrument, so they have an interface that is useable by the SDK. We should probably do something similar.

[hectorhdzg]

Is it possible to infer http.scheme as well here using url?

[lzchen]

Yes. However, if url is available, it takes priority since all components of the URI can be derived from it. See https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/metrics/semantic_conventions/http-metrics.md#parameterized-labels

[hectorhdzg]

This enumerator is currently being used to add more accurate description, what is the value of supporting both?

[lzchen]

The enumerator is not only for specifying the description. There are actually different labels that are needed depending on whether the type is client or server. "Adding both" refers to libraries that might actually emit both types, in which we would then have to create separate metric instances for duration.

[hectorhdzg]

LGTM