The Easiest Way to Monitor Ruby: Automatic Instrumentation

Milica Milica Maksimović, Tom de Bruijn on

Setting up a proper monitoring overview over your application’s performance is a complex task. Normally, you’d first need to figure out what you need to monitor, then instrument your code, and finally make sense of all the data that has been emitted.

However, with a few things set in place, and an APM that natively supports Ruby, it’s easier than ever to take this step. In this post, we’ll show you how you can do it too.

Automatic Instrumentation - Handsfree APM Setup

To discover which pieces of your code are causing your performance issues, you’ll need to add instrumentation to it. That way, you can break down all the actions and measure which ones are the slowest.

With AppSignal’s automatic instrumentation, we take away as much manual work as we can. Just run a few commands through the CLI, and you’ll be set.

Our monitoring agent detects the different parts of your infrastructure and automatically instruments it. This enables AppSignal app to digest, process, monitor, and show you the graphs and dashboards you need the most.

That means that for example for the graphql gem for Ruby, AppSignal will instrument every GraphQL request that comes in, meaning it will provide a breakdown of all events in the request.

Out-of-the-box Instrumentation

We’ve made a list of all the tools AppSignal supports. It’s pretty extensive:

Type Tool
Framework Rails
Rails features Action Mailer
Rails features Action Cable
Rails features Active Record
Rails features Active Job
Rails features Caching
Supported through ActiveRecord PostgreSQL, MySQL, SQLite, etc.
Heroku integration Heroku PostgreSQL
Framework Padrino
Framework Sinatra
Gem Rack
Gem WebMachine
Web server Puma
Web server Unicorn
ORM DataMapper
ORM Sequel
ORM MongoDB
API Grape
API GraphQL
Standard library Net::HTTP
Background job Que
Background job Sidekiq
Background job Delayed Job
Background job Resque
Background job Shoryuken
Gem Rake

As I’ve said, the list is pretty long, which is why we won’t dive into each and every tool in this post.

Web Frameworks and APIs

AppSignal supports instrumentation of web requests in Ruby on Rails, Padrino, and Sinatra out-of-the-box. APIs using Grape or the GraphQL gem are also supported.

Ruby on Rails

The AppSignal integration for Rails works by tracking exceptions and performance in requests. When an error occurs in a controller during a request AppSignal will report it. Performance issues will be based on the duration of a request and create a timeline of events detailing which parts of the application took the longest.

dashboard

It’s even possible to track how long it took for HTTP requests to arrive at the Rails app through a loadbalancer of web server. If it’s not on by default, set up the request queue time tracking header and AppSignal will automatically graph the queue time.

queue time

GraphQL

AppSignal supports the graphql gem for Ruby. It will instrument every GraphQL request that comes in and provide a breakdown of all events in the request. You’ll be able to see how long it took to parse, validate and execute your resolvers. Events from the app’s web framework and database calls are of course included in this breakdown.

Screenshot of event timeline

This is great for those who wish to debug GraphQL queries that seem to take a long time, and you’re not sure where the slowdown could be occurring. Don’t forget about our anomaly triggers here also - these can be very useful for alerting when the query time reaches a certain threshold.

Sinatra, Padrino and Grape

Sinatra, Padrino and Grape are web and API frameworks for Ruby that can be part of an app in different ways. They are either a standalone app or mounted on a larger Rails app. Depending on how the app is mounted on a web server some different installation steps are needed for Sinatra, Padrino and Grape.

Once installed Sinatra, Padrino, Grape requests are all instrumented: errors and performance measurements are reported when traffic hits the API. Every (API) endpoint is its own action in AppSignal to easily find which endpoint encountered which error. As with Rails apps the performance breakdown provides insight in what database queries or other parts or the app were slower than others.

Databases

Active Record and other ORMs

To see how long a request took querying the database, open a incident detail page. On top of the page the types of events recorded in the request are broken down per group. Here you can see how much time in total was spend on what type of operation.

IncidentPageWithPostGreSQL

If we zoom in further on the performance of this sample, further down the page you’ll find a timeline of all events in the request in the order they occurred. This provides you with an overview of each query that was executed and which ones are taking the longest.

IncidentPageTimelineWithPostGreSQL

The integration shows you the tracing for database calls, so you can see what query is the root of your evil (or genius) 😉

IncidentPageTracingWithPostGreSQL

N+1 queries

Worried there may be N+1 queries occurring in the request and that’s what is slowing it down? If we detect N+1 queries a warning will appear in the event timeline for those events that were detected.

IncidentPageWithPostGreSQL

Redis

With Redis integration, you’ll see your calls to Redis appear in the Event Timeline:

Screenshot of event timeline

You’ll also be able to see the name of the command sent to Redis and the address of the Redis instance that the query was made to:

Screenshot of event timeline flyout

This is great news for those who wish to debug long running calls to a Redis cache. You can even set an anomaly trigger to send an alert on requests that run for a super long time!

Background Jobs

Whenever a background job is queued with Sidekiq, Delayed::Job, Resque, Shoryuken and Que AppSignal will automatically report errors and performance measurements. All Active Job adapters are also supported, and some background job libraries like Sidekiq and Delayed::Job report even more metadata from the libraries themselves.

IncidentPageWithPostGreSQL

Sending emails with Action Mailer

If Rails mailers using Action Mailer are set up to deliver_later they will also be routed through Active Job and can count on the same level of instrumentation.

Websockets

Using Action Cable in your Rails app? AppSignal automatically reports errors and performance measurements for messages and subscriptions. Every message is instrumented separately so even long running channels will report all activity. They are grouped per action giving a clear overview of how each individual action is performing.

Try AppSignal: Monitoring Made Easy And Sweet 🍪

Over the past 7 years, we’ve helped thousands of developers to automatically instrument their code, and we’d love you to try us out as well. When you do, feel free to reach out, we’ll send you a free box of stroopwafels as well.

PS. If you are helping the world with a great OSS project, we help you back with a free AppSignal account. Spread the word to the maintainers you value!

5 favorite Ruby articles

10 latest Ruby articles

Go back
Ruby magic icon

Subscribe to

Ruby Magic

Magicians never share their secrets. But we do. Sign up for our Ruby Magic email series and receive deep insights about garbage collection, memory allocation, concurrency and much more.

We'd like to set cookies, read why.