feat: OpenTelemetry.logger_provider API, ProxyLoggers, Configuration, and Instrument Registry

[kaylareopelle]

This PR has a few different features that are all somewhat related:

• Adds the APIs to set a global logger provider using OpenTelemetry.logger_provider
  • Related to this, introduces OpenTelemetry::Internal::ProxyLoggerProvider and OpenTelemetry::Internal::ProxyLogger classes for defaults.
  • Like in the main SDK with traces, these proxies are upgraded to real LoggerProviders/Loggers when set.
• Adds the ability to configure the logs exporter using OTEL_LOGS_EXPORTER. The options available are console, none, and otlp. The OTLP exporter option will fail gracefully unless the yet to be released opentelemetry-exporter-otlp-logs gem is available. This takes the ConfigurationPatch approach, similar to feat: Update metrics configuration patch #1548
• Adds a thread-safe registry for loggers to access the same logger based on name and version

Closes #1699
Closes #1702

[mwear]

Do we need a mutex here? We don't have it for the proxy tracer. I believe we can remove this because the delegate is set from proxy logger provider, which synchronizes access using its mutex.

[kaylareopelle]

Great question! I don't think we need it here. I was copying the setup in the ProxyMeter and didn't cross-reference what was going on with the ProxyTracer.

Should we remove the mutex from the ProxyMeter too?

opentelemetry-ruby/metrics_api/lib/opentelemetry/internal/proxy_meter.rb

Lines 28 to 37 in 6727391

	def delegate=(meter)
	@mutex.synchronize do
	if @delegate.nil?
	@delegate = meter
	@instrument_registry.each_value { |instrument| instrument.upgrade_with(meter) }
	else
	OpenTelemetry.logger.warn 'Attempt to reset delegate in ProxyMeter ignored.'
	end
	end
	end

[mwear]

I think it makes sense to align the three. For the purposes of this PR we can remove it from the proxy logger.

[kaylareopelle]

Great! Updated in 9e2b8ee

[mwear]

Is this case necessary? I ask because it differs from what we're doing in the TracerProvider.

[kaylareopelle]

It's been a minute since I wrote this, but I believe I did it to adhere to this part of the shutdown protocol:

Shutdown MUST be called only once for each LoggerProvider instance. After
the call to Shutdown, subsequent attempts to get a Logger are not allowed.
SDKs SHOULD return a valid no-op Logger for these calls, if possible.

(source)

There's similar verbiage for the Trace SDK.

I'm not sure if we adhere to this part of the Trace spec elsewhere. Maybe this part does the job well enough? But I'm not sure if that would sufficiently covers an attempt to get a tracer after shutdown.

opentelemetry-ruby/sdk/lib/opentelemetry/sdk/trace/tracer_provider.rb

Lines 72 to 75 in a1f1629

	if @stopped
	OpenTelemetry.logger.warn('calling Tracer#shutdown multiple times.')
	return Export::FAILURE
	end

What do you think?

[mwear]

I think the other piece of the puzzle (for traces) is here:

opentelemetry-ruby/sdk/lib/opentelemetry/sdk/trace/tracer_provider.rb

Lines 146 to 167 in a1f1629

	if result.recording? && !@stopped
	trace_flags = result.sampled? ? OpenTelemetry::Trace::TraceFlags::SAMPLED : OpenTelemetry::Trace::TraceFlags::DEFAULT
	context = OpenTelemetry::Trace::SpanContext.new(trace_id: trace_id, span_id: span_id, trace_flags: trace_flags, tracestate: result.tracestate)
	attributes = attributes&.merge(result.attributes) || result.attributes.dup
	Span.new(
	context,
	parent_context,
	parent_span,
	name,
	kind,
	parent_span_id,
	@span_limits,
	@span_processors,
	attributes,
	links,
	start_timestamp,
	@resource,
	instrumentation_scope
	)
	else
	OpenTelemetry::Trace.non_recording_span(OpenTelemetry::Trace::SpanContext.new(trace_id: trace_id, span_id: span_id, tracestate: result.tracestate))
	end

My interpretation of the spec is that after calling shutdown on a tracer provider all tracers issued by it, past or future, must be non-operational. That is, they will create no-op spans from there on out. They do not necessarily need to be an instance of a no-op tracer, if that makes sense.

I think we need to ensure that all loggers return early from on_emit after shutdown is called, then it doesn't really matter what kind of logger we return from the logger provider. For consistency, we can follow what we're doing for tracing. I'm open to other considerations though.

[kaylareopelle]

I hadn't thought about it that way! Thanks for breaking that down. I've updated the code to use this approach. See: 06e4b05