ITチームがアプリの監視に使用するAPMメトリクス上位8

優れた顧客体験（CX）は、正確でタイムリーなアプリケーション・パフォーマンス監視メトリクスに基づいて構築されます。問題が何であるか、または機会がどこにあるのかを特定するまで、アプリやシステムをファイン・チューニングしてCXを改善することはできません。

APM（アプリケーション・パフォーマンス管理）ソリューションは通常、分析および比較するリアルタイムのパフォーマンス・メトリクスと洞察を集約するための集中型ダッシュボードを提供します。また、実際または潜在的な性能の問題を示す逸脱についてシステム管理者に警告するためのベースラインを確立します。ITチーム、DevOpsとサイト信頼性エンジニアは、アプリケーションの問題を迅速に特定して対処できるようになります。

アプリケーション・パフォーマンス監視は、アプリケーション・パフォーマンス管理（APM）の初期段階です。監視はアプリのパフォーマンスを追跡し、そのアプリの管理を可能にします。APM（アプリケーション・パフォーマンス管理）ソリューションは、管理者に迅速なデータ収集と根本原因分析の実施に必要な計測ツールを提供します。その後、その問題を切り分け、トラブルシューティングを行い、解決します。

選択できるメトリクスは多数ありますが、IT組織内で最大のメリットを享受するには、これら8つのメトリクスに焦点を当てることをお勧めします。

1. ApdexとSLAのスコア

アプリケーションの性能指数（Apdex）とサービス・レベル契約（SLA）スコアから始めましょう。これらは優れた顧客体験の基盤となるからです。測定するスピードやフィードは、高速な性能に付加されるべき特定の側面ですが、それらは手段であり、目的ではありません。顧客満足度の向上こそが目標であり、それが売上増加につながることが理想です。

ApdexとSLAのスコアは、エンドユーザー・エクスペリエンス・モニタリングを行うための最も一般的な方法です。Apdexスコアは、Webリクエストまたはトランザクションに通常かかる時間の目標を指定することにより、アプリの相対的な性能を追跡します。SLAは顧客契約のメトリクスであり、定義されたSLAよりも低いと、顧客体験（事前定義されたペナルティー）が低下するリスクがあります。

2. アプリケーションの可用性（アップタイムまたはパフォーマンス監視とも呼ばれる）

これは最も基本的な指標です：アプリは、稼働しているでしょうか。アプリケーションがオンラインで利用可能かどうかを監視および測定します。ほとんどの企業は、サービス・レベル・アグリーメント（SLA）のコンプライアンスを測定するためにこれを使用しています。アップタイムは多くの場合、システム全体の信頼性と正常性を評価するための略語です。オンライン・サービスを提供している組織にとって、過度のダウンタイムはユーザーの満足度に悪影響を与える可能性があります。Webアプリケーションの場合、定期的にスケジュールされたシンプルなHTTPチェックにより、可用性を確認できます。

3. CPU使用率（またはリソース使用率）

アプリケーションが使用するCPU容量の割合が高い場合は、パフォーマンスの問題の兆候である可能性があります。CPU使用率が突然急増すると、応答時間が遅くなる可能性があります。アプリの需要の変動も、より多くのアプリケーション・インスタンスを追加する必要があることを示している可能性があります。一般規則は、CPU使用率が時間の30%以上で70%を超える場合、CPU容量が不足している可能性があるということです。

リソースの使用量には、メモリとディスクの使用量も含まれます。RAMを追跡することで、障害につながる可能性やメモリーの必要性を特定することができます。ディスク使用量のメトリクスは、アプリが永続ストレージ不足に陥る（アプリに障害が発生する可能性がある）ことを防ぐ上で役立ちます。ディスク使用量が多いことは、バックエンド・データ・ストレージが非効率的であるか、データ保持ポリシーに欠陥があることを示している可能性もあります。

4. エラー・レート

APM（アプリケーション・パフォーマンス管理）メトリクス・ソフトウェアはアプリケーションを監視して、障害が発生したリクエストの割合を記録する必要があります。これは、ユーザー・エクスペリエンスに影響を与える問題の解決を特定し、優先順位を付けるのに役立ちます。アプリケーション・エラーには、サーバー・エラー、Webアプリの404応答、タイムアウトなどがあります。エラー率が設定されたパラメーターを超えたときに通知を送信するようにAPMソリューションを構成できます。たとえば、過去25件のリクエストのうち2.5％でエラーが発生した場合にアラートを送信します。

5. ガーベッジ・コレクション

ガーベッジ・コレクション（GC）は、Javaやその他の言語の継続的な大量のメモリ使用量を特定して排除することで、パフォーマンスを向上させることができます。幸いなことに、GCオートメーションは、アプリケーションで使用されなくなった未使用または冗長なオブジェクトやデータに割り当てられたメモリを再利用します。使用されていないオブジェクトまたはデータが削除され、ライブ・オブジェクトが後世代のメモリー・プールにコピーされます。理想的には、このメトリクスを適度な中間に維持します。GCの実行頻度が高すぎると、オーバーヘッドが大きくなる可能性があります。しかし、GCの実行頻度が十分でない場合、システムのメモリーが不足してしまう可能性があります。

6. インスタンス数

