En un proyecto reciente en Rails, el equipo de SixPatterns necesitaba incorporar observabilidad sin quedar atado a un único proveedor, por lo que recurrió a OpenTelemetry. OpenTelemetry genera tres señales de telemetría independientes (logs, métricas y trazas), todas transportadas mediante el formato neutral OTLP, que permite cambiar de backend (Datadog, New Relic o Grafana Cloud) sin modificar el código de la aplicación.
El artículo explica paso a paso cómo configuraron el SDK de Ruby de OpenTelemetry para exportar logs directamente a Grafana Cloud, prescindiendo del típico Collector como sidecar. Dado que su volumen de logs es reducido, el batching integrado del SDK resulta suficiente, aunque el Collector sigue siendo la opción recomendada cuando se requieren buffering, sampling o scrubbing fuera de la aplicación.
La configuración requiere seis gemas (opentelemetry-sdk, opentelemetry-logs-sdk, opentelemetry-exporter-otlp, opentelemetry-exporter-otlp-logs, opentelemetry-instrumentation-all y opentelemetry-instrumentation-logger), cada una con una responsabilidad concreta. Tras definir las variables de entorno OTEL_EXPORTER_OTLP_ENDPOINT y OTEL_EXPORTER_OTLP_HEADERS, un breve inicializador en Rails invoca OpenTelemetry::SDK.configure con c.use_all para activar toda la instrumentación incluida. La variable OTEL_LOGS_EXPORTER=console permite verificar el flujo en local antes de desplegar.
Durante la puesta en marcha detectaron dos errores en opentelemetry-exporter-otlp-logs: el exportador eliminaba la ruta base al añadir la ruta de la señal (corregido en la v0.5.1 mediante el PR #2158) y no reconocía el HTTP 204 No Content como respuesta exitosa, registrando cada ingesta en Grafana Cloud como un fallo (corregido en la v0.4.0 mediante el PR #2044).
Como siguiente paso, los autores apuntan al logging estructurado y sugieren la gema rails_semantic_logger como punto de partida.