AppSignalでDigitalOcean上のRuby on Railsアプリを監視する:初心者向け完全ガイド
想像してみてください。新しいRailsアプリの開発を終え、DigitalOceanのようなクラウドプロバイダーにデプロイしたばかりのところです。開発者であれば誰でも、自分の作品に誇りを感じる一方で、次のような不安や疑問が残るものです。
- 新しいアプリはトラフィックにどれくらい耐えられるのか
- 実装した最適化が実際に機能するのかどうか
目標は、最高のユーザー体験を提供することです。エラーや重要なイベントが発生した際にすぐ通知を受け取り、迅速に対処したいと考えるのは自然なことでしょう。
そんなときに役立つのが、アプリケーションを自動的に監視してくれる仕組みです。そこで登場するのがAppSignalです!本記事(全2回シリーズの第1回)では、DigitalOcean上でホストされているRailsアプリを効果的に監視できるよう、AppSignalをセットアップする方法を解説します。
前提条件
このチュートリアルに沿って進めるには、以下のものが必要です。
- ローカル環境にインストールされたRuby(本チュートリアルではバージョン3.3.0を使用)
- ローカル環境のPostgreSQL(Docker版またはローカルインストール版どちらでも可)
- アプリをデプロイするためのDigitalOceanアカウント
- AppSignalアカウント(30日間の無料トライアルあり)
今回使用するRuby on Railsアプリについて
本チュートリアルでは、シンプルなRails 7の出費管理アプリを使用します。ユーザーはサインアップして個人的な支出の記録を作成し、経時的な出費を追跡できるようになります。
このアプリをDigitalOceanにデプロイし、その後、内部で何が起きているかを把握できるようAppSignalの監視ソリューションを設定していきます。
ソースコードはこちらから取得するか、フォークしてチュートリアルに沿って進めることができます。
RailsアプリをDigitalOceanにデプロイする
アプリのデプロイには、DigitalOceanのApp Platformを使用します。以下の手順は、前述の出費管理アプリをすでにフォークしており、DigitalOceanアカウントの準備ができていることを前提としています。
ログイン後、アプリを作成して稼働させます。ただし、このプロセスの一部を制御したいので、最初のステップとしてアプリ用のデータベースを作成します。
アプリ用データベースの作成
左側メニューの「Databases」リンクをクリックし、次に「Create Database」リンクをクリックして、新しいPostgreSQLデータベースを作成します。

次の画面でデータベースの設定を完了したら、データベース接続文字列を控えておきましょう。これは次のステップでアプリを作成する際に、環境変数として使用します。

この時点で、「データベースがすべての外部接続に対して開放されています」という警告が表示される可能性があります。表示されるリンクに従って、このセキュリティ警告に対応してください。
アプリの作成とデプロイ
次に、左側メニューの「Apps」リンクをクリックして、アプリを作成します。

その後、以下のようにアプリのコードリポジトリリソースを接続します。

環境変数の画面に進み、コピーしておいたデータベースURL文字列を挿入します。また、デプロイプロセスで使用されるため、RAILS_MASTER_KEYも環境変数として追加してください。

これらの環境変数を設定したら、「Next」ボタンをクリックしてアプリをデプロイします。

アプリのデプロイが成功したら、次はAppSignalを使って監視をセットアップします。
AppSignalをセットアップしてRailsアプリを監視する
まず、AppSignalアカウントにログインし、「Ruby & Rails」を選択します。
次に、AppSignal gemをRailsアプリに追加します。この便利なgemは、エラー、例外、関連するパフォーマンスデータを収集し、分析のためにAppSignalへ送信します。
アプリのGemfileを開いて、gemを追加します。
そして、bundle installを実行します。
最後に、アカウント固有のAPIキーが添付されたインストールスクリプトを実行します。このスクリプトを実行すると、以下のような出力が得られるはずです。
スクリプト実行時に注意すべき点がいくつかあります。
- AppSignalのダッシュボードに表示されるアプリ名を変更するか、デフォルトのままにするかを選択できます。
- また、アプリ向けにAppSignalをどのように設定するかを選択できます。筆者の場合は設定ファイル方式を選び、
config/appsignal.ymlに以下の内容の設定ファイルを作成しました。
ここで定義しているのは以下の通りです。
- アプリをAppSignalに接続する
push_api_key - AppSignal上に表示されるアプリ名
- AppSignalがアプリを監視する環境(今回はdevelopmentとproductionの両方)
ちなみに、開発環境でのAppSignal監視をオフにしたい場合は、以下のようにactiveフラグをfalseに設定するだけです。
ヒント:設定ファイル方式と環境変数方式はどちらも同じことを行います。AppSignalがアプリに接続する方法、アプリ名、監視対象の環境を定義します。
すべてが計画通りに進んでいれば、AppSignalがアプリからデータを受信していることを示す画面が表示されるはずです!
Rails向けAppSignalダッシュボードのご紹介
すべてが正しくセットアップされ、AppSignalがアプリからデータを受信するようになったら、以下のようなデフォルトのアプリ監視ダッシュボードビューにアクセスできます。

