OpenTelemetry tracing without touching your infrastructure

Most “add observability to your Rails app” guides start with standing up a collector. The part that’s actually tedious isn’t the collector — it’s getting the right environment variables into every environment consistently, by hand, without typos, every time a new service joins.

What the platform actually sets

Settings → General → OpenTelemetry takes an OTLP endpoint, a protocol (http/protobuf, http/json or grpc), and optional headers — an API key for Honeycomb, say. Headers are stored encrypted. On the next deploy, Railyard sets exactly what every OpenTelemetry SDK already expects to read:

• OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL, OTEL_EXPORTER_OTLP_HEADERS
• OTEL_SERVICE_NAME — the app’s own name, not something to invent
• OTEL_RESOURCE_ATTRIBUTES — carries the commit SHA, environment, app and team, so a trace is attributable to an exact deploy without wiring that up yourself

Set any of these yourself and your value wins — this is a default, not a lock-in.

What ships with your app, not with the platform

The variables are platform-side. The actual instrumentation is still the vendor-neutral SDK, which you add like any other dependency:

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

Nothing about this is Railyard-specific — the same SDK works unmodified against any OTLP collector, which is the actual point of the protocol. The platform’s job ends at getting the variables right every time, not at replacing the instrumentation layer.

The platform’s own metrics, on the same pipe

Tick also send Railyard’s CPU, memory and request metrics and the platform posts its own numbers to <endpoint>/v1/metrics every minute, over OTLP HTTP — so infrastructure metrics and application traces land in the same backend instead of two separate dashboards you have to mentally correlate.

Where this sits next to logs and alerts

OpenTelemetry covers traces and metrics; day-to-day log search, saved searches with alerts, and log drains to your own sink are a separate, simpler path that needs no SDK at all — useful when a trace is overkill and you just need to grep production output. Metric alerts (p95 response time, 5xx rate, memory, CPU) work independently of whether OTel is configured.

Full reference: Logs, metrics and alerts.