Vendor-neutral OpenTelemetry logging in Rails, minus the Collector

Logs without lock-in

A team at SixPatterns has published a walkthrough of adding OpenTelemetry logging to a Rails application, choosing the standard specifically to avoid tying their observability pipeline to a single vendor. According to the post, which surfaced on Hacker News, OpenTelemetry produces three independent signals — logs, metrics and traces — so a team can adopt logging alone without pulling in the rest. Because all signals travel in the vendor-agnostic OpenTelemetry Protocol (OTLP) format, SixPatterns argues you can later move from Grafana Cloud to Datadog or New Relic without rewriting application code.

Skipping the Collector

The conventional OpenTelemetry deployment puts a Collector process, usually a sidecar container or a host-local service, between the app and the vendor. The application emits telemetry over the local network and the Collector batches it and forwards it onward.

SixPatterns bypassed that layer and exported logs straight from the Ruby SDK to Grafana Cloud, an approach they note is similar to how Scout APM's logging gem ships data directly from the app. Their log volume is small enough that the SDK's built-in batching covers it, though they still recommend a Collector when buffering, sampling or redaction need to happen outside the application.

The gems involved

OpenTelemetry's Ruby ecosystem is deliberately modular, and the post assembles six gems, each with one job:

• opentelemetry-sdk — the core framework and the configuration entry point
• opentelemetry-logs-sdk — adds the logging signal, which is separate from tracing
• opentelemetry-exporter-otlp — exports traces over OTLP
• opentelemetry-exporter-otlp-logs — exports logs over OTLP
• opentelemetry-instrumentation-all — bundles instrumentation for Rails, Rack, Active Record and more
• opentelemetry-instrumentation-logger — hooks the standard Ruby Logger so ordinary log messages become OpenTelemetry log records

Configuration

The exporter reads standard OTLP environment variables, so setup comes down to two of them: OTEL_EXPORTER_OTLP_ENDPOINT holding the vendor URL and OTEL_EXPORTER_OTLP_HEADERS carrying an Authorization header with the token.

An initializer in config/initializers/opentelemetry.rb then calls OpenTelemetry::SDK.configure, sets a service name and invokes use_all, which activates every instrumentation gem that has been loaded. SixPatterns wraps the initializer in a guard that exits early unless the endpoint variable is set, keeping local development silent.

For a quick sanity check before deploying, the post suggests OTEL_LOGS_EXPORTER=console, which prints log records to the terminal rather than sending anything to the vendor.

Two Ruby SDK bugs, two upstream fixes

Testing against Grafana Cloud exposed two places where the Ruby SDK behaved differently from other language SDKs and from the OpenTelemetry specification.

The first involved the base path. Some backends expect OTLP data at an endpoint with a specific prefix, such as /otlp for Grafana Cloud, but the exporter dropped that prefix when appending the signal path — turning an intended /otlp/v1/logs into /v1/logs. SixPatterns reported the problem as issue #2157 and landed the fix in PR #2158, released in opentelemetry-exporter-otlp-logs v0.5.1.

The second involved HTTP responses. Grafana Cloud acknowledges log ingestion with 204 No Content, but the exporter only treated 200 OK as success, so every export succeeded while being logged as a failure. The team raised issue #2043 and fixed it in PR #2044, shipped in v0.4.0 of the same gem.

Anyone running an older version of the exporter against Grafana Cloud may want to check whether they are seeing phantom export failures, or requests quietly going to the wrong URL, for these same reasons.

Next on the roadmap

With logs flowing, SixPatterns points to structured logging as the natural next step, naming the rails_semantic_logger gem as a starting point and hinting at a follow-up post covering its full OpenTelemetry integration.

Why it matters

Logging is often the last observability signal teams wire up, and Ruby's OpenTelemetry logging support is young enough that spec deviations like these two are still being shaken out. The post is useful on two fronts: it is a concrete, copy-pasteable recipe for Rails teams that want OTLP logs without operating a Collector, and it is a reminder that adopting a standard early sometimes means contributing fixes upstream. With both patches now released, the direct-export path SixPatterns describes is a practical option for small-volume Rails apps — and because the data format is vendor-neutral, switching backends later is a configuration change rather than a rewrite.