Dec 27th, ‘24/10 min read

Implementing OpenTelemetry in Ruby: A Guide for Developers

Learn how to integrate OpenTelemetry into your Ruby applications for better observability, performance insights, and debugging.

Implementing OpenTelemetry in Ruby: A Guide for Developers

In the software development landscape, observability has become a cornerstone for building reliable and maintainable applications.

For Ruby developers, integrating OpenTelemetry offers a standardized approach to collecting and analyzing telemetry data, enhancing the observability of their applications.

In this blog, we'll talk about setting up OpenTelemetry in your Ruby application, sampling strategies, applications, and more.

Implementing Distributed Tracing with OpenTelemetry | Last9
Implementing distributed tracing with OpenTelemetry helps track requests across services, providing insights into performance and pinpointing issues.

Implementing Distributed Tracing with OpenTelemetry

Setting Up OpenTelemetry in Ruby

To begin integrating OpenTelemetry into your Ruby application, follow these steps:

Install the OpenTelemetry SDK and Instrumentation Packages

Ensure your application is running Ruby version 2.5 or higher. Add the necessary gems to your Gemfile:

gem 'opentelemetry-sdk' 
gem 'opentelemetry-instrumentation-all'

Then, execute:

bundle install

Configure the OpenTelemetry SDK

Create an initializer file, such as config/initializers/opentelemetry.rb, and configure the SDK:

require 'opentelemetry/sdk' 
OpenTelemetry::SDK.configure do |c| 
  c.use_all 
end

This setup enables all available instrumentation, automatically capturing telemetry data from supported libraries and frameworks.

Set Up an Exporter

To visualize and analyze the collected telemetry data, configure an exporter that sends data to your chosen observability backend.

For example, to use the OpenTelemetry Protocol (OTLP) exporter:

require 'opentelemetry/exporter/otlp' 
OpenTelemetry::SDK.configure do |c| 
  c.use_all 
  c.add_span_processor( 
    OpenTelemetry::SDK::Trace::Export::BatchSpanProcessor.new( 
      OpenTelemetry::Exporter::OTLP::Exporter.new(endpoint: 'http://localhost:4317') 
    ) 
  ) 
end

Replace 'http://localhost:4317' with the endpoint of your observability backend.

Integrating OpenTelemetry with Elixir: A Step-by-Step Guide | Last9
Learn how to integrate OpenTelemetry with Elixir to monitor and troubleshoot your applications with traces, metrics, and logs.

Integrating OpenTelemetry with Elixir: A Step-by-Step Guide

Instrumenting Your Ruby Application

OpenTelemetry provides both automatic and manual instrumentation methods to capture telemetry data.

Automatic Instrumentation

The opentelemetry-instrumentation-all gem enables automatic instrumentation for a wide range of libraries and frameworks, including Rails, Sinatra, and ActiveRecord. This approach requires minimal configuration, as demonstrated in the setup above.

Manual Instrumentation

For custom code or unsupported libraries, manual instrumentation allows you to create spans and add attributes to trace specific operations:

require 'opentelemetry-api' 
tracer = OpenTelemetry.tracer_provider.tracer('my_app_or_library', '1.0.0') 

tracer.in_span('my_custom_operation') do |span| 
  # Your code here 
  span.set_attribute('custom_attribute', 'value') 
end

This approach provides granular control over the tracing of your application's operations.

The Role of OpenTelemetry Events in Improving Observability | Last9
Learn how OpenTelemetry events enhance observability by providing detailed insights into application performance and system behavior.

The Role of OpenTelemetry Events in Improving Observability

Exporting Telemetry Data

OpenTelemetry supports various exporters to transmit telemetry data to different backends. In addition to the OTLP exporter, you can configure other exporters based on your observability platform:

Jaeger Exporter

require 'opentelemetry/exporter/jaeger' 
OpenTelemetry::SDK.configure do |c| 
  c.use_all 
  c.add_span_processor( 
    OpenTelemetry::SDK::Trace::Export::BatchSpanProcessor.new( 
      OpenTelemetry::Exporter::Jaeger::AgentExporter.new(host: 'localhost', port: 6831) 
    ) 
  ) 
end

Replace 'localhost' and 6831 with your Jaeger agent's host and port.

Zipkin Exporter

require 'opentelemetry/exporter/zipkin' 
OpenTelemetry::SDK.configure do |c| 
  c.use_all 
  c.add_span_processor( 
    OpenTelemetry::SDK::Trace::Export::BatchSpanProcessor.new( 
      OpenTelemetry::Exporter::Zipkin::Exporter.new(endpoint: 'http://localhost:9411/api/v2/spans') 
    ) 
  ) 
end

Replace 'http://localhost:9411/api/v2/spans' with your Zipkin endpoint.

Choose the exporter that aligns with your observability infrastructure to effectively collect and analyze telemetry data.

Sampling in OpenTelemetry Ruby

Sampling is like the bouncer of observability—it decides which data gets in and which doesn’t, ensuring your app doesn’t drown in a flood of telemetry. OpenTelemetry

