AppSignalを使用した次のレベルのRubyonRailsアプリケーション監視

この2部構成のシリーズの最初の部分では、Ruby on RailsアプリケーションでAppSignalをセットアップして、箱から出してすぐに多くの優れた洞察を得る方法について説明しました。 AppSignalは、エラーを自動的に追跡し、パフォーマンスを監視し、いくつかの依存関係に関するメトリックを報告できます。

ただし、多くの場合、アプリケーションはそれぞれ異なる動作をするため、一般的な監視以上のものが必要になります。

この投稿では、RubyonRailsアプリケーションにカスタムインストルメンテーションとモニタリングを追加する方法について説明します。これにより、アプリケーションがどのように動作しているかについて、より深い洞察が得られます。

コードをフォローする場合の前提条件：

• www.appsignal.comのアカウント
• Dockerがインストールされ、実行されています（docker-composeを使用するため） ）

この投稿をフォローするには、サンプルアプリケーションで独自のAppSignalアカウントを使用してAppSignalを設定する必要があります。

カスタム計測と監視

箱から出してすぐに使えるAppSignalインストルメンテーション以上のものが必要な場合、AppSignalgemを使用すると、Railsアプリケーションにカスタムインストルメンテーションを追加できます。

コードの一部を計測する

アプリケーションに新しい機能を追加したいとします。ユーザーが/postsにアクセスしたとき すべての投稿を表示するには、タイトルが特定の文字で始まる投稿（またはもっと複雑なもの🪄）をフィルタリングできる必要があります。

この新しい検索機能は、Postにすでに実装されています メソッドPost.where_title_starts_withを使用したモデル 。 PostsController#indexを更新しましょう 特定のクエリパラメータが存在する場合に新しいメソッドを使用するには：

# app/controllers/posts_controller.rb
  def index
    starts_with = params[:starts_with]
    @posts = if starts_with.present?
               Post.where_title_starts_with(starts_with)
             else
               Post.all
             end
  end

これはアプリケーションのコア部分であるため、アプリケーションのパフォーマンスとそのパフォーマンスがいつ変化するかを知りたいと思うでしょう。 AppSignalは、これを行うためのいくつかの方法を提供します。

まず、Post.where_title_starts_withのコンテンツをインストルメントします 方法。コードブロックに関する洞察を受け取りたい場合は、インストルメンテーションブロックを使用してコードブロックをラップできます。次のようにメソッドを更新します：

# app/models/post.rb
def self.where_title_starts_with(letter)
  Appsignal.instrument('Post.where_title_starts_with', "Fetch posts that start with letter") do
    Analytics.track_post_title_search(letter.downcase)
    select('*, pg_sleep(0.01)').where("title ILIKE :letter", letter: "#{letter.downcase}%").load
  end
end

次に、Analytics.track_post_title_searchもインストルメント化します。 app/services/analytics.rbのために呼び出されるメソッド 重い処理を行っています。この場合、メソッドインスツルメンテーションを使用して、メソッド全体をより正確にインスツルメントします。

# app/services/analytics.rb
require 'appsignal/integrations/object'
 
class Analytics
  def self.track_post_title_search(letter, sleep = sleep(1))
    # Some heavy processing
    sleep 1
  end
  appsignal_instrument_class_method :track_post_title_search
end

洞察

上記をアプリケーションに保存してから数分後、AppSignalダッシュボードで利用可能な新しい情報を確認します（情報が表示されない場合は、dockerコンテナーを再起動する必要がある場合があります）。検索パラメータ：http：// localhost：3000 / posts？starts_with =f

を使用して投稿のインデックスページにアクセスすると、新機能が機能することを確認できます。

データベースに作成された投稿の数に応じて、/posts エンドポイントはかなり遅くなります。

AppSignalでパフォーマンスの問題を開いて（「パフォーマンス」->「問題リスト」）、PostsController#indexを表示する場合 アクション、ページの下の方に、「イベントタイムライン」が表示されるはずです。これにより、特定のコードの実行に費やされた時間の内訳がわかります。

このタイムラインはすべてのパフォーマンスイベントに存在しますが、ここでは、カスタムインストルメンテーションイベントも表示されます。 Post.where_title_starts_withを呼び出すことを示しています 実行に8.84秒かかり、Analytics.track_post_title_searchが2.01秒を使い果たしました。 メソッド、およびアクティブなレコードクエリによって使用される残り時間。また、個々のイベントをクリックしてさらに調査し、それらのパフォーマンスに関する詳細情報を表示することもできます。 sql.active_record イベント。

