stdoutmetric exporter observability

[mahendrabishnoi2]

Fixes #7014

This PR adds support for below self observability metrics for stdoutmetric exporter

• otel.sdk.exporter.metric_data_point.inflight
• otel.sdk.exporter.metric_data_point.exported
• otel.sdk.exporter.operation.duration

These metrics are experimental and hence behind a feature flag OTEL_GO_X_OBSERVABILITY.
Definition of above metrics is available at https://github.com/open-telemetry/semantic-conventions/blob/v1.36.0/docs/otel/sdk-metrics.md

Observability Implementation Checklist

Observability Implementation Checklist

Based on the project Observability guidelines, ensure the following are completed:

Environment Variable Activation

• Observability features are disabled by default
• Features are activated through the OTEL_GO_X_OBSERVABILITY environment variable
• Use consistent pattern with x.Observability.Enabled() check ¹
• Follow established experimental feature pattern ²³

Encapsulation

• Instrumentation is encapsulated within a dedicated struct (e.g., Instrumentation)
• Instrumentation is not mixed into the instrumented component
• Instrumentation code is in its own file or package if complex/reused
• Instrumentation setup doesn't bloat the main component code

Initialization

• Initialization is only done when observability is enabled
• Setup is explicit and side-effect free
• Return errors from initialization when appropriate
• Use the global Meter provider (e.g., otel.GetMeterProvider())
• Include proper meter configuration with:
  • Instrumentation package name is used for the Meter
  • Instrumentation version (e.g. Version)
  • Schema URL (e.g. SchemaURL)

Performance

• Little to no overhead when observability is disabled
• Expensive operations are only executed when observability is enabled
• When enabled, instrumentation code paths are optimized to reduce allocation/computation overhead

Attribute and Option Allocation Management

• Use sync.Pool for attribute slices and options with dynamic attributes
• Pool objects are properly reset before returning to pool
• Pools are scoped for maximum efficiency while ensuring correctness

Caching

• Static attribute sets known at compile time are pre-computed and cached
• Common attribute combinations use lookup tables/maps

Benchmarking

• Benchmarks provided for all instrumentation code
• Benchmark scenarios include both enabled and disabled observability
• Benchmark results show impact on allocs/op, B/op, and ns/op (use b.ReportAllocs() in benchmarks)

Error Handling and Robustness

• Errors are reported back to caller when possible
• Partial failures are handled gracefully
• Use partially initialized components when available
• Return errors to caller instead of only using otel.Handle()
• Use otel.Handle() only when component cannot report error to user

Context Propagation

• Observability measurements receive the context from the function being measured (don't break context propagation by using context.Background())

Semantic Conventions Compliance

• All metrics follow OpenTelemetry Semantic Conventions
• Use the otelconv convenience package for metric semantic conventions
• Component names follow semantic conventions
• Use package path scope type as stable identifier for non-standard components
• Component names are stable unique identifiers
• Use global counter for uniqueness if necessary
• Component ID counter is resettable for deterministic testing

Testing

• Use deterministic testing with isolated state
• Restore previous state after tests (t.Cleanup())
• Isolate meter provider for testing
• Use t.Setenv() for environment variable testing
• Reset component ID counter for deterministic component names
• Test order doesn't affect results

Footnotes

1. https://github.com/open-telemetry/opentelemetry-go/blob/e4ab3141123d0811125a69823dbbe4d9ec5a9b8f/exporters/stdout/stdouttrace/internal/observ/instrumentation.go#L101-L103 ↩

2. https://github.com/open-telemetry/opentelemetry-go/blob/e4ab3141123d0811125a69823dbbe4d9ec5a9b8f/exporters/stdout/stdouttrace/internal/x/x.go ↩

3. https://github.com/open-telemetry/opentelemetry-go/blob/e4ab3141123d0811125a69823dbbe4d9ec5a9b8f/sdk/internal/x/x.go ↩

[flc1125]

In addition, we are missing a benchmark test case and its results based on the exporter.

[mahendrabishnoi2]

In addition, we are missing a benchmark test case and its results based on the exporter.

I didn't get this point. This module has benchmark tests similar to others. Could you please help me in understanding exactly what's missing?

[mahendrabishnoi2]

In addition, we are missing a benchmark test case and its results based on the exporter.

goos: darwin
goarch: arm64
pkg: go.opentelemetry.io/otel/exporters/stdout/stdoutmetric
cpu: Apple M1 Pro
                                 │ exporter.txt │
                                 │    sec/op    │
ExporterExport/Observability-8      16.38µ ± 3%
ExporterExport/NoObservability-8    15.92µ ± 1%
geomean                             16.15µ

                                 │ exporter.txt │
                                 │     B/op     │
ExporterExport/Observability-8     2.277Ki ± 0%
ExporterExport/NoObservability-8   2.277Ki ± 0%
geomean                            2.277Ki

                                 │ exporter.txt │
                                 │  allocs/op   │
ExporterExport/Observability-8       85.00 ± 0%
ExporterExport/NoObservability-8     85.00 ± 0%
geomean                              85.00

[mahendrabishnoi2]

@open-telemetry/go-approvers sorry for the ping. Is there anything pending from me on this PR?