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.
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.
We've made a list of all the tools AppSignal supports. It's pretty extensive:
|Rails features||Action Mailer|
|Rails features||Action Cable|
|Rails features||Active Record|
|Rails features||Active Job|
|Supported through ActiveRecord||PostgreSQL, MySQL, SQLite, etc.|
|Heroku integration||Heroku PostgreSQL|
|Background job||Delayed Job|
As I've said, the list is pretty long, which is why we won't dive into each and every tool in this post.
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.
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.
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.
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.
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 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.
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.
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.
The integration shows you the tracing for database calls, so you can see what query is the root of your evil (or genius) 😉
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.
With Redis integration, you'll see your calls to Redis appear in the 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:
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!
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.
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.
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.
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!