Developers work tirelessly to publish updates to improve their products and services because, as we all know, a better user experience = happier customers. While shipping updates, features, and improved capabilities can help improve your user’s experience, introducing new code can also introduce new issues; and finding exactly what update caused a release to degrade can be time consuming and costly.

As you're likely well aware, Rails 7 was released last month bringing a number of new features with it. One of the features we're most excited about is load_async. This features allows for multiple Active Record queries to be executed in parallel which can be a great tool for speeding up slow requests. Since Rails introduces an entirely new infrastructure for load_async, Skylight's existing integration wasn't capturing all of these queries.

Ruby is an object-oriented programming language celebrated for its simple and easy-to-read syntax. It powers Ruby on Rails, the open source web development framework that streamlines common development tasks involved in building web applications. We’re pleased to announce that our Continuous Profiler, which provides low-overhead, code-level performance insights, is now generally available for Ruby applications.

OpenTelemetry is enabling a revolution in how Observability data is collected and transmitted. See our What Is OpenTelemetry post on why this is an important inflection point in the Observability space. In this post, we’ll walk through how to configure the OpenTelemetry Gems within a Rails app.

Scroll down for the author’s photo and bio. Time series databases like InfluxDB index data by time. They are efficient at recording constant data streams like server metrics, application monitoring, sensor reports, or any other data containing a timestamp. The structure makes analyzing change over time a breeze. This tutorial will show you how to set up InfluxDB with a sample Ruby application.

OpenTelemetry is a project by the Cloud Native Computing Foundation aimed to standardize the way that application telemetry data is recorded and utilized by platforms downstream. This application trace data can be valuable for application owners to understand the relationship between the components and services in their code, the request volume and latency introduced in each step, and ultimately where the bottlenecks are that are resulting in poor user experience.

When running and maintaining an application in a production environment, we want to feel confident about the behavior of the application and know when it isn’t working as expected. At the least, we want to track errors, monitor performance, and collect specific metrics throughout the application.

If you maintain a Ruby gem, you are definitely familiar with the recurring manual tasks surrounding the release of a new version. After doing this for a while, you inevitably start thinking that some of these steps could be automated. They can! With a few lines of code, you can bring the amazing world of continuous delivery to your project and increase the reliability of the whole process while freeing up some of your time. Double win!

In this tutorial, we will go through a working example of a Ruby application auto-instrumented with OpenTelemetry. To keep things simple, we will create a basic “Hello World” application, instrument it with OpenTelemetry’s Ruby client library to generate trace data and send it to an OpenTelemetry Collector. The Collector will then export the trace data to an external distributed tracing analytics tool of our choice.