Application instrumentation is one thing that has stayed a top priority over almost every project I have worked on. Good observability data helps engineers identify when systems break and provides centralized storage for critical performance information.

Traditionally, vendors provided language-specific plugins, but this created vendor lock-in. OpenTelemetry offers an open standard for instrumentation across languages and vendors, enabling data ownership and platform flexibility.

What Are OpenTelemetry Signals?

OpenTelemetry emits three types of signals (ranked by importance):

1. Traces

Traces show a journey through an application for a particular request, displaying all components and dependencies working together. Individual pieces are called Spans. In Rails, this visualizes the incoming request, database calls, and response rendering in a time-series format.

Honeycomb trace example

2. Metrics

Point-in-time measurements for later analysis—counters, histograms, and value tracking over time. Rails examples include non-200 status code frequency or Sidekiq queue size.

3. Logs

Raw application logs output to stdout or services like Cloudwatch. When emitted via OpenTelemetry SDK, logs link to spans and metrics, providing contextual viewing for debugging.

Getting Started with Ruby

Installation

Add to Gemfile:

gem 'opentelemetry-sdk'
gem 'opentelemetry-exporter-otlp'
gem 'opentelemetry-auto-instrumentation'
gem 'opentelemetry-instrumentation-rails'

Configuration

Create an initializer:

require 'opentelemetry/sdk'
require 'opentelemetry/exporter/otlp'
require 'opentelemetry/instrumentation/all'

OpenTelemetry::SDK.configure do |c|
  c.service_name = 'my-rails-app'
  c.use_all()
end

The service_name identifies signal sources. The use_all() method enables auto-instrumentation for available libraries. In Rails, this automatically captures request lifecycle, database queries, and rendering time.

Adding Custom Context

Track customer-specific traces:

span = OpenTelemetry::Trace.current_span
span.set_attribute('enduser.id', current_user.id)

This follows OpenTelemetry’s Semantic Conventions for standardized attribute naming, enabling vendor-agnostic querying across monitoring systems.

Vendor Support

Honeycomb, Google, Newrelic, Github and Shopify are all active in developing the Ruby SDK, with growing observability vendor support for OpenTelemetry data ingestion.

References