すべてのプロダクト
Search
ドキュメントセンター

Application Real-Time Monitoring Service:アラートメトリック

最終更新日:Dec 30, 2024

このトピックでは、Application Real-Time Monitoring Service (ARMS) のアプリケーション監視サブサービスが提供するアラートメトリックについて説明します。すべてのメトリックデータは1分ごとに監視されます。

JVM

説明

以下の JVM メトリックは参考値です。JVM 関連の説明は、公式の JVM ドキュメントを参照してください。

メトリック

メトリック名

単位

よく使用される

説明

JVM フル GC の回数 (瞬間値)

なし

はい

過去 N 分間に JVM によって実行されたフルガベージコレクション (GC) の回数。フル GC がアプリケーションで頻繁に発生する場合、エラーが発生する可能性があります。

JVM フル GC の期間 (瞬間値)

ミリ秒

いいえ

過去 N 分間にフル GC に費やされた時間。フル GC 期間の瞬間値は、現在の JVM のガベージコレクションパフォーマンスを示します。一般的に、フル GC の期間が短いほど、JVM のパフォーマンスは向上します。フル GC に時間がかかりすぎると、アプリケーションが大幅に停止する可能性があります。これはユーザーエクスペリエンスに影響します。

JVM ヤング GC の回数 (瞬間値)

なし

はい

過去 N 分間に JVM によって実行されたヤング GC の回数。ヤング GC 回数の瞬間値は、JVM オブジェクトの作成と破棄の速度、およびヤング世代の使用状況を示します。一般的に、ヤング GC が多いほど、アプリケーションで作成されるオブジェクトが多くなります。さらに、アプリケーションにメモリリークまたは不適切なメモリ使用量がある可能性があります。

JVM ヤング GC の期間 (瞬間値)

ミリ秒

いいえ

過去 N 分間にヤング GC に費やされた時間。ヤング GC 期間の瞬間値は、現在の JVM のガベージコレクションパフォーマンスを示します。一般的に、ヤング GC の期間が長いほど、ガベージコレクションの効率は低下します。この場合、アプリケーションが停止する可能性があります。

JVM ヒープメモリの合計

MB

いいえ

ヤング世代とオールド世代のメモリを含む、JVM ヒープメモリの合計サイズ。JVM ヒープメモリのサイズは、アプリケーションの負荷とパフォーマンス要件に基づいて適切に構成する必要があります。JVM ヒープメモリが小さすぎると、ガベージコレクションが頻繁に発生し、アプリケーションのパフォーマンスに影響します。JVM ヒープメモリが大きすぎると、大量のシステムリソースが占有され、システムの安定性に影響します。

使用済み JVM ヒープメモリ

MB

はい

Java プログラムによって使用される JVM ヒープメモリのサイズ。使用済み JVM ヒープメモリのサイズは厳密に制御して、システムパフォーマンスの低下、またはメモリリークや過剰なメモリ使用量によるメモリオーバーフローを防ぐ必要があります。

コミット済み JVM 非ヒープメモリ

MB

いいえ

Java プログラムによって使用される非ヒープメモリのサイズ。コミット済み JVM 非ヒープメモリのサイズは厳密に制御して、過剰なクラスの読み込みまたは大量の静的変数と定数による過剰なメモリ使用を防ぐ必要があります。

初期 JVM 非ヒープメモリ

MB

いいえ

一般に、JVM 非ヒープメモリの初期サイズは、JVM バージョン、オペレーティングシステム、JVM パラメーターなどの要因に基づいて動的に計算されます。

最大 JVM 非ヒープメモリ

MB

いいえ

8 より前の Java バージョンを使用している場合、このメトリックは JVM パラメーター MaxPermSize によって制御されます。それ以外の場合、このメトリックは MaxMetaspaceSize によって制御されます。

使用済み JVM 非ヒープメモリ

MB

はい

Metaspace と PermGen を含む、使用済み JVM 非ヒープメモリのサイズ。

使用済み JVM メタスペース

