AppSignalでカスタムメトリクスを追跡し、すぐに役立つ実用的なインサイトを得る方法

カスタムメトリクスを設定すれば、ログを一行ずつ調べたり複雑なレポーティングツールに苦戦したりすることなく、必要な情報へのインサイトを即座に得られます。意味のあるメトリクスを追跡してアプリケーションの重要な監視データを補完することで、潜在的な問題を素早く特定し、解決につなげることができます。

本記事では、監視の死角をなくすためにカスタムメトリクスを設定・活用する方法を紹介します。AppSignalの監視ツール群と組み合わせてカスタムメトリクスを利用し、アプリケーションのパフォーマンスをより深く理解する方法をデモします。

カスタムメトリクスとは何か?

メトリクスといえば、AppSignalはデフォルトでエラー率、レスポンスタイム、スループットといった重要なデータを自動的に追跡します。これらのメトリクスをもとにアプリケーションを監視し、パフォーマンスの問題が発生した際には通知をお届けします。

一方、カスタムメトリクスを使えば、追跡したいあらゆるアプリケーションデータを自由に可視化・記録できます。アクティブユーザー数やジョブごとの処理時間といった追加のコンテキストと紐付けることで、アプリケーションのパフォーマンスをより深く把握できるのです。AppSignalではダッシュボードを作成し、スループットやデータベースサイズなどの重要なメトリクスと並べてカスタムメトリクスを追跡できます。

メトリクスの測り方

メトリクスをAppSignalに送信するときは、どのような形で測定したいかを検討することが大切です。AppSignalでは次の3つの測定方式を提供しています。

AppSignalは、適切な測定形式でカスタムメトリクスを手軽に追跡できるよう、便利なメソッドや関数を用意しています。

ここでは、あるネットショップを監視している場面を想定してみましょう。ゲージ(gauge)、カウンター(counter)、ディストリビューション(distribution)という3つの測定方式を使って、具体的なデータポイントを追跡する方法を順番に見ていきます。

ゲージ(Gauge)

まず、アプリケーションのパフォーマンスが普段より良い・悪い理由を把握するための文脈として、現時点で何人のアクティブな買い物客がサイトを利用しているかを確認します。新しいユーザーセッションが作成されるたびにアクティブユーザー数を報告するのに、ゲージ測定を使用します。

そのために活躍するのが「minutely probe(ミニットリープローブ)」です。これはカスタムメトリクスを定期的にAppSignalへ送信する仕組みです。このプローブを使って直近1分間に更新されたショッピングカートの数を記録し、set_gaugeメソッドでactive_shoppersというラベル付きでAppSignalに送信できます。以下はその例です。

Ruby

minutely probeの詳細については、Rubyのドキュメントをご覧ください。

Elixir

minutely probeの詳細については、Elixirのドキュメントをご覧ください。

Node.js

minutely probeの詳細については、Node.jsのドキュメントをご覧ください。

設定が完了したら、AppSignal上でチャートを作成し、アクティブな買い物客が何人サイトを利用しているかを追跡できます。

この情報があれば、サイトを実際に利用しているおおよその人数から、ネットショップの状況を素早く推測できます。アクティブユーザー数が特に多いと感じたらパフォーマンス低下を予測できるため、アプリケーションを安定稼働させるための対策を事前に講じられます。

カウンター(Counter)

カウンターを使うと、アプリケーション内である出来事がどれくらいの頻度で発生しているかを追跡できます。一定期間における特定のイベントやアクションの発生回数を監視したいシーンで役立ちます。たとえば、「ユーザーが商品をカートに追加した回数」などが挙げられます。

ここでは、アプリケーションがユーザーに請求書を発行する頻度を把握したいとしましょう。そのためには、請求書が作成されるたびにカウンターを増加させます。

RubyとElixirではincrement_counterメソッドを使用します。

Node.jsではincrementCounter関数を使用します。

セットアップが完了すれば、AppSignal上でアプリケーションが生成した請求書の枚数を追跡できるようになります。

さらに、注文数など関連する他のデータポイントも併せて追跡してみましょう。もしメトリクス同士が想定どおりに連動していないことに気づいたら、請求処理と注文処理のロジックを調査できます。重大な問題が多くの顧客に影響を及ぼす前に、発見して修正できるかもしれません。

