Add tracing suppresing for Metrics Export

[hectorhdzg]

Fixes #3331

[codecov]

Codecov Report

Merging #3332 (30a1dca) into main (bbc1811) will increase coverage by 0.14%.
The diff coverage is 84.21%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3332      +/-   ##
==========================================
+ Coverage   93.47%   93.61%   +0.14%     
==========================================
  Files         243      223      -20     
  Lines        7321     5828    -1493     
  Branches     1517     1171     -346     
==========================================
- Hits         6843     5456    -1387     
+ Misses        478      372     -106     

Impacted Files	Coverage Δ
...y-sdk-trace-base/src/export/SimpleSpanProcessor.ts	83.33% <66.66%> (-7.98%)	⬇️
...etrics/src/export/PeriodicExportingMetricReader.ts	97.61% <100.00%> (+1.96%)	⬆️
...ckages/opentelemetry-core/src/internal/exporter.ts	100.00% <100.00%> (ø)
...ry-instrumentation-grpc/src/grpc-js/clientUtils.ts
...es/opentelemetry-instrumentation-http/src/utils.ts
...orter-metrics-otlp-proto/src/OTLPMetricExporter.ts
...grpc-exporter-base/src/OTLPGRPCExporterNodeBase.ts
...ental/packages/otlp-grpc-exporter-base/src/util.ts
...emetry-instrumentation-grpc/src/instrumentation.ts
...etry-sdk-node/src/TracerProviderWithEnvExporter.ts
... and 14 more

[dyladan]

coreExport is sort of an odd name for a function in core I think. Also can you please add tsdocs since it is very non-obvious what this does to an outsider.

[dyladan]

I worry a little bit about adding yet more API surface to the core module. I was hoping to eventually phase out the core module completely since it seems to just be a dumping ground for things. There also are other considerations beyond just suppressing tracing on export. We may for example want to suppress other signals like metrics.

[legendecas]

We should have a dedicated module to share common snippets across SDK packages. I find the problem with the @opentelemetry/core is that the APIs that are supposed to be internal are exposed as public interfaces. Would it make sense to you to explicitly document this method as an internal interface so that we don't provide any API stability guarantees? Or should we create a new internal util package?

[dyladan]

Seems like a reasonable compromise to document this as internal/unstable. IMO all of core should have been internal but it's too late for that.

[hectorhdzg]

Added internal tsdoc, under score is usually added at the beginning of the name of the function, I'm not sure if you are using this pattern in this repo but let me know if that is a problem https://tsdoc.org/pages/tags/internal/
@dyladan is Metrics signal suppression already defined or implemented somewhere in OpenTelemetry?, trace suppression should make the generated Spans to be "not recording" ones, those should not be considered for metrics, Ex. HTTP duration metrics.

[legendecas]

Seems like a reasonable compromise to document this as internal/unstable. IMO all of core should have been internal but it's too late for that.

I don't think "all" of them are internal. I suppose APIs like CompositePropagator are public -- as there is no good place to export them.

[hectorhdzg]

@dyladan @legendecas looks like this one is ready to merge, let me know if there is any concern. Thanks

[legendecas]

No, it's ready to go. Thanks for working on this!