[POC] Make scope attributes as identifying for Tracer, Meter, Logger

[pellared]

Spike for open-telemetry/opentelemetry-specification#4161 (and #3368)

API changes:

• Add Attributes attribute.Set field to instrumentation.Scope, logtest.ScopeRecords

Behavioral changes:

• The Tracer, Meter, Logger returned by the providers now handle scope attribute; the value is assigned by the SDK and it is seen as one of the identifying fields
• OTLP and STDOUT exporters set the instrumentation scope attributes
• Prometheus exporter exports the instrumentation scope attributes in otel_scope_info metric.

Remarks:

Zipkin exporter DOES NOT set the instrumentation scope attributes as it is not required by the spec: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk_exporters/zipkin.md. This may be a bug or missing feature in the spec.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.6%. Comparing base (078b2dd) to head (ea5fbd9).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #5806   +/-   ##
=====================================
  Coverage   84.6%   84.6%           
=====================================
  Files        272     272           
  Lines      22839   22858   +19     
=====================================
+ Hits       19325   19344   +19     
  Misses      3170    3170           
  Partials     344     344           

see 13 files with indirect coverage changes

[pellared]

@open-telemetry/go-maintainers, can you make a rough review if it looks like a good way to implement open-telemetry/opentelemetry-specification#4161? This PR is done in a PoC manner and it lacks unit tests - I just added few more assertions to validate the implementation.

I plan to make open-telemetry/opentelemetry-specification#4161 as "ready to merge" tomorrow.

[MrAlias]

This looks in line with our prior attempt: #3131

[dashpole]

Looks reasonable to me. Prometheus exporter is only supposed to add those attributes to the otel_scope_info metric, btw.

[pellared]

Prometheus exporter is only supposed to add those attributes to the otel_scope_info metric, btw.

I think this is what I described. If not then please update my description 😉

[dmathieu]

This look nice. Does it impact the benchmarks for tracer/meter/logger retrieval?

[XSAM]

Should we populate values to attributes to make sure the output actually has a value?

[pellared]

Agree. Leaving this open to not forget about it when I will be working on actual implementation.

[pellared]

This look nice. Does it impact the benchmarks for tracer/meter/logger retrieval?

It does (because there is a bigger memory footprint) but IMO not significantly. E.g.

pkg: go.opentelemetry.io/otel/sdk/log
cpu: Intel(R) Core(TM) i9-10885H CPU @ 2.40GHz
                        │   old.txt    │               new.txt               │
                        │    sec/op    │   sec/op     vs base                │
LoggerProviderLogger-16   639.8n ± 14%   738.4n ± 9%  +15.42% (p=0.009 n=10)

                        │   old.txt   │               new.txt               │
                        │    B/op     │    B/op      vs base                │
LoggerProviderLogger-16   349.0 ± 19%   463.0 ± 26%  +32.66% (p=0.009 n=10)

                        │  old.txt   │            new.txt             │
                        │ allocs/op  │ allocs/op   vs base            │
LoggerProviderLogger-16   1.000 ± 0%   1.000 ± 0%  ~ (p=1.000 n=10) ¹

[pellared]

Looks reasonable to me. Prometheus exporter is only supposed to add those attributes to the otel_scope_info metric, btw.

@dashpole, PTAL ea10e40