DEV Community

Cover image for Getting Started: Your Ruby On Rails App Hosted On DigitalOcean With AppSignal
Aestimo K. for AppSignal

Posted on • Originally published at blog.appsignal.com

Getting Started: Your Ruby On Rails App Hosted On DigitalOcean With AppSignal

Imagine this: you’ve just finished working on your brand new Rails app and have deployed it to a cloud provider like DigitalOcean. Like any developer, you’re very proud of your work but you still have lots of questions, like:

  • How well your new app will handle traffic
  • Whether the optimizations you put in place will actually work, etc.

Your goal is to provide the best user experience. You want to be notified whenever errors or other important events occur so you can take care of them fast.

It would be great to have a setup that automatically monitors your application. Enter AppSignal! In this article, the first part of a two-part series, we'll set AppSignal up so that you can effectively monitor your Rails app hosted on DigitalOcean.

Prerequisites

To follow along, make sure you have:

  • A local installation of Ruby (this tutorial uses version 3.3.0).
  • A local PostgreSQL installation (you can use a Docker version or a locally installed version).
  • A DigitalOcean account to deploy the application.
  • An AppSignal account (a free 30-day trial is available).

An Introduction To Our Ruby On Rails App

For this tutorial, we'll be using a simple Rails 7 expense tracker app. Users will be able to sign up and create entries for their personal expenses, to track their expenses over time.

We'll deploy this app to DigitalOcean, then configure AppSignal's monitoring solution to keep track of what is going on under the hood.

You can grab the source code or fork the app from here to follow along.

Deploying Your Rails App To DigitalOcean

We'll use DigitalOcean's app platform to deploy our application. The steps below assume that you've already forked the expense tracker app described above and that you have a DigitalOcean account ready to go.

After logging in, we'll create an app and get it up and running. Since we want to control some parts of this process, though, the first step is to create a database for the app.

Creating the App Database

Click on the Databases link on the left-hand menu, then click on the Create Database link to create a new PostgreSQL database:

Create new app database

After completing the database settings in the next screen, take note of the database connection string. You'll use it as an environment variable when creating the app in the next step:

Finalize database creation

At this point, you'll likely get a warning that your database is open to all incoming connections. Follow the accompanying link to take care of this security warning.

Creating and Deploying the App

Finally, create the app by first clicking on the Apps link on the left side menu:

DigitalOcean app platform dashboard

Then connect the app's code repository resource as shown below:

Connect app code repo

Continue to the environment variables screen and insert the copied database URL string. Also, add the RAILS_MASTER_KEY as an environment variable since it will be used in the deployment process.

Setting up the environment variables

Then, with these environment variables in place, click on the Next button to deploy the app:

App deployed

With the app successfully deployed, we'll now set up monitoring using AppSignal.

Setting up AppSignal to Monitor Your Rails App

First, log in to your AppSignal account and choose 'Ruby & Rails'.

Now add the AppSignal gem to the Rails app. This nifty gem will collect errors, exceptions, and relevant performance data, and port it over to AppSignal for analysis.

Open up the app's Gemfile and add the gem:

# Gemfile
gem "appsignal"
Enter fullscreen mode Exit fullscreen mode

Then run bundle install.

Finally, you'll need to run the installation script that comes with your account-specific API key attached. When you run this install script, you should get something similar to the below:

 bundle exec appsignal install <redacted>

#######################################
## Starting AppSignal Installer      ##
## --------------------------------- ##
## Need help?  support@appsignal.com ##
## Docs?       docs.appsignal.com    ##
#######################################

Validating API key...
  API key valid!

Installing for Ruby on Rails

  Your app's name is: 'ExpenseTracker'
  Do you want to change how this is displayed in AppSignal? (y/n): n
How do you want to configure AppSignal?
  (1) a config file
  (2) environment variables
  Choose (1/2): 1

Writing config file...
  Config file written to config/appsignal.yml

#####################################
## AppSignal installation complete ##
#####################################

  Sending example data to AppSignal...
  Example data sent!
Enter fullscreen mode Exit fullscreen mode