MB

いいえ

クラス構造、メソッド、フィールドなど、クラスメタデータを格納するスペース。一般に、このメモリ使用量は安定しています。

JVM ブロックスレッド数

なし

いいえ

モニターロックを待機しているブロックスレッドの数。ブロックスレッドが多すぎると、システムパフォーマンスが低下する可能性があります。

JVM スレッドの総数

なし

はい

すべての状態のスレッドの数。スレッド数が多すぎると、メモリと CPU リソースが不足する可能性があります。これは、アプリケーションのパフォーマンスと安定性に影響します。

JVM デッドロックスレッド数

なし

いいえ

デッドロックの数。デッドロックは、2 つ以上のスレッドがリソースへのアクセスを完了するために互いに待機しているときに発生します。JVM でデッドロックが発生すると、デッドロックスレッドの数は、ますます多くのデッドロックが発生するまで増加します。一般に、デッドロックスレッドが多いほど、状況は深刻になります。アプリケーションがクラッシュすることさえあります。

新規 JVM スレッド数

なし

いいえ

JVM によって作成されたスレッドの数。JVM では多数のスレッドを作成できますが、スレッドが多すぎるとシステムリソースの浪費やスレッドスケジューリングへのプレッシャーにつながる可能性があります。

JVM 実行可能スレッド数

なし

いいえ

実行時に JVM でサポートされる最大スレッド数。スレッドを作成しすぎると、大量のメモリリソースが消費されます。システムの動作が遅くなったり、クラッシュしたりする可能性があります。

JVM 終了スレッド数

なし

いいえ

実行時に JVM で同時に実行できるスレッドの数。スレッドリソースの浪費やスレッドの枯渇を防ぐために、実際の状況に基づいてスレッド数を制御できます。

JVM タイムアウト待機スレッド数

なし

はい

JVM ランタイムでリソースを待機してタイムアウトしたスレッドの数。タイムアウトしたスレッドの数が多すぎる場合は、システムにボトルネックが存在する可能性があります。この場合、リソースを最適化して、システムの処理能力と応答速度を向上させる必要があります。

JVM 待機スレッド数

なし

いいえ

現在の JVM で待機しているスレッドの数。高並列アプリケーションの場合、JVM 待機スレッド数の増加はパフォーマンスの低下につながる可能性があります。

JVM GC の回数 (累積値)

なし

いいえ

JVM で実行された GC の累積回数。

JVM マークアンドスイープガベージコレクションサイクル (累積値)

なし

いいえ

JVM でのマークアンドスイープガベージコレクションサイクルの累積回数。

JVM ヒープメモリ使用率 (%)

なし

いいえ

JVM ランタイムでの割り当て済みヒープメモリと合計ヒープメモリの比率。このメトリックを使用して、JVM メモリ管理の効率とパフォーマンスを測定できます。一般に、メモリオーバーフローなどの問題を防ぐために、JVM ヒープメモリ使用率を 70% 未満に維持する必要があります。

ディメンションとフィルター条件

上記のメトリックは、ノードの IP アドレスによって監視されます。IP アドレスをフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: 各ノードの IP アドレスをトラバースし、各ノードのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のノードを指定します。例: =172.20.XX.XX

  • ディメンションなし: すべてのノードのメトリックデータを集計し、アラートを構成します。

スケジュールタスク

説明 ARMS アプリケーション監視機能は、XXL-JOB、SchedulerX、および JDK-Timer タイプのスケジュールタスクのみをサポートしています。

メトリック

メトリック名

単位

よく使用される

説明

期間

ミリ秒

いいえ

スケジュールタスクの平均期間。

実行の総数

なし

いいえ

スケジュールタスクが実行された回数。

実行エラーの数

なし

いいえ

指定された時間間隔内にスケジュールタスクが予期どおりに実行されなかった回数。

スケジューリングレイテンシ

ミリ秒

いいえ

スケジュールタスクが開始される前にスケジューリングに費やされた時間。