Ruby gives you flexible sampling options to strike the perfect balance between visibility and performance.

Let’s break it down.

Why Sampling Matters

In high-traffic or distributed systems, recording every trace can lead to a mountain of data—impractical to store, analyze, or pay for.

Sampling keeps things manageable by capturing a representative slice of your telemetry data, providing insights without slowing everything to a crawl.

Getting Started with OpenTelemetry Logging: A Practical Guide | Last9
Learn how to get started with OpenTelemetry Logging, streamline your observability, and enhance debugging with structured, context-rich logs.

Getting Started with OpenTelemetry Logging: A Practical Guide

Sampling Strategies in OpenTelemetry Ruby

1. TraceIdRatioBased Sampling

This strategy samples traces based on a fixed ratio. You set a value between 0.0 (capture none) and 1.0 (capture all) to control the sample rate.

Example: Sample 10% of traces

require 'opentelemetry/sdk'

sampler = OpenTelemetry::SDK::Trace::Samplers::TraceIdRatioBased.new(0.1) # 10% sampling

OpenTelemetry::SDK.configure do |c|
  c.use_all
  c.sampler = sampler
end

Use case: When you want a consistent percentage of traces, like a lightweight overview of app performance.

2. Always On Sampling

Want to see it all? AlwaysOn records 100% of traces—ideal for critical apps where every detail counts.

Example: Enable Always On

require 'opentelemetry/sdk'

sampler = OpenTelemetry::SDK::Trace::Samplers::AlwaysOn.new

OpenTelemetry::SDK.configure do |c|
  c.use_all
  c.sampler = sampler
end

Use case: High-priority environments requiring complete observability.

3. Always Off Sampling

This strategy collects no data—useful for tests or when telemetry isn’t needed (rare, but hey, it happens).

Example: Disable Sampling

require 'opentelemetry/sdk'

sampler = OpenTelemetry::SDK::Trace::Samplers::AlwaysOff.new

OpenTelemetry::SDK.configure do |c|
  c.use_all
  c.sampler = sampler
end

Use case: Debugging or specific test scenarios where telemetry gets in the way.

Kubernetes Observability with OpenTelemetry Operator | Last9
Learn how the OpenTelemetry Operator makes monitoring Kubernetes easier, so you can focus on what matters—keeping your apps running smoothly!

Kubernetes Observability with OpenTelemetry Operator

4. Custom Sampling Logic

Need more control? Custom samplers let you define rules based on context, attributes, or even whimsy.

Example: Sample traces with even trace IDs

require 'opentelemetry/sdk'

class CustomSampler < OpenTelemetry::SDK::Trace::Samplers::Sampler
  def should_sample?(context, trace_id, span_name, attributes)
    trace_id % 2 == 0 # Sample only even trace IDs
  end
end

OpenTelemetry::SDK.configure do |c|
  c.use_all
  c.sampler = CustomSampler.new
end

Use case: Tailored logic, like sampling high-value transactions or filtering by user type.

Choosing the Right Strategy

  • TraceIdRatioBased: Great for most apps; it’s simple and effective.
  • Always On: Use for debugging or mission-critical systems.
  • Always Off: Testing or development without telemetry overhead.
  • Custom Sampling: When you need observability that aligns with your app's quirks.

Adjusting Sampling Dynamically in OpenTelemetry Ruby

Fixed sampling rates work for many cases, but dynamic adjustments can offer flexibility during varying traffic or system states. For example:

  • High Traffic: Increase the sampling rate to capture more traces.
  • Low Traffic: Decrease the rate to save resources.

This can be achieved programmatically, such as altering the rate based on request metrics or error occurrences.

Monitoring Your Sampling Strategy

To ensure effectiveness, monitor:

  • Performance: Watch for latency or CPU spikes and adjust as needed.
  • Data Completeness: Verify enough traces are collected to spot issues or performance bottlenecks.
Getting Started with Host Metrics Using OpenTelemetry | Last9
Learn to monitor host metrics with OpenTelemetry. Discover setup tips, common pitfalls, and best practices for effective observability.

Getting Started with Host Metrics Using OpenTelemetry

OpenTelemetry in Ruby: Who’s Using It and Why?

OpenTelemetry is gaining traction across a variety of industries and use cases, including within Ruby applications. The versatility and power of OpenTelemetry make it an ideal choice for developers looking to enhance the observability of their applications.

Below are some of the key players and industries utilizing OpenTelemetry in Ruby, along with the various types of applications it supports.

1. Ruby on Rails Applications

Ruby on Rails remains one of the most popular frameworks for web development, and many Rails developers are turning to OpenTelemetry to get a better handle on their application's performance and health.

Developers can trace requests, database queries, and external service calls, helping to identify bottlenecks and improve overall response times.

Key benefits include:

  • Detailed Request Tracing: Track each request from the moment it enters the system through to the response, providing a comprehensive view of how the application is processing.
  • Database Query Performance: With the automatic instrumentation of ActiveRecord, developers can gain insights into how database queries are performing and where optimizations are needed.

2. Microservices Architectures

