Remove severity-number exporter patch; map severity at emit time

[jrothrock]

Problem

CI started failing after opentelemetry-exporter-otlp-logs 0.7.0:

NoMethodError: undefined method 'as_otlp_any_value' for an instance of
OpenTelemetry::Exporter::OTLP::Logs::LogsExporter
# .../opentelemetry/log_record_patch.rb:20

log_record_patch.rb overrode the exporter's entire as_otlp_log_record method to remap Ruby's Logger::Severity integers (DEBUG=0, INFO=1, WARN=2, ERROR=3, FATAL=4) onto OpenTelemetry's SeverityNumber enum (DEBUG=5, INFO=9, WARN=13, …), the scale our UI matches on. Exporter 0.7.0 moved encoding into opentelemetry-exporter-otlp-common (Common.as_encoded_elsr), so as_otlp_log_record and as_otlp_any_value no longer exist and the override is never called. The CI failure was the patch's own unit spec calling the method directly.

This also means that on exporter 0.7.0, main was already sending Ruby's 0–5 integers as severity_number (INFO=1 is SEVERITY_NUMBER_TRACE in OTel).

The patch also carried the #114 guard (dropped_attributes_count vs total_recorded_attributes), so it couldn't just be deleted.

Fix

Severity is mapped at emit time. Formatter#emit_log sends the OTel SeverityNumber directly via SEVERITY_NUMBER_MAP, so every exporter version passes it through unmodified. log_record_patch.rb, its require_relative, and its spec are deleted.

• logger.unknown is labelled 'ANY' by Ruby's Logger. It now maps to FATAL, since it ranks above FATAL in Ruby; previously Logger::Severity.const_get('ANY') raised NameError. Unrecognized labels fall back to UNSPECIFIED.

#114 guard → LogRecordData shim (log_record_data_compat.rb). Every exporter release only requires opentelemetry-logs-sdk ~> 0.1, so on Ruby ≥ 3.3 Bundler can resolve pairs that disagree on LogRecordData's fields:

Exporter reads	Missing from
total_recorded_attributes (≤ 0.5.1)	logs-sdk ≥ 0.7.0
dropped_attributes_count (≥ 0.6.0)	logs-sdk < 0.7.0
event_name (≥ 0.5.0)	logs-sdk < 0.6.0

Any of these raises inside encode, which the exporter rescues, so every log is silently dropped. The shim defines only the missing field(s), derived from the others, and overrides no exporter methods. Checked against exporter 0.5.1 + sdk 0.8.1, 0.2.2 + 0.8.1, 0.6.0 + 0.4.0, and 0.5.1 + 0.4.0: all drop logs without the shim and export correctly with it. Matching pairs are unaffected.

Raising the gemspec floors instead was considered and rejected: exporter ≥ 0.6.0 and logs-sdk ≥ 0.7.0 both require Ruby ≥ 3.3, which would drop 2.x support for Ruby 3.1/3.2. (On 3.1/3.2, Bundler can only resolve exporter ≤ 0.3.0 with logs-sdk ≤ 0.4.0, which agree.)

Also: opentelemetry-logs-api is now a direct dependency, since the formatter references its constants.

Tests

• spec/unit/loggers/formatter_spec.rb (new): severity enum for every level, plus ANY and an unknown label, through an InMemoryLogRecordExporter.
• spec/unit/loggers/opentelemetry/log_record_data_compat_spec.rb (new): encodes a record through whichever encoder the installed exporter uses and asserts body, severity, and dropped_attributes_count == 0.
• spec/integration/rails/lifecycle_spec.rb: the stubbed receiver decodes severity_number / severity_text off the wire and asserts WARN/ERROR/FATAL/INFO. The receiver count assertions now check receiver_messages (they were re-checking local_messages).

All unit specs and the Rails lifecycle spec pass via rake test (Docker, Ruby 3.3, exporter 0.7.0 / logs-sdk 0.8.1). CI resolves the newest gems, so the mismatched pairs were checked separately against locally installed versions.

🤖 Generated with Claude Code

[quinnmil]

I'm approving. Had claude post a nitpic if you want to address.