AppSignalのインストルメンテーションヘルパーは、アプリケーションコードのより詳細な内訳を提供するため、アプリケーションのパフォーマンスに影響を与える可能性があると思われる特定のコードについての洞察を簡単に得ることができます。これについて詳しくは、AppSignalのインストルメンテーションガイドをご覧ください。

例外処理

コードのパフォーマンスを監視するだけでなく、アプリケーションが期待どおりに動作しない場合や、どこで問題が発生するかを知る必要もあります。 AppSignalがコードで処理されていない例外を報告する方法についてはすでに説明しました。しかし、箱から出てくるものよりも常に少し多くのものがあります。

断続的なエラーの原因となる既存のコードを削除することから始めることができます。ダッシュボードでエラーを表示すると、バックトレースでこのエラーが発生する場所がわかります。 app/controllers/pages_controller.rbの内部 ifを削除します ステートメント：

class PagesController < ApplicationController
  def home
    CreateRandomPostsJob.perform_later
  end
end

これで、概要ダッシュボードで、アプリケーションのエラー率が大幅に低下します。

現在、ユーザーが存在しない投稿を表示しようとすると、アプリケーションがクラッシュします（例：http：// localhost：3000 / posts / doesnotexist）。代わりに、メッセージを表示することをお勧めします。 PostsController内でこれが発生する可能性のある場所にarescueを追加します 。 #set_postを更新します 方法：

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
    .
    .
    .
    private
    def set_post
      @post = Post.find(params[:id])
    rescue ActiveRecord::RecordNotFound => e
      render json: { error: "Oops. That post isn't here" } , status: :not_found
    end
    .
    .
end

例外は手動で処理しているため、AppSignalに自動的に報告されることはありません。 Appsignal.set_errorを使用して、手動でエラーを追跡することもできます 。

エラーを追跡する最も簡単な方法は、Appsignal.set_error(e)のような関数の唯一の引数としてエラーを追加することです。 。また、リクエストにコンテキストを追加する機能を利用したいと考えています。 AppSignalでは、Appsignal.tag_requestを使用して、イベントに独自の任意の情報をタグ付けできます。 ：

def set_post
  Appsignal.tag_request(user_id: 'user-from-params', post_id: params[:id])
  @post = Post.find(params[:id])
rescue ActiveRecord::RecordNotFound => e
  Appsignal.set_error(e)
  render json: { error: "Oops. That post isn't here" }, status: :not_found
end

次に、http：// localhost：3000 / posts / doesnotexistにアクセスして、アプリケーションがクラッシュするのではなく、期待どおりにJSON応答が返されることを確認します。

洞察

存在しない投稿を表示しようとした後、追加された更新により、エラーがAppSignalに報告されます。AppSignalダッシュボードの「エラー->問題リスト」 、新しく報告されたエラーを見つけて表示します（ActiveRecord::RecordNotFound 。

エラーの詳細ページには、エラーに関する有用なコンテキストが表示されます。デフォルトでは、HTTPメソッド、パラメーター、セッションデータなどのリクエストに関する情報が含まれています。カスタムタグも含まれていることがわかります。これにより、一致するタグを使用してすべてのエラーをフィルタリングできます。

リクエストにタグを付けたため、この情報がエラーやその他のインストルメント化されたイベントに追加されます。 http：// localhost：3000 / posts / 1など、個々の投稿を数回表示すると、パフォーマンス測定値（「パフォーマンス」->「問題リスト」->）を見るときにタグも含まれていることがわかります。 'PostsController＃show'）。ガイドでトランザクションのタグ付けについて詳しく読むことができます。

トランザクションにカスタムメタデータを追加するこの機能は、本番環境での問題の診断に役立つ多くの機会を開きます。この良い例は、Kubernetesメタデータをエラーに追加することです。

メトリクス

いくつかのカスタムインストルメンテーションとエラー監視が実施されたので、投稿検索に大きなスパイクがあることに気付くかもしれません。ユーザーが検索するときはいつでも、Analytics#track_post_title_search が呼び出され、いくつかの計算が行われ、サードパーティのサービスへのAPI呼び出しが行われます。このサードパーティにはAPIのレート制限があります。アプリケーションが限界にどれだけ近づいているかを監視するために、呼び出される頻度を追跡したいと思います。