ディメンションとフィルター条件

上記のメトリックは、スケジュールタスクによって監視されます。スケジュールタスクをフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: スケジュールタスクをトラバースし、各スケジュールタスクのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のスケジュールタスクを指定します。例: =LoadGenerator.mockUserApiLoad

  • ディメンションなし: すべてのスケジュールタスクのメトリックデータを集計し、アラートを構成します。

例外

メトリック

メトリック名

単位

よく使用される

説明

例外の数

なし

はい

ヌルポインター例外、配列の範囲外例外、I/O 例外など、ソフトウェアランタイムで発生した例外の数。このメトリックを使用して、呼び出しスタックがエラーをスローするかどうか、およびアプリケーション呼び出しエラーが発生するかどうかを確認できます。

異常なインターフェース呼び出しの応答時間

ミリ秒

はい

アプリケーションの異常なインターフェース呼び出しの応答時間。インターフェース呼び出しが異常な場合、エラーが発生します。このメトリックを使用して、呼び出しスタックによってスローされたエラーがインターフェース呼び出しの応答時間に与える影響を推定し、エラーが発生するかどうかを確認できます。

ディメンションとフィルター条件

上記のメトリックは、インターフェース名によって監視されます。インターフェース名をフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: アクセスされたインターフェースをトラバースし、各インターフェースのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のインターフェースを指定します。例: =/tb/api/users/{userId}

  • 等しくない (!=): アラートから特定のインターフェースを除外し、他のインターフェースのアラートを個別に構成します。例: !=/tb/api/users/{userId}

  • 含む: 特定のキーワードを含むインターフェースのアラートを構成します。例: 含む api

  • 含まない: 特定のキーワードを含まないインターフェースのアラートを構成します。例: 含まない api

  • 正規表現: 指定された正規表現に一致するインターフェースのアラートを構成します。例: =/(api)/i

  • ディメンションなし: すべてのインターフェースのメトリックデータを集計し、アラートを構成します。

上記のメトリックは、例外によって監視されます。例外をフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: 例外をトラバースし、各例外のメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定の例外を指定します。例: =FeignException$InternalServerError

  • 等しくない (!=): アラートから特定の例外を除外し、他の例外のアラートを個別に構成します。例: !=FeignException$InternalServerError

  • 含む: 特定のキーワードを含む例外のアラートを構成します。例: 含む data

  • 含まない: 特定のキーワードを含まない例外のアラートを構成します。例: 含まない data

  • 正規表現: 指定された正規表現に一致する例外のアラートを構成します。例: =/(data)/i

  • ディメンションなし: すべての例外のメトリックデータを集計し、アラートを構成します。

アプリケーション依存サービス

メトリック

メトリック名

単位

よく使用される

説明

アプリケーション依存サービス呼び出しの数

なし

いいえ

アプリケーションが依存するダウンストリームインターフェースの数。このメトリックを使用して、アプリケーション依存サービス呼び出しの数が増加するかどうかを確認できます。

アプリケーション依存サービス呼び出しエラー率 (%)

なし

いいえ

このメトリックの値は、次の式を使用して計算されます。アプリケーション依存サービス呼び出しのエラー率 = 異常なダウンストリームインターフェースリクエストの数 / インターフェースリクエストの総数。このメトリックを使用して、アプリケーション依存サービスのエラーが増加し、アプリケーションに影響を与えるかどうかを確認できます。

アプリケーション依存サービス呼び出しの応答時間

ミリ秒

はい

アプリケーションが依存するダウンストリームインターフェースの平均応答時間。このメトリックを使用して、アプリケーション依存サービスで消費される時間が増加し、現在のアプリケーションに影響を与えるかどうかを確認できます。

アプリケーション依存サービスのスローコールの数

なし

いいえ

アプリケーションが依存するダウンストリームインターフェースのリクエスト時間がしきい値を超えると、スローコールとしてカウントされます。このメトリックを使用して、ダウンストリーム依存サービスがアプリケーションに影響を与えるかどうかを確認できます。

