AppSignalでRuby on Railsアプリケーションを監視する完全ガイド

本番環境でアプリケーションを運用・保守する際には、アプリが期待どおりに動作しているという確信を持ち、異常が発生したときにすぐ気づける状態にしておきたいものです。少なくとも、エラーの追跡、パフォーマンスの監視、そしてアプリ全体を通じた特定のメトリクスの収集は行いたいところです。

しかし、私たち開発者は保守しやすいソリューションを好みます(そうですよね?)。そのため、あらゆるツールや統合、依存関係が乱雑に積み重なり、全体の把握を難しくしてしまうような状況は避けたいはずです。

この記事では、Ruby on RailsアプリケーションにAppSignalを導入し、アプリケーションの動作を明確に可視化する方法を解説します。

コードを実際に試す場合の前提条件:

• www.appsignal.com のアカウント
• Dockerがインストール済みで起動していること(docker-composeを使用)
  *この記事のサンプルアプリケーションを使用する場合のみ必要です

AppSignalのセットアップ

注: すでにお手持ちのRailsアプリケーションにAppSignalを導入する場合は、このセクションを読み飛ばしても構いません。その場合は、記事中のDocker関連の手順やRailsサーバーの再起動方法に関する説明も無視して、普段どおりにアプリケーションを再起動・再デプロイしてください。

ここでは、作業の開始点としてサンプルアプリケーションを使用し、Dockerでローカルマシン上で実行します。

以下のコマンドを実行して、リポジトリのクローン、依存関係のインストール、アプリケーションの起動を行います。

$ git clone --branch appsignal-setup/start-docker --single-branch https://github.com/choncou/sample_rails_app appsignal-setup
$ cd appsignal-setup
$ yarn start:compose

初回実行時は、Dockerイメージのビルドと依存関係のダウンロードに時間がかかることがあります。完了すると、Railsサーバー、PostgreSQLデータベース、Redisが起動します。ログにリクエストが表示され、https://localhost:3000/ で動作中のアプリケーションを確認できます。

サンプルアプリケーションについて

今回扱うアプリケーションは非常にシンプルなので、押さえておくべきポイントはいくつかだけです。

PostモデルとPostsControllerがあり、/postsルート経由ですべてのCRUD操作が公開されています。

また、PagesControllerによってレンダリングされるホームページがあり、ランダムな投稿を非同期に生成するバックグラウンドジョブCreateRandomPostsJobがエンキューされます。

さらに、バックグラウンドジョブの処理にはSidekiqを使用しています。

この小さなブログプラットフォームには、すでにアクティブなユーザーもいます。サーバーと一緒にバックグラウンドで稼働するスクリプト(./bin/traffic)が定期的にリクエストを送信し、アプリへのアクセスを再現しています。

以上です。製品をリリースしたばかりで、すべてが完璧に動いている……はずでした。

しかし、アプリのパフォーマンスに関するユーザーレポートやエラーに遭遇する報告が届き始めると、話は変わります。

では、何が起きているのかをどう把握すればよいのでしょうか?開発環境ならエラーの調査は比較的簡単ですが、本番環境で稼働しているアプリとなると話は別です。サーバーログを延々と漁るよりも、エラーを見つける良い方法があるはずです。

そんなときこそ、AppSignalの出番です!

AppSignalを使い始める

それでは、アプリケーションにAppSignalを追加して、監視の旅を始めましょう。www.appsignal.com のアカウントにログインしてください。

AppSignalを初めて利用する場合は、アプリケーションを追加するための以下のようなページが表示されます(既存ユーザーの場合は「Add app」をクリックします)。

「Install for Ruby」を選択すると、従うべき簡単なステップが表示されます。

1. Gemfileにgemを追加する

   # Gemfile
   gem 'appsignal'

2. Dockerコンテナ内でbundle installを実行してgemをインストールする。yarn compose:shでコンテナに入れます

   $ yarn compose:sh
   # Dockerコンテナ内のbashコンソールに入りました
   $ bundle install
   # 次のコマンドのため、このままコンソールを開いておいてください

3. AppSignalをインストールする

   インストール中に、2つの質問に答える必要があります。

   • Do you want to change how this is displayed in AppSignal? (y/n): n
   • How do you want to configure AppSignal?: 環境変数だけではなく設定ファイルを使用するため、1を入力します

   AppSignalのセットアップページに表示されているAPIキーを使用します。

   $ bundle exec appsignal install <your-api-key>
   ...
   ...
   #####################################
   ## AppSignal installation complete ##
   #####################################
    
     Sending example data to AppSignal...
     Example data sent!
     It may take about a minute for the data to appear on https://appsignal.com/accounts
    
     Please return to your browser and follow the instructions.

インストールスクリプトを実行すると、ブラウザ上でAppSignalのセットアップが完了したことが確認できます。「Go to app」をクリックすれば、開発環境用のAppSignalダッシュボードを表示できます。

インストールコマンドによってconfig/appsignal.ymlが生成され、環境ごとにAppSignalの設定を行えるようになります。詳細についてはAppSignalのRuby設定ドキュメントをご覧ください。

config/appsignal.ymlにはプッシュAPIキーが含まれています。通常は、これをファイルから削除して環境変数として管理します。ただし、この記事ではそこまでは不要です。

新しいgemをインストールしたため、変更を確実に反映させるにはアプリケーションの再起動が必要です。最も簡単なのは、サーバーが動作しているターミナルウィンドウ内でctrl-cを押してDockerコンテナを停止し、次のコマンドでもう一度docker-composeを起動することです。

