SixPatterns Streamlines Rails Observability with OpenTelemetry Logs

SixPatterns has detailed a streamlined implementation of OpenTelemetry (OTel) logs within a Ruby on Rails application to achieve vendor-agnostic observability. This approach allows the team to export logs directly to Grafana Cloud, reducing infrastructure complexity while avoiding vendor lock-in.

To achieve this, the team utilized a modular suite of gems: `opentelemetry-sdk`, `opentelemetry-logs-sdk`, `opentelemetry-exporter-otlp`, `opentelemetry-exporter-otlp-logs`, `opentelemetry-instrumentation-all`, and `opentelemetry-instrumentation-logger`. Rather than deploying a traditional OpenTelemetry Collector, SixPatterns opted to send logs directly from the Ruby SDK to the vendor via the OTLP protocol—a strategy feasible for applications with low log volumes.

Configuration is managed through a Rails initializer using `OpenTelemetry::SDK.configure` and standard OTLP environment variables, specifically `OTEL_EXPORTER_OTLP_ENDPOINT` and `OTEL_EXPORTER_OTLP_HEADERS`. For local development, the team uses `OTEL_LOGS_EXPORTER=console` to output log records directly to the terminal.

The Push for Standardization

OpenTelemetry provides a standardized framework for the three primary signals of observability: logs, metrics, and traces. By leveraging the OpenTelemetry Protocol (OTLP), developers can decouple application code from the backend provider. This architecture ensures that a team can migrate between different observability platforms—such as moving from Grafana Cloud to Datadog or New Relic—without rewriting the instrumentation logic within the application itself.

Improving the Ruby Ecosystem

During the implementation, SixPatterns identified and resolved two critical bugs within the OpenTelemetry Ruby SDK, contributing the fixes upstream to benefit the wider community. The first issue involved the exporter dropping the base path of the endpoint, which was resolved in version 0.5.1. The second bug caused the SDK to incorrectly treat HTTP 204 responses as failures, a flaw corrected in version 0.4.0.

These contributions resolve significant compatibility hurdles for Ruby developers using vendors like Grafana Cloud. By fixing these SDK errors, the implementation removes operational friction and makes the OTel ecosystem more robust for those seeking to avoid the overhead of managing a separate Collector process.

Future Outlook

As more Rails teams adopt OTel, the focus shifts toward refining the balance between direct-to-vendor exports and the use of Collectors for higher-volume traffic. While the SixPatterns model simplifies the stack for smaller workloads, the continued stabilization of the Ruby SDK remains essential for enterprise-scale adoption of vendor-neutral observability. This shift toward standardization reduces the long-term maintenance burden on developers and allows teams to focus on analyzing data rather than managing the plumbing of their observability pipeline.