ディメンションとフィルター条件

上記のメトリックは、インターフェース呼び出しタイプによって監視されます。インターフェース呼び出しタイプをフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: インターフェース呼び出しタイプをトラバースし、HTTP、MySQL、Redis など、各タイプのメトリックデータのアラートを個別に構成します。

  • 等しい (=): アラートの特定のインターフェース呼び出しタイプを指定します。例: =http

  • ディメンションなし: すべてのインターフェースのメトリックデータを集計し、アラートを構成します。

ECS インスタンス

メトリック

メトリック名

単位

よく使用される

説明

ノード CPU 使用率 (%)

なし

いいえ

ノードの CPU 使用率。各ノードはサーバーです。CPU 使用率が高すぎると、システムの応答が遅くなったり、サービスが利用できなくなったりするなどの問題が発生する可能性があります。

ユーザーモードでのノード CPU 使用率 (%)

なし

いいえ

ユーザーモードで実行されているプロセスによって占有されているノード CPU 時間と合計 CPU 時間の比率。ユーザーモードのプロセスは、Web サービスやデータベースなど、ユーザー空間のアプリケーションです。

アイドルノードディスク容量

MB

はい

ノードの未使用ディスク容量。このメトリックを使用して、ディスク容量がいっぱいになっているかどうかを確認できます。ディスク容量がいっぱいになると、システムがクラッシュしたり、予期どおりに動作しなくなったりする可能性があります。

ノードディスク使用率 (%)

なし

いいえ

使用済みディスク容量と合計ディスク容量の比率。ディスク使用率が高いほど、ノードのストレージ容量は少なくなります。

ノードシステム負荷

なし

はい

このメトリックを使用して、ノードのワークロードが高すぎるかどうかを確認できます。N コアを持つノードの場合、最大ワークロードは N です。

アイドルノードメモリ

MB

はい

ノード内の未使用メモリのサイズ。このメトリックを使用して、ノードのメモリが十分かどうかを確認できます。ノードのメモリが不足している場合、メモリ不足 (OOM) エラーなどの例外が発生する可能性があります。

ノードメモリ使用率 (%)

なし

いいえ

使用中のメモリの割合。ノードのメモリ使用率が 80% を超える場合は、ノードの構成を調整するか、タスクのメモリ使用量を最適化することで、メモリプレッシャーを軽減する必要があります。

ノードで受信されたエラーパケットの数

なし

いいえ

ノードがネットワーク通信を処理したときに受信したエラーパケットの数。これらのエラーパケットは、ネットワーク伝送の問題またはアプリケーションの問題が原因である可能性があります。エラーパケットを受信すると、ノードはネットワーク通信の処理に失敗し、システムに影響を与える可能性があります。

ノードから送信されたエラーパケットの数

なし

いいえ

ノードがネットワーク通信を処理したときに送信したエラーパケットの数。これらのエラーパケットは、ネットワーク伝送の問題またはアプリケーションの問題が原因である可能性があります。このメトリックを使用して、ノードネットワークが正常かどうかを確認できます。

JVM インスタンスの数

なし

はい

リアルタイムで実行されている JVM インスタンスの数。一般に、このメトリックはサービスダウンタイムアラートを構成するために使用されます。

ノードから送信されたバイト数

なし

いいえ

アプリケーションによって送信されたデータ、システムメッセージ、エラーメッセージを含む、ネットワーク経由でノードによって送信されたデータ量。

ノードから送信されたパケットの数

なし

いいえ

ネットワーク経由でノードから送信されたメッセージの数。

ノードで受信されたバイト数

なし

いいえ

ネットワーク経由でノードによって受信されたデータの総量。

ノードで受信されたパケットの数

なし

いいえ

ネットワーク経由でノードによって受信されたパケットの数。

ディメンションとフィルター条件