As microservices architectures become more prevalent, OpenTelemetry's ability to provide end-to-end traceability across distributed systems is a game changer.

Ruby applications that are part of a microservices environment can rely on OpenTelemetry to help them monitor communication between services, identify latency issues, and detect service failures more efficiently.

Microservices environments benefit from:

  • Distributed Tracing: OpenTelemetry allows tracing across different services, making it easier to identify where issues arise, whether it’s a single microservice or the interaction between multiple.
  • Service Dependency Tracking: By correlating traces, you can see how microservices depend on each other and where performance problems might occur within the service mesh.
Advanced OpenTelemetry: Sampling, Filtering, and Enrichment | Last9
OpenTelemetry offers powerful data collection, but maximizing its efficiency requires careful configuration. This article explores advanced techniques for sampling filtering, and data enrichment.

Advanced OpenTelemetry: Sampling, Filtering, and Enrichment

3. E-Commerce Platforms

In the competitive e-commerce space, where application uptime and performance directly impact revenue, OpenTelemetry is helping businesses track the health of their platforms.

From cart functionality to checkout processes, OpenTelemetry can monitor everything, ensuring users experience fast, reliable service.

For e-commerce applications, OpenTelemetry supports:

  • Transaction Tracing: By tracking user journeys from page load to transaction completion, developers can understand which parts of the process are slowing down and make data-driven improvements.
  • Real-Time Monitoring: OpenTelemetry helps with real-time monitoring of site performance, alerting developers to any issues before they become critical.

4. SaaS and Cloud-Native Applications

Software-as-a-Service (SaaS) and cloud-native applications are another big user group for OpenTelemetry, especially as these applications scale rapidly and involve multiple cloud-based services.

OpenTelemetry provides the observability needed to maintain reliability as these applications grow and evolve.

For SaaS providers, OpenTelemetry is beneficial in:

  • Cloud Infrastructure Monitoring: Gain visibility into the performance of cloud services such as databases, storage, and messaging systems.
  • API Performance Tracking: For API-first services, OpenTelemetry helps track the latency and reliability of APIs, ensuring users get fast and reliable responses.

5. Financial Services and Fintech

In the highly regulated and performance-sensitive financial services sector, OpenTelemetry offers transparency into how transactions and operations are handled by backend systems.

This is crucial for ensuring both performance and compliance with strict industry standards.

Applications in fintech benefit from:

  • Transaction Monitoring: OpenTelemetry helps track financial transactions across systems, making it easier to identify issues related to processing delays or service disruptions.
  • Compliance Tracking: Instrumenting various components of the system helps ensure all transactions are logged properly, assisting in audit trails and compliance requirements.
Convert OpenTelemetry Traces to Metrics with SpanMetrics | Last9
Already implemented tracing but lack metrics? With SpanConnector, you can convert trace data into actionable metrics. Here’s how to configure it.

Convert OpenTelemetry Traces to Metrics with SpanMetrics

6. Gaming and Entertainment

In gaming and entertainment applications, where real-time performance and user experience are essential, OpenTelemetry provides developers with the tools they need to troubleshoot issues quickly.

Whether it’s online multiplayer games or streaming platforms, OpenTelemetry can track user activity and the underlying system performance to prevent disruptions.

Gaming applications use OpenTelemetry for:

  • Latency Monitoring: Detecting and addressing latency issues in real-time to provide players with smooth and responsive gameplay experiences.
  • User Behavior Tracking: Understanding how players interact with the game or service helps improve features and performance.

7. DevOps and Continuous Integration/Continuous Delivery (CI/CD) Pipelines

DevOps teams and those working with CI/CD pipelines benefit significantly from OpenTelemetry's observability capabilities. By collecting telemetry data from various stages of the pipeline, DevOps teams can optimize workflows, prevent bottlenecks, and address issues that might impede software delivery.

DevOps use cases include:

  • Pipeline Monitoring: Monitoring build, test, and deployment processes to identify and troubleshoot failures early.
  • Service Monitoring in Staging and Production: Keeping track of staging environments in parallel with production environments ensures performance is stable across both.

8. IoT (Internet of Things) Applications

For IoT applications, where multiple devices and services communicate with one another, OpenTelemetry provides visibility into device performance and network communication. This is especially important for systems that rely on low-latency, real-time responses.

IoT applications benefit from:

  • Device Performance Monitoring: Instrumenting edge devices to track their health, performance, and any errors that might arise.
  • Network Communication Tracking: OpenTelemetry can be used to monitor the communication between devices, ensuring smooth and reliable interaction across the system.
Last9 review by Probo

Conclusion

OpenTelemetry in Ruby empowers developers with a robust observability framework. Regularly revisiting and refining your sampling strategy ensures it aligns with evolving application needs, helping maintain reliable and well-monitored systems.

🤝
If you’d like to explore further, join our community on Discord! We have a dedicated channel where you can discuss your specific use case with fellow developers.

Contents


Newsletter

Stay updated on the latest from Last9.

Authors

Aditya Godbole

CTO at Last9

Handcrafted Related Posts