Rubyを監視する最も簡単な方法：自動インストルメンテーション

アプリケーションのパフォーマンスに関する適切な監視の概要を設定することは、複雑な作業です。通常、最初に何を監視する必要があるかを理解し、次にコードをインストルメント化し、最後に送信されたすべてのデータを理解する必要があります。

ただし、いくつかの設定が行われ、RubyをネイティブにサポートするAPMを使用すると、この手順をこれまで以上に簡単に実行できます。この投稿では、その方法も紹介します。

自動計測-ハンズフリーAPMセットアップ

コードのどの部分がパフォーマンスの問題を引き起こしているのかを見つけるには、それにインストルメンテーションを追加する必要があります。そうすれば、すべてのアクションを分類して、どれが最も遅いかを測定できます。

AppSignalの自動インストルメンテーションを使用すると、可能な限り多くの手作業を省くことができます。 CLIからいくつかのコマンドを実行するだけで、設定が完了します。

当社の監視エージェントは、インフラストラクチャのさまざまな部分を検出し、自動的に計測します。これにより、AppSignalアプリは、最も必要なグラフとダッシュボードをダイジェスト、処理、監視、および表示できるようになります。

つまり、たとえばRubyのgraphql gemの場合、AppSignalは着信するすべてのGraphQLリクエストを計測します。つまり、リクエスト内のすべてのイベントの内訳を提供します。

すぐに使用できるインストルメンテーション

AppSignalがサポートするすべてのツールのリストを作成しました。かなり広範囲です：

私が言ったように、リストはかなり長いので、この投稿のすべてのツールに飛び込むことはしません。

WebフレームワークとAPI

AppSignalは、Ruby on Rails、Padrino、およびSinatraでのWebリクエストのインストルメンテーションをすぐにサポートします。 GrapeまたはGraphQLgemを使用するAPIもサポートされています。

Ruby on Rails

RailsのAppSignal統合は、リクエストの例外とパフォーマンスを追跡することで機能します。リクエスト中にコントローラーでエラーが発生すると、AppSignalはそれを報告します。パフォーマンスの問題は、リクエストの期間に基づいており、アプリケーションのどの部分に最も時間がかかったかを詳細に示すイベントのタイムラインを作成します。

Webサーバーのロードバランサーを介してHTTPリクエストがRailsアプリに到着するまでにかかった時間を追跡することも可能です。デフォルトでオンになっていない場合は、リクエストキューのタイムトラッキングヘッダーを設定すると、AppSignalがキューの時間を自動的にグラフ化します。

GraphQL

AppSignalは、Ruby用のgraphqlgemをサポートしています。入ってくるすべてのGraphQLリクエストをインストルメントし、リクエスト内のすべてのイベントの内訳を提供します。リゾルバーの解析、検証、実行にかかった時間を確認できます。もちろん、アプリのWebフレームワークとデータベース呼び出しからのイベントはこの内訳に含まれます。

これは、時間がかかるように思われるGraphQLクエリをデバッグしたい場合に最適であり、どこで速度低下が発生しているのかわからない場合があります。ここでも異常トリガーを忘れないでください。これらは、クエリ時間が特定のしきい値に達したときにアラートを出すのに非常に役立ちます。

シナトラ、パドリーノ、グレープ

Sinatra、Padrino、Grapeは、さまざまな方法でアプリの一部となることができるRuby用のWebおよびAPIフレームワークです。これらはスタンドアロンアプリであるか、より大きなRailsアプリにマウントされています。アプリがウェブサーバーにどのようにマウントされているかに応じて、Sinatra、Padrino、Grapeにはいくつかの異なるインストール手順が必要です。

Sinatra、Padrino、Grapeリクエストがインストールされると、すべてインストルメント化されます。トラフィックがAPIに到達すると、エラーとパフォーマンス測定値が報告されます。すべての（API）エンドポイントは、どのエンドポイントでどのエラーが発生したかを簡単に見つけるためのAppSignalでの独自のアクションです。 Railsアプリと同様に、パフォーマンスの内訳は、どのデータベースクエリや他の部分、またはアプリが他の部分よりも遅いかについての洞察を提供します。

データベース

アクティブレコードおよびその他のORM

リクエストがデータベースのクエリにかかった時間を確認するには、インシデントの詳細ページを開きます。ページの上部に、リクエストに記録されたイベントの種類がグループごとに分類されています。ここでは、どのタイプの操作に合計でどれだけの時間が費やされたかを確認できます。

このサンプルのパフォーマンスをさらに拡大すると、ページのさらに下に、リクエスト内のすべてのイベントのタイムラインが発生順に表示されます。これにより、実行された各クエリの概要と、最も時間がかかっているクエリの概要がわかります。

統合により、データベース呼び出しのトレースが表示されるため、どのクエリが悪（または天才）の根源であるかを確認できます😉

N+1クエリ

リクエストでN+1クエリが発生している可能性があり、それが原因で速度が低下しているのではないかと心配しています。 N + 1クエリを検出すると、検出されたイベントのイベントタイムラインに警告が表示されます。

Redis

Redisとの統合により、Redisへの呼び出しがイベントタイムラインに表示されます：

また、Redisに送信されたコマンドの名前と、クエリが実行されたRedisインスタンスのアドレスを確認することもできます。

これは、Redisキャッシュへの長時間実行される呼び出しをデバッグしたい人にとっては朗報です。異常トリガーを設定して、非常に長時間実行されるリクエストにアラートを送信することもできます！

バックグラウンドジョブ

バックグラウンドジョブがSidekiqでキューに入れられると、Delayed ::Job、Resque、Shoryuken、およびQueAppSignalはエラーとパフォーマンス測定値を自動的に報告します。すべてのアクティブジョブアダプタもサポートされており、SidekiqやDelayed ::Jobなどの一部のバックグラウンドジョブライブラリは、ライブラリ自体からさらに多くのメタデータを報告します。

アクションメーラーを使用したメールの送信

アクションメーラーを使用するRailsメーラーがdeliver_laterに設定されている場合 また、アクティブジョブを介してルーティングされ、同じレベルのインストルメンテーションを信頼できます。

WebSocket

Railsアプリでアクションケーブルを使用していますか？ AppSignalは、メッセージとサブスクリプションのエラーとパフォーマンス測定値を自動的に報告します。すべてのメッセージは個別に計測されるため、長時間実行されているチャネルでもすべてのアクティビティが報告されます。これらはアクションごとにグループ化されており、個々のアクションがどのように実行されているかを明確に示しています。

👋これが気に入った場合は、Rubyパフォーマンス監視チェックリストにある他のRuby（on Rails）パフォーマンス記事をご覧ください。

AppSignalをお試しください：監視が簡単で便利になりました🍪

過去7年間、私たちは何千人もの開発者がコードを自動的にインストルメント化するのを支援してきました。ぜひ試してみてください。その際は、お気軽にお問い合わせください。ストロープワッフルの無料ボックスもお送りします。

PS。優れたOSSプロジェクトで世界を支援している場合は、無料のAppSignalアカウントで支援します。大切なメンテナにその言葉を広めましょう！