Tracing con OpenTelemetry sin tocar tu infraestructura

La mayoría de las guías de “agrega observabilidad a tu app de Rails” empiezan levantando un collector. La parte que de verdad es tediosa no es el collector — es meter las variables de entorno correctas en cada entorno de forma consistente, a mano, sin errores de tipeo, cada vez que un servicio nuevo se suma.

Qué define la plataforma en realidad

Settings → General → OpenTelemetry recibe un endpoint OTLP, un protocolo (http/protobuf, http/json o grpc), y headers opcionales — una API key para Honeycomb, por ejemplo. Los headers se guardan cifrados. En el siguiente despliegue, Railyard define exactamente lo que cualquier SDK de OpenTelemetry ya espera leer:

OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL, OTEL_EXPORTER_OTLP_HEADERS
OTEL_SERVICE_NAME — el propio nombre de la app, no algo que inventar
OTEL_RESOURCE_ATTRIBUTES — lleva el SHA del commit, el entorno, la app y el equipo, así que un trace es atribuible a un despliegue exacto sin que tengas que conectarlo tú mismo

Define cualquiera de estos tú mismo y gana tu valor — esto es un valor por defecto, no un lock-in.

Qué viene con tu app, no con la plataforma

Las variables son del lado de la plataforma. La instrumentación en sí sigue siendo el SDK neutral de proveedor, que agregas como cualquier otra dependencia:

Rails: opentelemetry-sdk, opentelemetry-exporter-otlp, opentelemetry-instrumentation-all con c.use_all, sobre http/protobuf.
Node: @opentelemetry/auto-instrumentations-node/register.
Python: opentelemetry-instrument.

Nada de esto es específico de Railyard — el mismo SDK funciona sin modificaciones contra cualquier collector OTLP, que es justamente el sentido del protocolo. El trabajo de la plataforma termina en poner las variables correctas cada vez, no en reemplazar la capa de instrumentación.

Las propias métricas de la plataforma, por el mismo tubo

Marca también enviar las métricas de CPU, memoria y requests de Railyard y la plataforma publica sus propios números a <endpoint>/v1/metrics cada minuto, sobre OTLP HTTP — así que las métricas de infraestructura y los traces de la aplicación aterrizan en el mismo backend en vez de dos dashboards separados que tienes que correlacionar mentalmente.

Dónde queda esto junto a los logs y las alertas

OpenTelemetry cubre traces y métricas; la búsqueda de logs del día a día, las búsquedas guardadas con alertas, y los drains de logs hacia tu propio destino son un camino separado y más simple que no necesita ningún SDK — útil cuando un trace es demasiado y solo necesitas hacer grep sobre la salida de producción. Las alertas de métricas (tiempo de respuesta p95, tasa de 5xx, memoria, CPU) funcionan independientemente de si OTel está configurado.

Referencia completa: Logs, métricas y alertas.