上記のメトリックは、ノードの IP アドレスによって監視されます。IP アドレスをフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: 各ノードの IP アドレスをトラバースし、各ノードのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のノードを指定します。例: =172.20.XX.XX

  • ディメンションなし: すべてのノードのメトリックデータを集計し、アラートを構成します。

コンテナー

ARMS エージェント v4.1.0 以降は、監視とアラートのために CPU とメモリに関する監視データを収集します。

メトリック

メトリック名

単位

よく使用される

説明

ユーザーモードでの CPU 使用率

なし

いいえ

プロセスがユーザーモードでコードを実行するのに費やした時間。これは、アプリケーションがタスクを実行するために直接使用する CPU 時間であり、アプリケーションコードと、カーネルモードで実行されないすべてのライブラリ関数が含まれます。

カーネルモードでの CPU 使用率

なし

いいえ

プロセスがカーネルモード (システムモードとも呼ばれます) で実行するのに費やした時間。カーネルモードは、アプリケーションがシステムコールを実行したり、割り込みを処理したり、カーネルによって提供される機能を使用したりするときに発生します。この時間の部分は、オペレーティングシステムがプロセスにサービスを提供する際に消費する CPU リソースを反映しています。

合計 CPU 使用率

なし

はい

合計 CPU 使用率は、ユーザーモードでの CPU 使用率とカーネルモードでの CPU 使用率の合計です。

メモリ使用量

バイト

はい

実行時にコンテナーによって使用されているメモリ量。オペレーティングシステムによってスワップ不可としてマークされている部分と、キャッシュされているがまだアクティブと見なされているデータを含め、コンテナーによってアクティブに使用されているメモリの総量を反映しています。

送信されたネットワークパケットの数

なし

いいえ

ネットワーク経由でコンテナーから送信されたパケットの数。

送信されたバイト数

バイト

はい

ネットワーク経由でコンテナーから送信されたバイト数。

送信されたエラーパケットの数

なし

いいえ

コンテナーがネットワーク通信を処理したときに送信したエラーパケットの数。これらのエラーパケットは、ネットワーク伝送の問題またはアプリケーションの問題が原因である可能性があります。このメトリックを使用して、コンテナーネットワークが正常かどうかを確認できます。

送信された破棄されたパケットの数

なし

いいえ

コンテナーネットワークインターフェースが起動されてから、システムまたはネットワークスタックによってドロップされた送信ネットワークパケットの総数。

受信されたパケットの数

なし

いいえ

ネットワーク経由でコンテナーによって受信されたメッセージの数。

受信されたバイト数

バイト

はい

ネットワーク経由でコンテナーによって受信されたデータの総量。

受信されたエラーパケットの数

なし

いいえ

コンテナーがネットワーク通信を処理したときに受信したエラーパケットの数。これらのエラーパケットは、ネットワーク伝送の問題またはアプリケーションの問題が原因である可能性があります。エラーパケットを受信すると、コンテナーはネットワーク通信の処理に失敗し、システムに影響を与える可能性があります。

受信された破棄されたパケットの数

なし

いいえ

コンテナーネットワークインターフェースが起動されてから、システムまたはネットワークスタックによってドロップされた受信ネットワークパケットの総数。

ディメンションとフィルター条件

上記のメトリックは、ノードの IP アドレスによって監視されます。IP アドレスをフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: コンテナーをトラバースし、各コンテナーのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のコンテナーを指定します。例: =172.20.XX.XX

  • ディメンションなし: すべてのコンテナーのメトリックデータを集計し、アラートを構成します。

アプリケーション提供サービス

メトリック

メトリック名

単位

よく使用される

説明

呼び出しの数

なし

はい

HTTP 呼び出しと Dubbo 呼び出しを含む、アプリケーションエントリポイント呼び出しの数。このメトリックを使用して、アプリケーションの呼び出し数を分析し、ビジネスボリュームを推定し、アプリケーションで例外が発生するかどうかを確認できます。

スローコールの数

なし

いいえ

