5.6. クラスタリングメトリクス
メトリクスを使用して、Red Hat build of Keycloak のノード間の通信を監視します。
これは、メトリクスを使用したトラブルシューティング 章の一部です。
5.6.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- Red Hat build of Keycloak でメトリクスを有効にしている。詳細は、メトリクスから洞察を得る の章を参照してください。
- メトリクスを収集する監視システム。
5.6.2. メトリクス リンクのコピーリンクがクリップボードにコピーされました!
複数の Red Hat build of Keycloak ノードをデプロイすると、それらのノード間で負荷を分散できますが、そのためにはノード間の通信が必要です。このセクションでは、Red Hat build of Keycloak 間の通信を監視して、起こりうる障害を特定するのに役立つメトリクスを説明します。
これはシングルサイトデプロイメントにのみ適用されます。マルチサイトデプロイメント で説明されているように、複数のサイトを使用する場合、Red Hat build of Keycloak ノードはクラスター化されないため、ノード間の直接通信は行われません。
グローバルタグ
cluster=<name>
- クラスター名。複数のクラスターからメトリクスを収集している場合、このタグを使用してメトリクスの所属先を識別できます。
node=<node>
- メトリクスを報告するノードの名前。
vendor_jgroups_
で始まるすべてのメトリクス名は、トラブルシューティングとデバッグのためだけに提供されています。メトリクス名は、Red Hat build of Keycloak の今後のリリースで予告なく変更される可能性があります。したがって、ダッシュボードや監視およびアラートでは使用しないことが推奨されます。
5.6.2.1. レスポンス時間 リンクのコピーリンクがクリップボードにコピーされました!
次のメトリクスは、リモートリクエストのレスポンス時間を公開します。レスポンス時間は 2 つのノード間で測定され、処理時間も含まれます。すべてのリクエストはこれらのメトリクスによって測定され、レスポンス時間はクラスターのライフサイクルを通じて安定しているはずです。
健全なクラスターでは、レスポンス時間は安定しています。レスポンス時間が増加した場合は、クラスターの性能が低下しているか、ノードの負荷が大きいことを示している可能性があります。
タグ
node=<node>
- 送信側ノードを識別します。
target_node=<node>
- 受信ノードを識別します。
メトリクス | 説明 |
---|---|
| 受信ノードへの同期リクエストの数。 |
| 受信ノードへの同期リクエストの合計期間 |
ヒストグラムを有効にすると、パーセンタイルバケットが利用可能になります。これらはヒートマップを作成するのに役立ちますが、パーセンタイルバケットを収集して公開すると、デプロイメントのパフォーマンスに悪影響を与える可能性があります。
5.6.2.2. 帯域幅 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of Keycloak によって送受信されるすべてのバイトは、これらのメトリクスによって収集されます。また、ハートビートなどのすべての内部メッセージもカウントされます。そのため、各ノードで現在使用されている帯域幅の計算が可能になります。
メトリクス名は、使用されている JGroups トランスポートプロトコルによって異なります。
メトリクス | Protocol | 説明 |
---|---|---|
|
| ノードが受信したバイトの合計数。 |
|
| |
|
| |
|
| ノードが送信したバイトの合計数。 |
|
| |
|
|
5.6.2.3. スレッドプール リンクのコピーリンクがクリップボードにコピーされました!
スレッドプールのサイズを監視することは、ノードに大きな負荷がかかっているかどうかを示す良い指標となります。受信したすべてのリクエストは処理のためにスレッドプールに追加され、スレッドプールがいっぱいになると、リクエストは破棄されます。再送信メカニズムにより、リソース使用量が増加しても信頼性の高い通信が確保されます。
正常なクラスターでは、スレッドプールが最大サイズ (デフォルトでは 200
スレッド) に近づくことはありません。
スレッドプールメトリクスは仮想スレッドでは使用できません。OpenJDK 21 で実行する場合、仮想スレッドはデフォルトで有効になります。
メトリクス名は、使用されている JGroups トランスポートプロトコルによって異なります。デフォルトのトランスポートプロトコルは TCP です。
メトリクス | Protocol | 説明 |
---|---|---|
|
| スレッドプール内の現在のスレッド数。 |
|
| |
|
| |
|
| これまでにプール内で同時に存在したスレッドの最大数。 |
|
| |
|
|
5.6.2.4. フロー制御 リンクのコピーリンクがクリップボードにコピーされました!
フロー制御は、時間の経過とともに、メッセージ送信側の速度を最も遅い受信側の速度に合わせて調整します。これはクレジットベースのシステムを通じて実装され、各送信側のクレジットが送信時に減少します。送信側は、クレジットが 0 を下回るとブロックし、受信側から補充メッセージを受信した場合にのみメッセージの送信を再開します。
以下のメトリクスは、ブロックされたメッセージの数と平均ブロック時間を示しています。値がゼロではない場合、受信側が過負荷になっているためにクラスターのパフォーマンスが低下する可能性があることを示しています。
各ノードには、ユニキャストメッセージ用の UFC
とマルチキャストメッセージ用の MFC
という、2 つの独立したフロー制御プロトコルがあります。
正常なクラスターでは、すべてのメトリクスの値がゼロになります。
メトリクス | 説明 |
---|---|
| フロー制御がユニキャストメッセージの送信側をブロックした回数。 |
| ユニキャストメッセージを送信しようとしたときにフロー制御でブロックされた平均時間 (ミリ秒)。 |
| フロー制御がマルチキャストメッセージの送信側をブロックした回数。 |
| マルチキャストメッセージを送信しようとしたときにフロー制御でブロックされた平均時間 (ミリ秒)。 |
5.6.2.5. 再送信 リンクのコピーリンクがクリップボードにコピーされました!
JGroups は信頼性の高いメッセージ配信を提供します。メッセージがネットワーク上でドロップされた場合、または送信側がメッセージを処理できない場合は、再送信する必要があります。再送信によりリソース使用量が増加し、通常これはシステムの過負荷を示しています。
Random Early Drop (RED) は送信側のキューを監視します。キューがほぼいっぱいになると、メッセージはドロップされ、再送信が必要になります。これは、送信側のキューがいっぱいになってスレッドがブロックされることを防ぎます。
正常なクラスターでは、すべてのメトリクスの値がゼロになります。
メトリクス | 説明 |
---|---|
| 再送信されたメッセージの数。 |
| 送信側によってドロップされたメッセージの合計数。 |
| 送信がによってドロップされた全メッセージの割合。 |
5.6.2.6. ネットワークパーティション リンクのコピーリンクがクリップボードにコピーされました!
5.6.2.6.1. クラスターサイズ リンクのコピーリンクがクリップボードにコピーされました!
クラスターサイズメトリクスは、クラスター内に存在するノードの数を報告します。異なる場合は、ノードが参加途中か、シャットダウンしているか、最悪の場合はネットワークパーティションの発生を示している可能性があります。
正常なクラスターでは、すべてのノードで同じ値が示されます。
メトリクス | 説明 |
---|---|
| クラスター内のノード数。 |
5.6.2.6.2. ネットワークパーティションイベント リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のネットワークパーティションはさまざまな理由で発生します。このメトリクスは、ネットワーク分割を予測するためには使用できませんが、ネットワーク分割が発生してクラスターが統合されたことを示します。
正常なクラスターでは、このメトリクスの値はゼロになります。
メトリクス | 説明 |
---|---|
| ネットワーク分割が検出されてから復旧するまでの時間。 |
5.6.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
メトリクスを使用したトラブルシューティング に戻るか、シングルサイトデプロイメント用の埋め込み Infinispan メトリクス に進みます