There are a couple of things to note when you run the script:

  • You'll get the option to change your app's name as it will appear on AppSignal's dashboard or leave the default option.
  • You'll also get the option to choose how you want AppSignal configured for your app. In my case, I went with the config file option, creating a config file in config/appsignal.yml, with the below content:
# config/appsignal.yml

default: &defaults
  push_api_key: "<%= ENV['APPSIGNAL_PUSH_API_KEY'] %>"

  name: "ExpenseTracker"

development:
  <<: *defaults
  active: true

production:
  <<: *defaults
  active: true
Enter fullscreen mode Exit fullscreen mode

Here, we define:

  • A push_api_key which connects the app to AppSignal.
  • The app's name as it will appear on AppSignal.
  • The environments in which AppSignal will monitor the app (in this case, both development and production environments).

By the way, if you'd like to turn off AppSignal monitoring on the development environment, just set the active flag to false, like so:

...
development:
  <<: *defaults
  active: false
...
Enter fullscreen mode Exit fullscreen mode

Tip: Both the config file and environment variable options do the same thing. They define how AppSignal will connect to your app, the app name, and which environment will be monitored.

Assuming everything goes to plan, you should see a screen showing that AppSignal is receiving data from your app!

An Introduction to AppSignal's Dashboard for Rails

Now that everything is set up correctly and AppSignal is receiving data from your app, you can access the default app monitoring dashboard view as shown below:

Default Appsignal dashboard

Tip: If you set up monitoring for both development and production environments, you can easily switch between them from the selection shown by the arrow.

From the default view, you have access to the following default charts:

  • Error rate - This will show the rate of errors occurring in your app per unit of time.
  • Throughput - Here, you'll get a snapshot of the throughput your app is able to handle in terms of requests per minute.
  • Response time - This will show your app's response times.
  • Latest open errors - This section will list the latest errors that will have happened within your app.
  • Latest open performance measurements - This section lists the latest performance measurements, including method calls, API requests, etc.

Next, we'll see how to set up proper error tracking for a Rails application using AppSignal.

Monitoring Errors with AppSignal

There are more than ten error types that could affect a running Ruby on Rails app. Obviously, some are more common than others. In this section, we'll simulate a few of these errors and see how AppSignal handles them. Let's start with a simple example first.

Since the expense tracker app is using Devise for authentication, let's add a check for whether a user is signed in. Instead of using the recommended user_signed_in? method, let's use the erroneous user_logged_in? method, which should trigger an ActionView::Template::Error:

<!-- app/views/shared/_navbar.html.erb -->
...
<% if user_logged_in? %>
    <%= link_to 'Logout', destroy_user_session_path %>
<% else %>
    <%= link_to new_user_session_path do %>
    Login
    <% end %>
<% end %>
...
Enter fullscreen mode Exit fullscreen mode

Deploy this change, reload the production app, then go into the production environment dashboard in AppSignal and watch how this error shows up:

ActionView template error on AppSignal

AppSignal makes it a breeze to get more details on any errors that happen in an application. For example, we can get details about the ActionView template error by clicking on it from the 'Latest Open Errors' dashboard panel.

ActionView template error details

You can clearly see that the error is caused by an undefined method which points us in the right direction to fix it.

AppSignal's Errors dashboard also gives you extra information through the Logbook and Settings panels:

AppSignal error dashboard details

  • Logbook - Here, you or your team members can add comments to an error being tracked by AppSignal. The Logbook panel also shows a chronological breakdown of any actions taken regarding the error in question.
  • Settings - From this panel, you can assign an error to another team member, change alert settings (we'll check these out in detail in the second part of this tutorial), and set error severity.

And that's it for this part of the series!

Wrapping Up

In this tutorial, we deployed a simple Rails application to DigitalOcean's app platform and hooked it up to AppSignal's application monitoring platform. We also went through how errors are monitored and displayed in AppSignal's Errors dashboard.

Obviously, this is just scratching the surface of what's possible with AppSignal. In the second part of this series, we'll dive deeper into performance measurements, anomaly detection, uptime monitoring, and logging.

In the meantime, happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Top comments (0)