HTTP 呼び出しと Dubbo 呼び出しを含む、アプリケーションエントリポイント呼び出しの応答時間がしきい値を超えると、スローコールとしてカウントされます。このメトリックを使用して、アプリケーションで例外が発生するかどうかを確認できます。

エラー呼び出しの数

なし

はい

HTTP 呼び出しと Dubbo 呼び出しを含む、アプリケーションのエラーエントリポイント呼び出しの数。ステータスコード 400 が返されるか、アプリケーションエントリポイント呼び出しが Dubbo の最上位層によってインターセプトされると、呼び出しはエラーと見なされます。このメトリックを使用して、アプリケーションにエラー呼び出しがあるかどうかを確認できます。

呼び出しエラー率 (%)

なし

はい

アプリケーションエントリポイント呼び出しのエラー率は、次の式を使用して計算されます。エラー率 = アプリケーションエントリポイントエラー呼び出しの数 / アプリケーションエントリポイント呼び出しの総数 × 100%。

呼び出し応答時間

ミリ秒

はい

HTTP 呼び出しや Dubbo 呼び出しなど、アプリケーションエントリポイント呼び出しの応答時間。このメトリックを使用して、遅いリクエストと例外を確認できます。

ディメンションとフィルター条件

上記のメトリックは、インターフェース名によって監視されます。インターフェース名をフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: アクセスされたインターフェースをトラバースし、各インターフェースのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のインターフェースを指定します。例: =/tb/api/users/{userId}

  • 等しくない (!=): アラートから特定のインターフェースを除外し、他のインターフェースのアラートを個別に構成します。例: !=/tb/api/users/{userId}

  • 含む: 特定のキーワードを含むインターフェースのアラートを構成します。例: 含む api

  • 含まない: 特定のキーワードを含まないインターフェースのアラートを構成します。例: 含まない api

  • 正規表現:指定された正規表現に一致するインターフェースのアラートを構成します。例: =/(api)/i

  • ディメンションなし: すべてのインターフェースのメトリックデータを集計し、アラートを構成します。

上記のメトリックは、インターフェース呼び出しタイプによって監視されます。インターフェース呼び出しタイプをフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: インターフェース呼び出しタイプをトラバースし、HTTP、MySQL、Redis など、各タイプのメトリックデータのアラートを個別に構成します。

  • 等しい (=): アラートの特定のインターフェース呼び出しタイプを指定します。例: =http

  • ディメンションなし: すべてのインターフェースのメトリックデータを集計し、アラートを構成します。

スレッドプール

メトリック

メトリック名

よく使用される

説明

コアスレッド数

はい

スレッドプールで常にアクティブなスレッドの数。

最大スレッド数

はい

スレッドプールに同時に存在できる最大スレッド数。

アクティブスレッド数

はい

タスクを実行しているスレッドの数。このメトリックを使用して、スレッドプールの状態を監視し、スレッドプールの性能を評価できます。

キューサイズ

はい

スレッドキューのサイズは、アプリケーションの要件とシステムリソースの可用性によって異なります。マルチスレッドプログラミングでは、キューサイズが小さすぎると、タスクが長時間キューに入れられる可能性があります。これは、プログラムの性能を低下させます。キューサイズが大きすぎると、大量のシステムリソースが消費される可能性があります。これは、システムのクラッシュまたは性能の低下を引き起こします。

現在のスレッド数

はい

実行中または実行待ちのスレッドの数。

実行されたタスクの数

はい

タスクキューまたはスレッドプールで実行および完了したタスクの数。このメトリックを使用して、タスクキューまたはスレッドプールの性能を評価できます。

スレッドプール使用率 (%)

はい

スレッドプールで使用中のスレッド数とスレッドプールの合計スレッド数の比率。

ディメンションとフィルター条件

上記のメトリックは、ノードの IP アドレスによって監視されます。IP アドレスをフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: 各ノードの IP アドレスをトラバースし、各ノードのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のノードを指定します。例: =172.20.XX.XX

  • ディメンションなし: すべてのノードのメトリックデータを集計し、アラートを構成します。