ヒント:開発環境と本番環境の両方に監視を設定した場合、矢印で示されたセレクターから簡単に切り替えることができます。
デフォルトビューからは、以下の標準チャートにアクセスできます。
- エラー率(Error rate) - 単位時間あたりにアプリで発生するエラーの割合を表示します。
- スループット(Throughput) - アプリが処理できるリクエスト数(毎分)のスナップショットを確認できます。
- レスポンスタイム(Response time) - アプリのレスポンスタイムを表示します。
- 最新の未解決エラー(Latest open errors) - アプリ内で発生した最新のエラー一覧が表示されます。
- 最新のパフォーマンス測定値(Latest open performance measurements) - メソッド呼び出しやAPIリクエストなどを含む、最新のパフォーマンス測定値の一覧が表示されます。
次に、AppSignalを使ってRailsアプリケーションに適切なエラー追跡を設定する方法を見ていきましょう。
AppSignalでエラーを監視する
稼働中のRuby on Railsアプリに影響を与えうるエラーの種類は10種類以上あります。もちろん、よく見られるものとそうでないものがあります。このセクションでは、いくつかのエラーを意図的に発生させ、AppSignalがそれらをどう処理するかを確認します。まずはシンプルな例から始めましょう。
出費管理アプリは認証にDeviseを使用しているので、ユーザーがサインインしているかどうかのチェックを追加してみます。推奨されるuser_signed_in?メソッドの代わりに、誤ったuser_logged_in?メソッドを使用すると、ActionView::Template::Errorが発生するはずです。
この変更をデプロイし、本番アプリを再読み込みしてから、AppSignalの本番環境ダッシュボードに移動すると、このエラーが表示される様子を確認できます。

AppSignalを使えば、アプリ内で発生したあらゆるエラーの詳細情報を簡単に取得できます。例えば、「Latest Open Errors」ダッシュボードパネルからActionViewテンプレートエラーをクリックすれば、詳細を確認できます。

エラーが未定義のメソッドによって引き起こされていることが明確にわかり、修正への正しい方向性を示してくれます。
AppSignalのErrorsダッシュボードでは、「Logbook」と「Settings」パネルから追加情報も得られます。

- Logbook - ここでは、自分やチームメンバーが、AppSignalで追跡中のエラーにコメントを追加できます。Logbookパネルには、当該エラーに関して行われた対応の時系列の履歴も表示されます。
- Settings - このパネルから、エラーを別のチームメンバーにアサインしたり、アラート設定を変更したり(これについては本チュートリアルの第2部で詳しく解説します)、エラーの重要度を設定したりできます。
以上で、シリーズ第1部は終了です!
まとめ
本チュートリアルでは、シンプルなRailsアプリケーションをDigitalOceanのApp Platformにデプロイし、AppSignalのアプリケーション監視プラットフォームと連携させる方法を解説しました。さらに、エラーがAppSignalのErrorsダッシュボードでどのように監視・表示されるかについても確認しました。
もちろん、これはAppSignalで可能なことのほんの一部にすぎません。シリーズ第2部では、パフォーマンス測定、異常検知、アップタイム監視、ログ管理についてより深く掘り下げていきます。
それまでは、Happy Coding!
P.S. Ruby Magicの記事を公開と同時にお読みになりたい方は、Ruby Magicニュースレターを購読して、記事を見逃さないようにしましょう!
-
Rubyで例外発生時にローカル変数とインスタンス変数をログに記録する方法
簡単には再現できないバグに悩まされたことはありませんか?アプリをしばらく使い続けたユーザーの環境でだけ発生し、エラーメッセージやバックトレースを見ても原因がさっぱり分からない——そんな経験を持つ開発者は多いはずです。 こうした場面で役立つのが、例外が発生する直前のアプリの状態をスナップショットとして記録しておく手法です。たとえば、すべてのローカル変数とその値の一覧を取得できれば、デバッグの強力な手がかりになります。実は、これは思ったより簡単に実現できるのです。 この記事では、例外発生時点でのローカル変数をキャプチャする方法を紹介します。ただし、最初に重要な注意点があります。ここで紹介するテ
-
コードリーディングの冒険:awesome_print gem の仕組みをソースコードから探る
awesome_print は、irb や pry での出力を色付きで整形し、格段に読みやすくしてくれる Ruby gem です。 たとえば、ハッシュを awesome_print で表示すると、次のようにインデントとカラーが付いた見やすい出力になります。 しかし、この美しい出力は一体どうやって実現されているのでしょうか? 「真実はコードの中にしかない。」 ― Robert C. Martin というわけで、今回は実際にソースコードを読みながら、その仕組みを探っていきましょう。 コードリーディングの進め方 私がコードリーディングを始めるときは、まずプロジェクトの構成(ファイルやフォルダ)をざ