この記事には、このサービスに関するすべての監視リファレンス情報が含まれています。
メトリック
このセクションには、このサービスに関して自動的に収集されるすべてのプラットフォーム メトリックが一覧表示されています。 これらのメトリックは、Azure Monitor でサポートされているすべてのプラットフォーム メトリックのグローバル リストにも含まれています。
メトリックのリテンション期間の詳細については、「Azure Monitor メトリックの概要」を参照してください。
Microsoft.Cache/redisEnterprise でサポートされているメトリックの詳細と情報については、次のセクションを参照してください。
Microsoft.Cache/redisEnterprise でサポートされているメトリック
次の表に、Microsoft.Cache/redisEnterprise リソースの種類で使用できるメトリックの一覧を示します。
- すべての列がすべてのテーブルに存在しないことがあります。
- 一部の列がページの表示領域を超えている場合があります。 [テーブルの展開] を選択すると、使用可能なすべての列が表示されます。
テーブルの見出し
- カテゴリ - メトリック グループまたは分類。
- メトリック - Azure Portal に表示されるメトリックの表示名。
- REST API の名前 - REST API で参照されるメトリック名。
- 単位 - 測定単位。
- 集計 - 既定の集計の種類。 有効な値: 平均 (Avg)、最小 (Min)、最大 (Max)、合計 (Sum)、数。
- ディメンション - メトリックで使用できるディメンション。
-
時間グレイン - メトリックをサンプリングする間隔。 たとえば、
PT1Mは、メトリックを 1 分ごとに、PT30Mは 30 分ごとに、PT1Hは 1 時間ごとにサンプリングすることを示します。 - DS エクスポート - メトリックが診断設定を介して Azure Monitor ログにエクスポート可能かどうかを示します。 メトリックのエクスポートについては、「Azure Monitor で診断設定を作成する」を参照してください。
| メトリック | REST API での名前 | 高度なプラットフォーム メトリック | 単位 | 集約 | 次元 | タイムグレインズ | DS エクスポート |
|---|---|---|---|---|---|---|---|
|
キャッシュ ヒット数 成功したキー参照の数。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
cachehits |
いいえ | 数える | 合計 (和) | <なし> | PT1M | イエス |
|
キャッシュ待機時間マイクロ秒 (プレビュー) キャッシュへの待機時間 (マイクロ秒単位)。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
cacheLatency |
いいえ | 数える | 平均 | InstanceId |
PT1M | イエス |
|
キャッシュ ミス数 失敗したキー参照の数。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
cachemisses |
いいえ | 数える | 合計 (和) | <なし> | PT1M | イエス |
|
キャッシュの読み取り キャッシュから読み取られたデータ量。1 秒あたりのメガバイト (MB/秒) 単位。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
cacheRead |
いいえ | 秒あたりのバイト数 | 最大値 | InstanceId |
PT1M | イエス |
|
キャッシュの書き込み キャッシュに書き込まれたデータ量。1 秒あたりのメガバイト (MB/秒) 単位。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
cacheWrite |
いいえ | 秒あたりのバイト数 | 最大値 | InstanceId |
PT1M | イエス |
|
接続されているクライアント数 キャッシュへのクライアント接続の数。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
connectedclients |
いいえ | 数える | 最大値 | InstanceId |
PT1M | イエス |
|
削除されたキー キャッシュから強制削除された項目数。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
evictedkeys |
いいえ | 数える | 合計 (和) | <なし> | PT1M | イエス |
|
期限切れのキー キャッシュで有効期限が切れた項目数。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
expiredkeys |
いいえ | 数える | 合計 (和) | <なし> | PT1M | イエス |
|
地理的レプリケーションの状態は正常です アクティブ ジオ レプリケーション グループ内のジオ レプリケーションの正常性。 0 は異常を表し、1 は正常を表します。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
geoReplicationHealthy |
いいえ | 数える | 最大値 | <なし> | PT1M | イエス |
|
取得数 キャッシュからの取得操作の数。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
getcommands |
いいえ | 数える | 合計 (和) | <なし> | PT1M | イエス |
|
1 秒あたりの操作数 キャッシュで実行された 1 秒あたりの即時操作の数。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
operationsPerSecond |
いいえ | 数える | 最大値 | <なし> | PT1M | イエス |
|
CPU Azure Redis Cache サーバーの CPU 使用率 (パーセント)。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
percentProcessorTime |
いいえ | パーセント | 最大値 | InstanceId |
PT1M | イエス |
|
サーバーの負荷 Redis サーバーの処理がビジーで、アイドル状態でメッセージを待機していないサイクルの割合。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
serverLoad |
いいえ | パーセント | 最大値 | <なし> | PT1M | イエス |
|
設定 キャッシュへの設定操作の数。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
setcommands |
いいえ | 数える | 合計 (和) | <なし> | PT1M | イエス |
|
合計操作数 キャッシュ サーバーによって処理されたコマンドの合計数。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
totalcommandsprocessed |
いいえ | 数える | 合計 (和) | <なし> | PT1M | イエス |
|
合計キー数 キャッシュ内の項目の合計数。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
totalkeys |
いいえ | 数える | 最大値 | <なし> | PT1M | イエス |
|
メモリ使用量 キャッシュ内のキーと値のペアに使用されたキャッシュ メモリの量 (MB 単位)。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
usedmemory |
いいえ | バイト（データ単位） | 最大値 | <なし> | PT1M | イエス |
|
使用されているメモリの割合 キーと値のペアに使用されたキャッシュ メモリの割合 (パーセント)。 詳細については、https://aka.ms/redis/enterprise/metricsを参照してください。 |
usedmemorypercentage |
いいえ | パーセント | 最大値 | <なし> | PT1M | イエス |
Azure Managed Redis メトリックの詳細
以下のセクションでは、Microsoft対応のAzure Monitorメトリクスに関する詳細情報と解釈ガイダンスを提供します。キャッシュ/redisEnterprise。 単位や集約タイプのメトリクスの全リストについては、 サポート済みメトリクス の表をご覧ください。
クラスターレベルの指標に関する詳細
以下の表は、各クラスタレベルの指標に対する基礎となるRedis V1 Prometheusソース指標と追加の解釈ガイダンスを示しています。 ソースメトリックの定義については、 Redis Enterprise Prometheus v1メトリクスのリファレンスを参照してください。
| メトリック | 出典と注釈 |
|---|---|
| キャッシュレイテンシ | 指定されたレポート間隔中にキャッシュ ノード上のエンドポイントによって処理される要求の平均待機時間。 この指標はミリ秒単位で測定され、 node_avg_latency V1プロメテウス指標から得られています。 このメトリックは、キャッシュにアクティブなトラフィックがある場合にのみ報告されます。 |
| キャッシュ ヒット数 | 成功率は、1秒あたりのヒット数で表されます。
bdb_read_hits V1 Prometheus メトリクスから出典。 これはレート指標です。Azure Monitorのユニットはカウントとして表示されますが、値は秒単位のレートです。 |
| キャッシュ ミス数 | 鍵検索失敗率は、1秒あたりのミス数で表されます。
bdb_read_misses_max V1 Prometheus メトリクスから出典。 これはレート指標です。Azure Monitorのユニットはカウントとして表示されますが、値は秒単位のレートです。 キャッシュ ミスは、必ずしもキャッシュに問題があるということではありません。 たとえば、キャッシュ アサイド プログラミング パターンを使用する場合、アプリケーションはまず項目をキャッシュから検索します。 項目が見つからなかった (キャッシュ ミス) 場合は、データベースから項目を取得して、次回使用するためにキャッシュに追加されます。 キャッシュ ミスは、キャッシュ アサイド プログラミング パターンでは普通の動作です。 キャッシュ ミスの数が予想よりも大きい場合は、キャッシュにデータを入力またはキャッシュからデータを読み取るアプリケーション ロジックを確認してください。 メモリ不足のために項目がキャッシュから削除されている場合は、キャッシュ ミスが発生する可能性がありますが、メモリ不足を監視するメトリックの方が Used Memory or Evicted Keys。 |
| キャッシュの読み取り | キャッシュノードへの受信ネットワークトラフィックのバイト毎秒の速度を表します。 この値は node_ingress_bytes_max V1プロメテウス指標から得られます。 サーバー側のネットワーク帯域幅制限のアラートを設定する場合は、このキャッシュ読み取りカウンターを使用して作成します。 キャッシュのさまざまな価格レベルとサイズで観測された帯域幅の制限値については、こちらの表を参照してください。 これはバイト毎秒で表されるレート指標です。 |
| キャッシュの書き込み | キャッシュノードからの送信ネットワークトラフィックのバイト毎秒の速度を表します。 この値は node_egress_bytes_max V1プロメテウス指標から得られます。 これはバイト毎秒で表されるレート指標です。 |
| 接続されているクライアント数 | これはノード上のエンドポイントに接続されたクライアント数をカウントする、 node_conns V1のPrometheusメトリックから取得しています。 接続の制限に達すると、後でキャッシュへの接続が失敗します。 アクティブなクライアント アプリケーションがない場合でも、内部処理や接続によって接続されたクライアントのインスタンスが少数見つかることがあります。 |
| CPU |
node_cpu_idle V1のPrometheusメトリックに由来し、平均CPUのアイドル時間部分(0から1の値に100を掛けてパーセンテージを表します)を表し、CPUの忙しい時間を反映するために逆になっています。 CPU メトリックには、厳密には Redis サーバー プロセスではないマルウェア対策などのバックグラウンド プロセスが含まれているため、Redis ワークロードとは無関係に急増することがあります。 このメトリックは、監視のために サーバー負荷 に対して使用することをお勧めします。これは、インスタンス ID で分割することでインスタンス レベルのドリルダウンをサポートするため、どのノードに負荷がかかされているかをより細かく設定します。 |
| 削除されたキー数 | キーの立ち退き速度は、1秒あたりの退去数で表されます。
bdb_evicted_objects V1 Prometheus メトリクスから出典。 これはレート指標です。Azure Monitorのユニットはカウントとして表示されますが、値は秒単位のレートです。 |
| 期限切れキー数 | 鍵の有効期限率は、1秒あたりの有効期限数で表されます。
bdb_expired_objects V1 Prometheus メトリクスから出典。 これはレート指標です。Azure Monitorのユニットはカウントとして表示されますが、値は秒単位のレートです。 |
| Geo Replication Healthy (正常な Geo レプリケーション) | アクティブな Geo-Replication グループ内のキャッシュ間の geo レプリケーション リンクの正常性を示します。 メトリックは、次の 2 つの値のいずれかを報告します。 0 - 断絶/不健康 1 - 健康 このメトリックは、geo レプリケーションが有効になっているメモリ最適化、分散、コンピューティング最適化レベルのキャッシュで使用できます。 値 0 は、geo レプリカ上のデータが失われたという意味ではありません。 geo プライマリと geo セカンダリ間のリンクが異常であることを意味しているだけです。 このメトリックは、月次パッチの適用、ホスト OS の更新、ネットワーク構成の誤り、geo レプリケーション リンクのプロビジョニング失敗など、いくつかの理由で、切断/異常のレプリケーション状態を示している可能性があります。 Azure Managed Redis サービスは、最新のプラットフォーム機能と機能強化を使用してキャッシュに定期的にパッチを適用します。 これらの更新中、各キャッシュ ノードはオフラインになり、geo レプリケーション リンクが一時的に無効になります。 geo レプリケーション リンクが異常な場合は、ポータルの [リソース] メニューの [問題の診断と解決 ] を使用して、geo プライマリ キャッシュまたは geo セカンダリ キャッシュのパッチ適用イベントが原因かどうかを確認します。 キャッシュ内のデータの量に応じて、パッチ適用によるダウンタイムには数分から 1 時間かかる場合があります。 geo レプリケーション リンクが 1 時間以上異常な場合は、サポート リクエストを提出してください。 |
| 取得数 | 読み取り操作の速度は、1秒あたりの演算で表されます。 これは bdb_read_req V1のPrometheusメトリックから得られ、データベース上のすべての読み取りリクエストのレートを表し、キャッシュのヒット数とミス数の合計に相当します。 これはレート指標です。Azure Monitorのユニットはカウントとして表示されますが、値は秒単位のレートです。 |
| 1 秒あたりの操作回数 | 指定されたレポート間隔中にキャッシュのすべてのシャードによって 1 秒あたりに処理された要求の合計数。 この値は bdb_instantaneous_ops_per_sec V1プロメテウス指標から得られます。 これはレート指標で、秒あたりの操作数で表されます。 |
| サーバーの負荷 |
サーバー負荷指標は、Redisサーバー自身が全体の負荷を評価したものです。
CPUメトリックと同様に、node_cpu_idleV1のPrometheusメトリックをベースに、サーバーの忙しい時間を反映するために逆に導き出しています。 違いは 、サーバー負荷 はクラスタレベルで測定されるのに対し、 CPU はノード(インスタンス)レベルで測定される点です。サーバー負荷 が100に達したからといって、必ずしもCPUがキャッシュ全体で使い果たされているわけではありません。これは、ノードのCPUが飽和状態に近づいていることを示すことがあります。 このため、複数のキャッシュにデータを拡張したり分割したりするパフォーマンス関連の判断をする前に、 サーバー負荷 とノードごとの CPU 指標の両方を評価してください。 持続的な高 負荷 サーバー負荷には、サーバー側の遅延増加やタイムアウト例外など、いくつかの副作用が生じる可能性があります。 注意:Azure管理のRedisキャッシュの場合、Server Loadは時に100を超える値を反映します。 パフォーマンスベースの意思決定を行う前に 、CPU メトリックを使うか、両方の指標を一緒に評価することをお勧めします。 |
| 設定 | 書き込み操作の速度は、秒あたりの操作で表されます。 データベース上のすべての書き込みリクエストのレートを表す、 bdb_write_req V1 Prometheusメトリックから得られます。 これはレート指標です。Azure Monitorのユニットはカウントとして表示されますが、値は秒単位のレートです。 |
| 合計キー数 |
bdb_no_of_keys V1 Prometheus メトリクスから出典。重要: クラスタリングが有効なキャッシュの基盤となるメトリクスシステムの制限により、Total Keysは報告期間中に最大キー数を持っていたシャードの最大キー数を返します。 クラスタ化されたキャッシュのシャードごとの正確なキーカウントを見るには、 Slots (Range)次元でスライスしたシャードレベルのシャードキーカウントメトリックを使用します。 |
| 操作の合計 | すべての操作の速度を秒あたりの操作で表します。
bdb_total_req V1 Prometheus メトリクスから出典。 これはレート指標です。Azure Monitorのユニットはカウントとして表示されますが、値は秒単位のレートです。 |
| メモリ使用量 |
bdb_used_memory V1 Prometheus メトリクスから出典。 Flash Optimized レベルのキャッシュでは、この値には RAM とフラッシュ メモリの両方の使用量が含まれます。 この値には、断片化は含まれません。高可用性が有効になっている場合、[使用済みメモリ] の値には、プライマリ ノードとレプリカ ノードの両方にメモリが含まれます。 これにより、メトリックが予想の 2 倍の大きさで表示される可能性があります。 |
| 使用されているメモリの割合 | Redis Enterprise V1のPrometheus指標から、 bdb_used_memory と bdb_memory_limit の比率として計算されます。 この値には、断片化は含まれません。 |
シャードレベルの指標
Azure Managed Redisは、シャードレベルの指標を公開し、シャードごとのキャッシュ動作を可視化します。 これらのメトリクスはRedis V2のPrometheusエンドポイント(redis_server_* メトリクス)から取得されています。
次元
各シャードレベルの指標は以下の次元をサポートしています:
| ディメンション | REST API での名前 | Description |
|---|---|---|
Instance ID |
InstanceId |
クラスタ内の特定のRedisノード(VMインスタンス)を特定します。 この次元を使って、ノードごとの挙動を分離し、ノード間の負荷不均衡を特定しましょう。 |
Slots (Range) |
Slots |
シャードはハッシュスロットの範囲で識別します。 この次元を使って、シャード間のメモリの不均衡やキー分布の不均一を検出します。 |
Shard ID |
Shard |
RedisシャードのUIDを使ったユニークなシャード識別子。 この次元をSlots (Range)と併用して、Azure MonitorデータをRedisレベルのシャード識別子と相関させましょう。 |
Shard Role |
Role |
ノードの役割: primary または replica。 この次元を使って、同じシャード上のプライマリノードとレプリカノード間のメトリクスを比較します。 |
Note
Azure Monitor REST APIで次元で分割またはフィルタリングする際は、ポータルの表示名ではなく「REST APIの名前」列の値を使いましょう。 Azure Monitor REST APIのメトリクス名と次元名は大文字を区別しません。 例えば、 percentProcessorTime、 PercentProcessorTime、 PERCENTPROCESSORTIME のクエリはすべて同じ結果を返します。 次元フィルターの値も同様で、 instanceId eq '*' と INSTANCEID eq '*' は同値です。 この記事で使用されているケースは、読みやすさのための慣例です。
Important
これらの指標はシャードレベルで公開されます。 次元で分割せずにクエリされた場合、Azure Monitorはデフォルトの集約タイプですべてのシャードの値を集約します。 ほとんどの指標において、このクロスシャード集約は意味のあるクラスタ全体の合計を生み出しません。 正確なシャードごとの分析のために、常に Slots (Range) 次元で分割してください。
シャードレベルのメトリクスに関する詳細
以下の表は、各シャードレベルメトリクスに対する基礎となるRedis V2 Prometheusソースメトリクスと追加の解釈ガイダンスを提供します。 ソースメトリックの定義については、 Redis Enterprise Prometheus v2メトリクスの参考文献を参照してください。
| メトリック | 詳細情報 |
|---|---|
| 使用シャードメモリ(バイト数)(プレビュー) | このシャードが使用するメモリはバイト単位です。 フラッシュ対応SKUでは、DRAMとフラッシュの両方の使用が含まれます。
redis_server_used_memory Redis V2 Prometheus指標から出典。 |
| シャードメモリクライアント 通常(バイト)(プレビュー) | 非レプリカクライアントの入出力バッファに使用される現在のメモリ。
redis_server_mem_clients_normal Redis V2 Prometheus指標から出典。 |
| シャードメモリクライアントレプリカ(バイト)(プレビュー) | レプリカクライアントの入出力バッファに使用されている現在のメモリ。
redis_server_mem_clients_slaves Redis V2 Prometheus指標から出典。 |
| シャードキーカウント(プレビュー) | 総キー数。
redis_server_db_keys Redis V2 Prometheus指標から出典。 |
| シャード複製リンクアップ(プレビュー) | レプリカがプライマリに接続されているかどうかを示します。 これは redis_server_master_link_status Redis V2 Prometheusメトリクスから得られ、これはレプリカシャードのみが送信します。なぜなら、レプリカだけがプライマリへのレプリケーションリンクを持ち、報告できるからです。 |
ビッグキーの指標
以下の指標はシャード間の鍵サイズ分布を追跡し、大きな鍵がパフォーマンス問題を引き起こす前に特定するのに役立ちます。
Note
ビッグキーの指標はまだアクティブジオレプリケートキャッシュにはサポートされていません。 ジオレプリケートキャッシュのこれらの指標のサポートは後日提供される予定です。
文字列キー(メモリサイズによる)
| メトリック | 詳細情報 |
|---|---|
| シャード文字列のサイズ 128MB未満(プレビュー) | このシャードのメモリサイズが128MB未満の文字列キーの数。 |
鍵のセット(要素数による)
| メトリック | 詳細情報 |
|---|---|
| シャードがアイテムを100万要素に設定する(プレビュー) | このシャードのセットキーの数は100万要素未満です。 |
| シャードがアイテム1Mから8M要素を設定する(プレビュー) | このシャードには100万から800万の要素を持つセットキーの数があります。 |
| シャードがアイテムを800万要素以上に設定(プレビュー) | このシャードには800万以上の要素を持つセットキーの数があります。 |
ソートされた集合キー(要素数別)
| メトリック | 詳細情報 |
|---|---|
| シャードソートが1M要素未満のアイテムをセット(プレビュー) | このシャード上のソートされたセットキーの数は、100万要素未満です。 |
| シャードソートセットのアイテム1Mから8M要素(プレビュー) | このシャード上にソートされたセットキーの数は、100万から800万の要素の間です。 |
| シャードソートが800万要素以上のアイテムをセット(プレビュー) | このシャードには800万以上の要素を持つソートセットキーの数があります。 |
ハッシュキー(フィールドカウント別)
| メトリック | 詳細情報 |
|---|---|
| シャードは100万要素未満のアイテムをハッシュ化します(プレビュー) | このシャード上の100万フィールド未満のハッシュキーの数。 |
| シャードは1Mから8Mの要素をハッシュ化します(プレビュー) | このシャード上のハッシュキーの数は100万から800万フィールドの範囲です。 |
| シャードが800万要素以上のアイテムをハッシュ化(プレビュー) | このシャード上のハッシュキーの数は800万フィールド以上です。 |
リストキー(要素数別)
| メトリック | 詳細情報 |
|---|---|
| シャードが100万要素未満のアイテムをリストアップ(プレビュー) | このシャード上のリストキーの数は100万要素未満です。 |
| シャードはアイテム1Mから8Mの要素をリストアップします(プレビュー) | このシャード上のリストキーの数は100万から800万の要素です。 |
| シャードが800万要素以上のアイテムをリストアップ(プレビュー) | このシャードには800万以上の要素を持つリストキーの数があります。 |
シャードレベルの指標によるトラブルシューティング
以下のセクションでは、一般的なシャードレベルのシナリオとその診断方法について説明します。
レプリケーションリンクの故障の特定
レプリケーションリンク障害は、プライマリシャードが関連するレプリカシャードとのレプリケーション接続を確立できず、レプリカがプライマリシャードと同期できなくなった場合に発生します。 このメトリクスはレプリカシャードのみが出力します。なぜなら、レプリカだけがプライマリへのレプリケーションリンクを持ち、そのレプリカが現在プライマリに接続されているかどうかを報告するためです。 継続的な障害は影響を受けたシャードの高可用性保護を失い、リンクが回復する前にフェイルオーバーが発生した場合のデータ損失リスクが高まります。 とはいえ、フェイルオーバー、シャードの移行、スケーリング、保守イベントの際にレプリケーションリンクが一時的に不健康になることがあるため、この指標はノイズが出ることがあります。 このため、この指標でアラートを設定する際は、健康状態の低下を示す複数のデータポイントを含む持続的な期間のみアラートを行うことが重要です。
検出アプローチ:
-
シャード複製リンクを
Slots (Range)で分割してください。 任意のシャードで値が0の場合は、そのシャードの複製リンクがダウンしていることを意味します。1は上がっていることを意味します。 - 長期間(例えば120分以上)0のままのリンクは、一時的な再接続ではなく持続的な障害とみなしてください。 通常のメンテナンスやフェイルオーバー時に短時間の低下が生じることがあります。
- 同じシャード上で 使用されたシャード メモリとシャー ドメモリクライアントレプリカ を関連付けて、プライマリにかかるリソース負荷が故障に伴うかどうかを調べます。
一般的な原因:
- 大きなキーが大きな原因です。 大きな鍵やコレクションは同期を遅くコストよくし、レプリカが停滞し、最終的にレプリケーションリンクを不健康な状態に陥らせる可能性があります。
- プライマリノードとレプリカノード間のネットワーク障害や高い遅延。
- プライマリシャードが過負荷(書き込みスループットが高いかCPU飽和状態)でレプリケーションを処理できない状態です。
- プライマリにかかるメモリ圧が、レプリカ同期に必要なバックグラウンド操作を妨げています。
- 遅いレプリカがレプリケーションのバックログに遅れを取ることで、繰り返しの完全な再同期サイクルが発生しました。
対応策:
- 持続的な書き込みスループットを減らすか、キャッシュを拡張して容量を増やし、プライマリシャードの飽和状態を減らします。
- 影響を受けたシャードでのレプリケーションや再同期コストが高くなる大きな鍵を特定し、分割しましょう。
- 負荷が減ってもリンクがダウンし続ける場合は、サポートリクエストを開き、プラットフォームチームがノードの健康状態や内部複製のバックログを調査できるようにします。
記憶の不均衡の特定
メモリアンバランスは、あるシャードが他よりも著しく多くのメモリを使う場合に起こり、特定のシャードで追放される一方で、他のシャードは十分な空きメモリを持っている場合があります。
検出アプローチ:
-
Slots (Range)が使用した分割シャードメモリ(バイト数)を使います。 最大/最小比が2倍を超える場合は、意味のある不均衡を示します。 - シャー ドキーカウント と
Slots (Range)相関して、不均衡がキー数が多いのか、特定のシャードの値が大きいのかを判断します。
一般的な原因:
- ハッシュタグの誤用は、同じシャードに大量のキーを集中させる現象です。
- ビッグキー:特定のシャード上に非常に大きなデータ構造が少数存在する。
- TTLポリシーの不一致により、時間とともにメモリ使用量の乖離が生じます。
対応策:
- 鍵を再配布するために、ハッシュタグの使用を見直し、変化させましょう。
- Big Keysの指標を使って影響を受けたシャードを特定し、分割します。
- 高メモリシャードのキーのTTLポリシーを確認してください。
複製バッファーの成長診断
各プライマリシャードは、レプリカの書き込みキューがまだ適用されていない出力バッファを保持しています。 レプリカが追いつかなくなると、このバッファは成長し、シャード上のメモリを消費します。 もしバウンドなしで成長すると、レプリカは切断され、完全な再同期を強制される可能性があり、これはコストがかかり、繰り返しの再同期サイクルに発展したり、レプリケーション同期が健康で悪くなることもあります。 各シャードには独自のレプリカバッファがあるため、成長はしばしば特定のシャードに限定されます。
検出アプローチ:
-
シャードメモリクライアントのレプリカ(バイト単位)を
Slots (Range)ごとに分割し、15分以上続くシャードで持続的な上昇傾向があるかを観察してください。単一の高負荷読み取りではなく。 一時的な急増ではなく、着実な成長が信号です。 - 同じシャード上でシャー ド複製リンク アップと関連付けてください。 リンクが0に落ちるまでバッファが成長している場合は、レプリカが切断されていることを示し、再同期が行われる可能性が高いです。
- 書き込み重視の活動(クラスターレベルではセット や トータルオペレーション )と相関し、書き込みバーストが成長を促進しているかどうかを調べます。
一般的な原因:
- 持続的な書き込みバーストは、レプリカが適用できる速度よりも速く変更を生み出します。
- 資源争いの中、プライマリーに遅れを取る遅いレプリカ。
- バッファを繰り返し埋め戻す完全な再同期ループ。
- 大きなキーが複製された操作を大きくし、転送が遅くなります。
対応策:
- 可能な限り書き込みバーストを平滑化または減らすか、キャッシュを拡張して容量を増やすこと。
- 大きな鍵を特定し分割することで、個々の複製操作のサイズを削減しましょう。
- バッファが増え続け、レプリカが繰り返し切断する場合は、サポートリクエストを開き、プラットフォームチームがサービスが管理するレプリカの健康状態やバッファサイズを確認してもらいます。
大きな鍵の管理
大きな鍵や大規模なコレクションは個々のシャードへのメモリ負荷を高め、複製コストを増やします。 最良のデータパス性能を得るためには、個々のキー/値のサイズを512KB未満に抑えましょう。 これは性能の推奨であり、強制的な制限ではありません。
大きなキーメトリクスバケットは境界の監視のみであり、推奨または推奨されるキーサイズではありません。 例えば、「128MB未満のシャード文字列サイズ」は128MB未満の文字列キーを単純にカウントしているため、成長を観察できます。Azureがキーを128MB付近に保存することを推奨しているわけではありません。 同様に、要素数バケット(1M、8M)は、過大コレクションを検出するための閾値であり、ターゲットサイズではありません。 常に実用的な最小のキーサイズ(理想的には512KB未満)を目標にし、より高いバケットに入るキーは調査対象として扱いましょう。
Big Keysはバケットキーのサイズ範囲を測定し、問題が起きる前に成長を見逃さないようにしています。 コレクションの場合、最初のバケットは通常範囲内の鍵を表しているため、2番目または3番目のバケットに現れる鍵は調査に値します。 文字列キーの場合は128MB未満のバケットのみが露出しているため、128MBに近づくかそれを超える文字列値は問題視してください。
なぜ大きな鍵が重要なのか:
- レプリケーションコスト:大きな鍵は高可用性レプリケーションとアクティブジオレプリケーション(CRDB)の両方のコストを増加させます。 その効果は即座に現れるものではありません。通常、後の故障や再接続によって引き起こされる完全再同期時に表面化します。
- フラッシュ最適化キャッシュへの影響:フラッシュ最適化SKUでは、キーが大きい場合RAMに残り、フラッシュにオフロードされないため、フラッシュディスクの空きスペースが残っていてもメモリ外(OOM)エラーが発生することがあります。 キー名に対して非常に小さい値は、オフロードも悪くなります。
検出アプローチ:
- 大きな鍵の指標を
Slots (Range)で分割して、どのシャードに大きな鍵が入っているか確認します。 - コレクションでは、2番目と3番目の要素カウントバケット(1Mから8Mおよび8M以上)に焦点を当ててください。 3つ目のバケットは最も極端な鍵を表しています。 文字列については、 128MB未満のシャード文字列 サイズのみが公開されているため、128MB以上の文字列値は考慮してください。
- シャー ドメモリ との相関
Slots (Range)が特定のシャードのメモリ不均衡を引き起こしているかどうかを確認するために使われる。
対応策:
- ベストプラクティスとして、最初のバケットまたは512KBに向かって値サイズを縮小しましょう。 一般的な戦略には、大きな値を複数のキーに分割またはチャンク化したり、シリアル化された値を圧縮または再フォーマットしたりする方法があります。
- 時間とともに無限に増え続けるコレクション(リスト、セット、ソート済みセット、ハッシュ)については、複数のキーに分割するか、定期的にトリミングしてください。
- 目標は個々の鍵とコレクションのサイズを減らすことです。 最適な方法は、あなたのアプリケーションの設計やデータ型によって異なります。
シャードレベルの指標に対するアラート推奨
| シナリオ | メトリック | 状態 | 評価ウィンドウ | Severity |
|---|---|---|---|---|
| レプリケーションリンクの故障 | シャード複製リンクアップ、分割 Slots (Range) |
任意のシャードで最小値=0 | 120+分 | High |
| 記憶の不均衡 | 使用されるシャードメモリ(バイト数)、分割 Slots (Range) |
スロット間の最大/最小比率 > 2倍 | 5 分 | Medium |
| 複製バッファーの成長 | シャードメモリクライアントレプリカ(バイト)、分割 Slots (Range) |
15分間の持続的な増加 | 15 分 | Medium |
| 非常に大規模なコレクション(第3バケット) | 「800万要素以上」コレクションバケットの指標を分割して Slots (Range) |
どのシャードでも値 > 0 | 10分以上 | High |
| 大規模コレクション(第2バケット) | 「1Mから8M要素」の収集バケット指標を、以下で分割します。 Slots (Range) |
そのタイプの総キーに占めるバケット数は10を超えます% | 10分以上 | Medium |
| 大きな弦の鍵 | シャード文字列のサイズ 128MB未満(唯一の露出文字列バケット) | 128MB以上の文字列値は問題です。128MB未満のキー数に注目してください。閾値に向かって伸びているキーのカウントです | 10分以上 | 参考情報 |
Note
レプリケーションリンク障害のアラートは、メトリクスが最小値として集約されるため、ウィンドウ上の数値が0であればリンクが一度ダウンしていたことを示すため、直接Azure Monitorのメトリックアラートとして作成できます。 非常に大きなコレクション(サードバケット)アラートもネイティブ作成可能で、単一の指標を0より大きい閾値に対してテストします。 残りのシナリオは、Azure Monitorメトリクスアラートでネイティブに評価できません。メトリクスアラートは次元値間の値を比較できず(例えばSlots (Range)間の最大/最小比)、2つの指標間の比率(例えば、そのタイプの総キーに占める第2バケットカウント)を検出できず、持続的な上昇傾向を検出できません。 それらは、ある時点で値が一定の閾値を超えたかどうかのみをテストします。 エクスポートされた指標に対してログ検索アラートとして作成します。診断設定を使ってLog Analyticsのワークスペースにメトリックを送信し、Kusto(KQL)クエリで最大/最小比率、バケットシェア、またはトレンドを計算します。 ファーストバケットの指標はアラートを必要としません。時間をかけて動向を監視しましょう。
リソース ログ
このセクションでは、このサービス用に収集できるリソース ログの種類を一覧表示します。 このセクションでは、Azure Monitor でサポートされているすべてのリソース ログ カテゴリの種類のリストからプルされます。
Microsoft.Cache/redisEnterprise/databases でサポートされているリソース ログ
| カテゴリ | エクスポートのコスト | ログテーブル | 基本ログプランをサポートします | インジェスト時変換をサポート | クエリの例 |
|---|---|---|---|---|---|
| 接続イベント (新しい接続/認証/切断) | イエス |
REDConnectionEvents クライアントが redis エンタープライズ データベースに接続するときの接続イベントをログに記録します。 |
イエス | イエス | クエリ |
Azure Monitor ログ テーブル
このセクションでは、Kusto クエリを使用した Log Analytics によるクエリに使用できる、このサービスに関連するすべての Azure Monitor ログ テーブルを一覧表示します。 テーブルにはリソース ログ データが含まれており、収集されルーティングされる内容によっては、さらに多くのデータが含まれる場合があります。
Azure マネージド再配布
マイクロソフト.キャッシュ/redisEnterprise
アクティビティ ログ
リンクされたテーブルには、このサービスのアクティビティ ログに記録できる操作が一覧表示されます。 これらの操作は、アクティビティ ログで使用可能なすべてのリソース プロバイダー操作のサブセットです。
アクティビティ ログ エントリのスキーマの詳細については、「アクティビティ ログのスキーマ」を参照してください。
関連コンテンツ
- Azure リソースの監視の詳細については、「Azure Monitor で Azure リソースを監視する」を参照してください。