$ yarn start:compose

依存関係が変更されたためDockerイメージが再ビルドされるので、少し時間がかかることがあります。

AppSignalのメインダッシュボード

アプリケーションがAppSignal付きで稼働するようになったので、ダッシュボードを見てみましょう。AppSignal上で稼働中のすべてのアプリケーションと環境を確認するには、appsignal.com/accounts にアクセスします。

アプリケーション名をクリックすると、AppSignalが標準で提供している監視機能を一通り確認できます。

トラフィック生成スクリプトのおかげで、数分もしないうちにデータが収集されているはずです。

メインダッシュボードからは、重要なアプリケーションメトリクスのハイレベルな概要をつかむことができます。ここから先は、AppSignalの中でもより具体的な領域を掘り下げていきます。

AppSignalのエラーダッシュボード

エラーページには、アプリケーションから報告されたすべてのエラーの一覧が表示されます。インストールスクリプトの実行時にテストエラーが送信されていますが、それ以外にもかなり定期的に発生しているエラーがあるのがわかります。エラーをクリックすると詳細ページが開き、問題のデバッグに役立ちます。

今回のケースでは、バックトレースセクションから、アプリのホームページ(/)においてapp/controllers/pages_controller.rb:7 homeでバリデーションエラーが発生していることがわかります。

その他のAppSignalダッシュボード

サイドバーの「Dashboard」を見ると、AppSignalが最初からいくつかのダッシュボードを用意してくれていることがわかります。

「Overview」ダッシュボードはすべてのアプリケーションで利用可能で、以下の情報を提供します。

• アプリケーションのエラー率
• スループット
• レスポンスタイム
• 詳細を掘り下げられるその他の最近のアクティビティ

さらに、「Active Job」と「Sidekiq」の2つのマジックダッシュボードもあります。AppSignalには多くの人気フレームワークやgemとの組み込み統合が備わっており、Railsアプリケーションで自動的に機能します。

これらのダッシュボードを表示すると、各統合に関連するアクティビティ情報が確認できます。Active Jobダッシュボードでは、キューごとのジョブ数や記録された各ジョブの処理時間などのグラフを見ることができます。ぜひ覗いてみてください。

アプリのパフォーマンス

Performance → Issue list 内では、AppSignalが計測しているアクションの一覧を確認できます。これらの計測データは、アプリケーションのどの部分がパフォーマンスを大量に消費しているのかについて、貴重な洞察をもたらしてくれます。

たとえば、PostsController#indexアクションのissueをクリックすると、そのコントローラのパフォーマンスをさらに深掘りできます。最も時間がかかっている箇所や、オブジェクト割り当てが最も多い箇所の内訳をすぐに確認できます。

AppSignalの隠れた機能:Pumaの活用

AppSignalには、ほとんど手間をかけずに得られる隠れた便利機能(もちろんRubyのgemではなく、です)がいくつかあります。例を使って、これらをどれほど簡単に有効化できるのか見てみましょう。

config/puma.rbに以下の1行を追加します。

# config/puma.rb
plugin :appsignal

アプリを再起動する前に、docker-compose.ymlの12行目以降に以下の環境変数を追加します。

# docker-compose.yml
APP_REVISION: "latest_version_tag"

Pumaサーバーの設定とdocker-composeの設定を更新したので、ctrl-cでDockerコンテナを停止し、yarn start:composeでもう一度docker-composeを起動します。

新しいインサイトの追跡

サーバーが再起動したら、1分ほど待ってからAppSignalダッシュボードに戻り、ページを更新してみましょう。新しい情報が現れる主なエリアは2つあります。

1つ目は、自動生成された新しいPumaメトリクスのマジックダッシュボードです。AppSignalのPumaとの組み込み統合により、アプリケーションサーバーの稼働状況に関する情報を取得できるようになりました。設定ファイルでpluginを指定することで、Pumaサーバーに関するメトリクスを報告する毎分プローブが有効になります。

最後に、AppSignalダッシュボード全体にデプロイマーカーが表示されるようになります。APP_REVISION環境変数には、gitコミットSHAなど、アプリケーションの現在のバージョンを判別できる任意の値を設定できます。

また、ダッシュボードの「Deploys」セクションでデプロイ履歴を確認したり、エラーやパフォーマンスissueリストなどのインサイトをデプロイ単位で絞り込んだりすることもできます。デプロイ間でパフォーマンスや信頼性がどう変化したかを確認できるため、どの変更が新たなバグを引き起こした可能性があるのかを突き止めやすくなります。

次回予告:Rubyアプリ向けのカスタム計測とモニタリング

この記事では、AppSignalをアプリケーションにセットアップして活用することで、実運用環境でのコードの可視性を高める方法を紹介しました。

Rails本体だけでなく、SidekiqやPumaといったアプリケーションの依存関係との自動的な統合についても確認しました。AppSignalは他にも多数のRubyフレームワークやgemと、追加設定なしで連携できます。AppSignalのRuby統合の完全なリストはこちらから確認できます。

シリーズ第2部では、より深い洞察を得るために、Ruby on Railsアプリケーションへカスタム計測とモニタリングを追加する方法を取り上げます。

それでは、また次回お会いしましょう!

追伸: Ruby Magicの記事が公開されたらすぐに読みたい方は、Ruby Magicニュースレターを購読して、最新記事をお見逃しなく!