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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.