OpenTelemetry en Rails: configurar logs sin vendor lock-in

Por qué OpenTelemetry ya no es opcional para tu app Rails

En 2026, el mercado global de herramientas y plataformas de observabilidad mueve US$11.910 millones y proyecta llegar a US$22.990 millones en 2031 según MarketsandMarkets, con una tasa de crecimiento anual compuesta del 14,1%. Y dentro de ese mercado, OpenTelemetry (OTel) pasó de ser una opción a ser la línea base: Gartner afirma que los compradores empresariales ya lo consideran un requisito, no un diferenciador, según el último Magic Quadrant for Observability Platforms recogido por Network World.

¿Qué significa eso para un founder con una app Rails en producción? Que mantenerte en un agente propietario de logs es cada vez más caro y más frágil. La consultora Six Patterns publicó esta semana una guía práctica configurando el SDK de OpenTelemetry en Ruby para exportar logs OTLP directamente a Grafana Cloud, sin pasar por un Collector. En el camino, detectaron dos bugs del SDK que arreglaron upstream, y la receta que dejaron sirve como modelo para cualquier startup que quiera salir del vendor lock-in sin reinventar su stack.

¿Qué problema resuelve esta configuración?

El setup clásico de OpenTelemetry usa un OpenTelemetry Collector como proceso aparte, normalmente un sidecar o un servicio en el mismo host. Tu aplicación envía telemetría por la red local, el Collector batcha los datos y los reenvía al vendor (Datadog, New Relic, Grafana Cloud, etc.).

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Six Patterns decidió saltarse ese paso: configuró el SDK de Ruby para exportar logs directamente a Grafana Cloud sobre OTLP, apoyándose en el batching interno del SDK. ¿Por qué les funcionó? Porque su volumen de logs es bajo. Pero aclaran: si necesitas buffering, sampling o scrubbing fuera de la app, el Collector sigue siendo la mejor opción. Para una startup en etapa temprana o con tráfico moderado, el bypass es válido.

Los gems y el código que necesitas

La receta que documentaron es directa y cabe en cualquier Gemfile:

gem "opentelemetry-sdk"
gem "opentelemetry-logs-sdk"
gem "opentelemetry-exporter-otlp"
gem "opentelemetry-exporter-otlp-logs"
gem "opentelemetry-instrumentation-all"
gem "opentelemetry-instrumentation-logger"

Cada gema cumple un rol específico:

opentelemetry-sdk: el framework núcleo, punto de entrada de configuración.
opentelemetry-logs-sdk: añade soporte a la señal de logs (separada de los traces).
opentelemetry-exporter-otlp y opentelemetry-exporter-otlp-logs: exportación por red vía OTLP.
opentelemetry-instrumentation-all: bundle de instrumentaciones para Rails, Rack y Active Record.
opentelemetry-instrumentation-logger: conecta el Logger estándar de Ruby para que cada línea de log se convierta en un log record de OpenTelemetry.

Después se setean dos variables de entorno con el endpoint y token del vendor, y se inicializa el SDK en un initializer (config/initializers/opentelemetry.rb):

return if ENV["OTEL_EXPORTER_OTLP_ENDPOINT"].blank?
OpenTelemetry::SDK.configure do |c|
  c.service_name = "our-rails-app"
  c.use_all
end

Para probarlo en local sin tocar producción, basta con setear OTEL_LOGS_EXPORTER=console y los logs se imprimen en tu terminal en lugar de enviarse al vendor. Es la forma más rápida de validar la configuración antes del deploy.

Los dos bugs que Six Patterns arregló upstream

La parte más interesante del post no es el setup, sino los dos issues reales que detectaron al exportar a Grafana Cloud y que ya quedaron resueltos en el SDK de Ruby:

El exporter descartaba el base path. Grafana Cloud espera los logs en /otlp/v1/logs, pero el exporter enviaba a /v1/logs, perdiendo el /otlp configurado. Lo reportaron en el issue #2157 y lo arreglaron en el PR #2158, liberado en opentelemetry-exporter-otlp-logs v0.5.1.
Solo trataba el HTTP 200 como éxito. Grafana Cloud responde con 204 No Content después de ingestar logs, lo que el SDK registraba como fallo aunque la exportación hubiera salido bien. Issue #2043, PR #2044, liberado en v0.4.0.

Es el tipo de contribución chica que tiene impacto multiplicador: cualquier startup que use OTLP contra un backend con /otlp en la URL o que responda 204 se beneficia gratis de esos fixes.

Qué significa esto para tu startup

La historia de Six Patterns importa más allá de Rails. Refleja tres tendencias que ya están en los números del mercado:

OpenTelemetry es commodity, el valor está en lo que construyas encima. Según Gartner, citado por Network World, el 5% de sus clientes ya gasta más de US$10 millones al año con un solo proveedor de observabilidad. El estándar abierto bajó la barrera de cambio, así que la pelea se gana en analytics, automatización, IA y UX, no en agentes propietarios.
El Collector-first es la arquitectura madura, pero no la única. Un análisis de Bank Info Security describe el patrón edge/gateway: edge ligero cerca de la app, gateway centralizado para escalar ingesta. Para una startup, empezar directo desde el SDK y añadir Collector cuando el volumen lo justifique es una decisión de capital eficiente.
Los microservicios y serverless generan 50 a 100 veces más telemetría que los monolitos, según el análisis del mercado 2026 de ETCIO. Eso vuelve inviable el enfoque «agente propietario a perpetuidad». Adoptar OTLP desde el día uno evita una migración dolorosa cuando escales.

Acciones concretas que puedes tomar esta semana

Audita qué vendor lock-in tienes hoy. Lista cuántos agentes de telemetría corren en tu stack, cuántos SDKs específicos de proveedor y cuánto cuesta migrar cada uno a un exporter OTLP neutro. El coste real aparece cuando intentas cambiar, no cuando firmas.
Empieza por una señal, no por las tres. Elige logs (como hizo Six Patterns) o traces, configura el exporter OTLP directo al vendor que uses, y valida con OTEL_LOGS_EXPORTER=console antes de desplegar. Cuando esté estable, sumas metrics. OpenTelemetry es modular: adoptar una señal no obliga a las otras.
Mide el coste de telemetría desde el inicio. Gartner advierte que el control de costes por volumen de logs, traces y métricas es ya una de las principales preocupaciones de compra. Configura sampling, retención y atributos desde el día uno; un atributo de más en producción multiplicado por millones de requests pesa en la factura del mes.

El siguiente paso natural después de tener los logs exportados es structured logging, y Six Patterns sugiere empezar con la gema rails_semantic_logger como puerta de entrada. Eso ya es tema para otro post, pero la dirección es clara: la observabilidad abierta dejó de ser una declaración de principios y se convirtió en infraestructura básica.