ディストリビューション(Distribution)

カスタムメトリクスは、レスポンスタイムやバックグラウンドジョブの実行時間といったデータ測定値の記録にも活用できます。こうしたメトリクスを追跡しておけば、パフォーマンスの低いバックグラウンドジョブやAPIエンドポイントを特定でき、ユーザー体験への悪影響を未然に防ぐことにつながります。

ここでは、注文確認メールを送信するジョブにかかる平均時間を確認したいと思います。顧客が購入後数分以内にこのメールを受け取れることは非常に重要だからです。

そのために、add_distribution_valueメソッドを使用します。

Ruby

Elixir

Node.js

これで、AppSignal上で注文確認ジョブの完了までにかかる平均時間を追跡できるようになります。ユーザーが気づく前に遅延を検知できるため、アプリケーションの可用性と拡張性を保つための先手の対応が可能になります。

カスタムメトリクスのためのカスタムダッシュボード

直感的なUIのおかげで、カスタムメトリクスの追跡は数分で始められます。

ダッシュボードナビゲーションの「Add dashboard」ボタンから新しいダッシュボードを作成できます。「Add graph」ボタンをクリックすると、Graph Builderを使ってグラフの構築を始められます。

グラフ作成時には、表示したいメトリクスやタグを選択し、凡例やラベルを設定できます。設定が完了すると、指定した期間の最新のメトリクスデータがすぐにグラフに表示されます。

なぜメトリクスが重要なのか

ロギングは、発生後のアプリケーションパフォーマンス問題のデバッグやトラブルシューティングに非常に有効な手段です。しかし、メトリクスがあれば、顧客が何かに気づく前に将来の問題を防ぐことができます。カスタムメトリクスを活用すれば、次のようなメリットがあります。

• 本当に重要なことに集中できる: アプリケーション内の特定のデータポイントを正確に追跡し、大量のログメタデータやインシデント一覧をふるいにかけることなく、焦点を絞ったインサイトを得られます。
• ビジネス視点でパフォーマンスを把握できる: アプリケーションのパフォーマンスをビジネスの観点から理解し、アクティブユーザー数、KPI、日次売上といった重要データを素早く追跡できます。
• ロギングを効率化できる: 「何でもかんでも全部ログに出す」運用は持続不可能です。カスタムメトリクスで本質的なデータを効率的に追跡し、ログはインシデント原因の調査に絞れば、トラブルシューティングとデバッグに必要なデータだけを記録できます。
• 受動的ではなく能動的に動ける: たとえば「請求書の送信に時間がかかりすぎている」「アクティブユーザー数が通常より多い」といった状況を検知するカスタムトリガーを設定できます。こうした警告により、顧客に影響が出る前に問題を調査・解決できます。

カスタムメトリクスをさらに深く掘り下げる

アプリケーションのメトリクスを最大限に活用する準備はできましたか?本記事で紹介したのは、AppSignalのカスタムメトリクスで実現できることのほんの一部です。詳細については、カスタムメトリクスに関するドキュメントで必要な情報をすべて確認できます。

メトリクスやAppSignal・監視全般について質問がある場合やサポートが必要な場合は、いつでもお気軽にお問い合わせください。

AppSignalのカスタムメトリクスは、アプリケーション監視を支援する数多くの開発者向け機能のひとつにすぎません。開発者の皆さんに私たちの監視ツールを愛用いただいている理由は、ほかにもあります。

• 直感的で操作しやすいインターフェース
• シンプルで予測可能な料金体系
• 開発者による開発者のためのサポート

初めてAppSignalを使う方は、ぜひ無料のストルップワッフルをリクエストしてくださいね!アプリケーションのすべてのメトリクスを手元に置ける感覚に負けないくらい美味しいですよ😉🍪

Connor James

AppSignalのDeveloper Marketing Manager。ポッドキャスト中毒で、カンノーリ(cannoli)への愛が深すぎて名前を「Connoli」に変えようか考えているほど。「color」には「u」が入るべきだと主張するイギリス英語派です。マイクの前、ステージの上、そして仕事オフのソファの上で見かけられるかもしれません。

Connor Jamesのすべての記事を読む