上記のメトリックは、スレッドプール名によって監視されます。スレッドプール名をフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: スレッドプールをトラバースし、各スレッドプールのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のスレッドプールを指定します。例: =pool-*-thread-*

  • ディメンションなし: すべてのスレッドプールのメトリックデータを集計し、アラートを構成します。

上記のメトリックは、スレッドプールタイプによって監視されます。スレッドプールタイプをフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: スレッドプールタイプをトラバースし、各スレッドプールタイプのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のスレッドプールタイプを指定します。例: =FixedThreadPool

  • ディメンションなし: すべてのスレッドプールタイプのメトリックデータを集計し、アラートを構成します。

HTTP ステータスコード

メトリック

メトリック名

よく使用される

説明

4xx ステータスコードの HTTP リクエスト数

はい

ステータスコード 4xx が返された HTTP リクエストの数。4xx ステータスコードは、リクエストされたリソースが存在しないか、必要なパラメーターがないことを示します。一般的な 4xx ステータスコードには、400 と 404 が含まれます。

5xx ステータスコードの HTTP リクエスト数

はい

ステータスコード 5xx が返された HTTP リクエストの数。5xx ステータスコードは、内部サーバーエラーが発生したか、システムがビジー状態であることを示します。一般的な 5xx ステータスコードには、500 と 503 が含まれます。

ディメンションとフィルター条件

上記のメトリックは、インターフェース名によって監視されます。インターフェース名をフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: アクセスされたインターフェースをトラバースし、各インターフェースのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のインターフェースを指定します。例: =/tb/api/users/{userId}

  • 等しくない (!=): アラートから特定のインターフェースを除外し、他のインターフェースのアラートを個別に構成します。例:!=/tb/api/users/{userId}

  • 含む: 特定のキーワードを含むインターフェースのアラートを構成します。例: 含む api

  • 含まない: 特定のキーワードを含まないインターフェースのアラートを構成します。例: 含まない api

  • 正規表現: 指定された正規表現に一致するインターフェースのアラートを構成します。例: =/(api)/i

  • ディメンションなし: すべてのインターフェースのメトリックデータを集計し、アラートを構成します。

データベース

メトリック

メトリック名

単位

よく使用される

説明

データベースリクエスト数

なし

はい

アプリケーションが実行時にデータベースに送信したリクエストの数。各リクエストには、読み取りまたは書き込み操作が含まれています。データベースリクエスト数は、アプリケーションの性能と応答時間に影響します。

データベースリクエストエラー数

なし

はい

アプリケーションが実行時にデータベースをリクエストしたときに発生したエラーの数。たとえば、データベース接続の失敗、クエリステートメントのエラー、権限の不足などです。データベースリクエストエラーの数が多いことは、アプリケーションとデータベース間のインタラクションが異常であることを示しています。この場合、アプリケーションは予期どおりに実行できません。

データベースリクエスト応答時間

ミリ秒

はい

アプリケーションがデータベースにリクエストを送信してからデータベースが応答するまでの時間間隔。データベースリクエストの応答時間は、アプリケーションの性能とユーザーエクスペリエンスに影響します。応答時間が長すぎると、アプリケーションが停止したり、速度が低下したりする可能性があります。

低速データベースリクエスト数

なし

いいえ

アプリケーションからリクエストを送信してからデータベースから応答を受信するまでの時間がしきい値を超えると、スローコールとしてカウントされます。スローコールの数が多いと、アプリケーションの性能とユーザーエクスペリエンスに直接影響します。

ディメンションとフィルター条件

上記のメトリックは、データベース名によって監視されます。データベース名をフィルタリングするには、次のいずれかの方法を使用できます。

  • トラバーサル: データベースをトラバースし、各データベースのメトリックデータのアラートを構成します。

  • 等しい (=): アラートの特定のデータベースタイプを指定します。例: =mysql-pod:3306(demo_db)

  • ディメンションなし: すべてのデータベースのメトリックデータを集計し、アラートを構成します。