グローバルタグ
cluster=<name>-
クラスタ名。複数のクラスタからのメトリクスが収集されている場合、このタグはそれらがどこに属しているかを識別するのに役立ちます。
node=<node>-
メトリクスを報告するノードの名前。
これは、メトリクスを使用したトラブルシューティングガイドの一部です。
Keycloakでメトリクスを有効にする必要があります。詳細については、メトリクスによる洞察の獲得ガイドに従ってください。
メトリクスを収集する監視システム。
複数のKeycloakノードをデプロイすることで、ノード間で負荷を分散できますが、これにはノード間の通信が必要です。このセクションでは、起こりうる障害を特定するためにKeycloak間の通信を監視するのに役立つメトリクスについて説明します。
| これは、シングルサイトデプロイメントにのみ関連します。マルチサイトデプロイメントで説明されているように、マルチサイトが使用されている場合、Keycloakノードはクラスタ化されないため、ノード間に直接的な通信はありません。 |
グローバルタグ
cluster=<name>クラスタ名。複数のクラスタからのメトリクスが収集されている場合、このタグはそれらがどこに属しているかを識別するのに役立ちます。
node=<node>メトリクスを報告するノードの名前。
|
|
次のメトリクスは、リモートリクエストの応答時間を公開します。応答時間は2つのノード間で測定され、処理時間を含みます。すべてのリクエストはこれらのメトリクスによって測定され、応答時間はクラスタのライフサイクルを通じて安定している必要があります。
| 健全なクラスタでは、応答時間は安定したままです。応答時間の増加は、クラスタの劣化または高負荷状態のノードを示している可能性があります。 |
タグ
node=<node>送信元ノードを識別します。
target_node=<node>受信ノードを識別します。
| メトリクス | 説明 |
|---|---|
|
受信ノードへの同期リクエストの数。 |
|
受信ノードへの同期リクエストの合計時間 |
| ヒストグラムが有効になっている場合、パーセンタイルバケットが利用可能です。これらはヒートマップを作成するのに役立ちますが、パーセンタイルバケットを収集および公開すると、デプロイメントのパフォーマンスに悪影響を与える可能性があります。 |
Keycloakによって受信および送信されたすべてのバイトは、これらのメトリクスによって収集されます。また、ハートビートなどのすべての内部メッセージもカウントされます。これらにより、各ノードで現在使用されている帯域幅を計算できます。
| メトリクス名は、使用中のJGroupsトランスポートプロトコルによって異なります。 |
| メトリクス | プロトコル | 説明 |
|---|---|---|
|
|
ノードが受信したバイト数の合計。 |
|
|
|
|
|
|
|
|
ノードが送信したバイト数の合計。 |
|
|
|
|
|
スレッドプールのサイズを監視することは、ノードが高負荷状態にあることを示す良い指標です。受信したすべてのリクエストは処理のためにスレッドプールに追加され、スレッドプールが満杯になると、リクエストは破棄されます。再送信メカニズムにより、リソース使用量が増加しても信頼性の高い通信が保証されます。
健全なクラスタでは、スレッドプールが最大サイズ（デフォルトでは 200 スレッド）に近づくことはありません。 |
| スレッドプールのメトリクスは、仮想スレッドでは利用できません。仮想スレッドは、OpenJDK 21で実行している場合、デフォルトで有効になっています。 |
| メトリクス名は、使用中のJGroupsトランスポートプロトコルによって異なります。デフォルトのトランスポートプロトコルはTCPです。 |
| メトリクス | プロトコル | 説明 |
|---|---|---|
|
|
スレッドプール内の現在のスレッド数。 |
|
|
|
|
|
|
|
|
これまで同時にプール内に存在したスレッドの最大数。 |
|
|
|
|
|
フロー制御は、メッセージ送信者のレートを最も遅い受信者のレートに時間経過とともに調整します。これは、クレジットベースのシステムを通じて実装され、各送信者は送信時にクレジットを減らします。クレジットが0を下回ると送信者はブロックされ、受信者から補充メッセージを受信したときにのみメッセージの送信を再開します。
以下のメトリクスは、ブロックされたメッセージの数と平均ブロック時間を示しています。値がゼロと異なる場合、受信者が過負荷状態であり、クラスタのパフォーマンスが低下している可能性があることを示している場合があります。
各ノードには、ユニキャストメッセージ用の UFC とマルチキャストメッセージ用の MFC の2つの独立したフロー制御プロトコルがあります。
| 健全なクラスタは、すべてのメトリクスでゼロの値を示します。 |
| メトリクス | 説明 |
|---|---|
|
フロー制御がユニキャストメッセージの送信者をブロックした回数。 |
|
ユニキャストメッセージを送信しようとしたときにフロー制御でブロックされた平均時間（ミリ秒単位）。 |
|
フロー制御がマルチキャストメッセージの送信者をブロックした回数。 |
|
マルチキャストメッセージを送信しようとしたときにフロー制御でブロックされた平均時間（ミリ秒単位）。 |
JGroupsは、メッセージの信頼性の高い配信を提供します。メッセージがネットワーク上でドロップされた場合、または受信者がメッセージを処理できない場合、再送信が必要になります。再送信はリソース使用量を増やし、通常はシステムの過負荷の兆候です。
ランダム早期ドロップ（RED）は、送信者キューを監視します。キューがほぼ満杯になると、メッセージはドロップされ、再送信が発生する必要があります。これにより、スレッドが満杯の送信者キューによってブロックされるのを防ぎます。
| 健全なクラスタは、すべてのメトリクスでゼロの値を示します。 |
| メトリクス | 説明 |
|---|---|
|
再送信されたメッセージの数。 |
|
送信者によってドロップされたメッセージの総数。 |
|
送信者によってドロップされたすべてのメッセージの割合。 |