AppSignalを使用すると、必要に応じてアプリケーション全体でカスタムメトリックを追跡できます。

まず、カウンターとタグを使用して、分析サービスを呼び出す頻度とデータを追跡します。

#app/services/analytics.rb
require 'appsignal/integrations/object'
 
class Analytics
  def self.track_post_title_search(letter, sleep = sleep(1))
    Appsignal.increment_counter("track_post_search", 1, { letter: letter })
    # Some heavy processing
    sleep 1
  end
  appsignal_instrument_class_method :track_post_title_search
end

次に、PostsController#indexで返される投稿の数も追跡します。 、これはアプリケーションの動作の中核部分であり、成長し続けることがわかっているためです。

#app/controllers/posts_controller.rb
class PostsController < ApplicationController
    .
    .
  def index
    .
        .
    Appsignal.set_gauge("posts_index", @posts.size, starts_with: params[:starts_with])
  end
end

アプリケーションでまだ実行されている偽のトラフィックスクリプトはいくつかのデータを生成しますが、さらに多様性を追加するために、f、l、およびvで始まる投稿も検索してみましょう。

洞察

カスタムメトリックを表示するには、AppSignalにカスタムグラフを含むダッシュボードを作成する必要があります。これはUIを介して実行できますが、この例では1つだけインポートします。 [ダッシュボード]セクションで、[ダッシュボードの追加]をクリックし、次のダッシュボードをインポートします。

{
  "title": "Post Search",
  "description": "Sample dashboard about posts search activity",
  "visuals": [
    {
      "title": "Analytics",
      "line_label": "%name% %letter%",
      "display": "LINE",
      "format": "number",
      "draw_null_as_zero": true,
      "metrics": [
        {
          "name": "track_post_search",
          "fields": [
            {
              "field": "COUNTER"
            }
          ],
          "tags": [
            {
              "key": "letter",
              "value": "*"
            }
          ]
        }
      ],
      "type": "timeseries"
    },
    {
      "title": "Search",
      "line_label": "%name% %starts_with%",
      "display": "LINE",
      "format": "number",
      "draw_null_as_zero": true,
      "metrics": [
        {
          "name": "posts_index",
          "fields": [
            {
              "field": "GAUGE"
            }
          ],
          "tags": [
            {
              "key": "starts_with",
              "value": "*"
            }
          ]
        }
      ],
      "type": "timeseries"
    }
  ]
}

数分以内にグラフにデータが表示されるはずです。線にカーソルを合わせると、表示している時間枠内に収集されたメトリックの凡例が表示されます。

これは、タグ値ごとに異なる行を示していることに注意してください。現在、私たちの偽のトラフィックは文字eのみを検索しています 、ただし、他の文字を手動で検索したため、グラフ上に別のデータポイントを示す新しい線が表示されます。

AppSignalには、ここでは取り上げないカスタムインストルメンテーションソリューションがあります。簡単に言及する価値のあるものの1つは、breadcrumbsです。Breadcrumbsを使用すると、アプリケーション内のアクションのリストを追跡でき、エラーとして報告されます。エラーの原因について、さらに具体的で順序付けられた情報が得られます。

ガイドでカスタム計装についてすべて読んでください。

まとめ：AppSignalを使用したRubyアプリのカスタムインストルメンテーションとモニタリング

このシリーズのパート1では、RubyアプリケーションでのAppSignalの基本的なセットアップと使用について説明しました。

このパートでは、すぐに使用できる優れた監視機能を備えたアプリケーションを取り上げ、AppSignalgemを使用してさらに優れたものにしました。

AppSignalのカスタムインストルメンテーション、エラートラッキング、およびパフォーマンスモニタリング機能により、アプリケーションの動作について必要な洞察が得られます。これにより、アプリケーションをすぐに使用できるようになり、必要に応じて制御できるようになります。

コードの動作を監視している限り、コードを実際に自由に実行できるようにするときが来ました。ハッピーコーディング！

P.S。 Ruby Magicの投稿をマスコミから離れたらすぐに読みたい場合は、Ruby Magicニュースレターを購読して、投稿を1つも見逃さないでください。