インスタンスを追跡することで、常時実行されているアプリやサーバーのインスタンスの数に基づいて、実際のユーザーの需要に合わせてアプリケーションを拡張することができます。これは、クラウド・アプリケーションにとって特に重要となる可能性があります。Auto-scalingは、最新のアプリケーションを需要に合わせて確実にスケーリングし、オフピーク時に予算を節約するのに役立ちます。これにより、インフラ監視の課題が生じる可能性もあります。たとえば、アプリがCPU使用率に応じて自動的にスケールアップする場合、CPU使用率が上昇しない代わりに、サーバー・インスタンスの数がホスティング料金とともに大幅に増加する可能性があります。

7. リクエスト率

アプリケーションが受信したトラフィックを測定して、大幅な減少または増加または同時ユーザーを特定できます。リクエスト率を他のアプリケーションのパフォーマンスメトリクスと関連付けることは、ソフトウェア・アプリケーションの拡張性を理解するのに役立ちます。APM（アプリケーション・パフォーマンス管理）ソフトウェアはトラフィックを監視して異常を特定することもできます。リクエストの予期せぬ増加を示すユーザー監視は、サービス拒否（DoS）攻撃である可能性があります。同じユーザーからの多数のリクエストは、ハッキングされたアカウントの兆候である可能性があります。異常に低いリクエストも問題かもしれません。非アクティブまたはトラフィックがまったくない場合は、システムのあらゆる部分に、障害が発生している可能性があります。

8. 応答時間（または処理時間）

リクエストに対する平均応答時間、つまりアプリケーションがリソースへのリクエストを返すまでにかかる時間を追跡することで、アプリのパフォーマンスを評価できます。これらのリクエストには、Webページの読み込みリクエストなど、エンドユーザーによって開始されたトランザクションが含まれる場合があり、また、ディスクやメモリからデータを要求するプロセスやマイクロサービスなど、アプリケーションの一部から別の部分への内部リクエストが含まれる場合もあります。合計応答時間には、サーバー応答時間（サーバーがリクエストの処理に要する時間）とネットワーク・レイテンシー（リクエストがネットワーク上を移動するために要する合計時間）が含まれます。

関連するメトリクスはページ読み込み時間です。これは、Webページがブラウザーに読み込まれるまでの時間を測定します。ページの読み込み時間を追跡することで、アプリケーションのパフォーマンス監視ツールでページの読み込みが遅くなる問題を特定し、デジタル・エクスペリエンスを向上させることができます。ページの読み込みが遅いと、ページの放棄やビジネスの損失を意味する可能性があります。APM（アプリケーション・パフォーマンス管理）ソリューションでは、このメトリクスに対するパフォーマンスのベースラインを設定し、そのベンチマークが満たされていない場合に警告を発することができます。

アプリケーションのパフォーマンス監視に関する、より包括的な一連のメトリクスを探している方は、次のメトリクスを検討するといいでしょう。

• データベース・クエリー：アプリケーションによってデータベースから要求されるクエリーの数を測定します。APMツールは、アプリケーションの全体的な性能を遅らせている可能性のある、遅いまたは非効率なクエリーを特定するのに役立ちます。
• I/O（インプット/アウトプット）：I/Oは、アプリがデータを読み取りまたは書き込みする速度を示します。永続ストレージ・メディア（HDDやSSDなど）の性能や、メモリまたは仮想ディスクのI/Oレートを追跡できます。
• ネットワーク使用量： ネットワーク使用量は、アプリケーションが使用するネットワーク帯域幅の合計を表します。ネットワーク使用量の増加は、性能の問題によってアプリケーションの応答時間が遅くなったり、ボトルネックが生じたりしていることを示している可能性があります。
• ノードの可用性： インスタンス数と同様の測定値がノードの可用性ですが、これはクラウドに固有のものです。アプリをKubernetesクラスターにデプロイする場合、使用可能で応答しているノードの数（クラスター内のノードの合計数）は、インフラストラクチャー内の問題を特定するのに役立ちます。クラウド支出メトリクスも重要であり、 API呼び出し、クラウドベースの仮想マシン（VM）の実行時間、合計データ送信率を追跡することで、クラウド・コストをリアルタイムで把握できます。
• スループット：スループットは、アプリとユーザーまたは他のシステムの間で転送できるデータの量です。これは、予想されるトラフィック量をアプリが処理できるかどうかを判断するために使用できます。
• トランザクション・トレース：アプリケーションによって実行される単一のトランザクションの全体像が得られます。キャプチャされるデータは、データベース呼び出し、外部呼び出し、関数呼び出しが含まれ、トランザクション要求の開始から終了まで監視されます。
• トランザクション・ボリューム：トランザクション・ボリュームは、アプリケーションによって処理されるトランザクションの数を測定します。これにより、APM（アプリケーション・パフォーマンス管理）ツールは拡張性とキャパシティー計画に関する問題を特定できるようになります。

IBM® Instana Observabilityは、誰でも使用できるリアルタイムのオブザーバビリティーを提供します。プログラム識別情報戦略が今日および将来の環境の動的な複雑さに確実に対応できるようにしながら、価値を迅速に実現します。モバイルからメインフレームまで、Instanaは250以上のテクノロジーをサポートしており、その数は増え続けています。