診断レポートの分析 - Tair (Redis® OSS-Compatible) - Alibaba Cloud ドキュメントセンター

診断レポートは、ApsaraDB for Redisインスタンスの動作状態を評価し、パフォーマンスレベル、スキューされたリクエスト分布、スローログなどの統計に基づいてインスタンスの異常を特定するのに役立ちます。

前提条件

診断レポートの作成

診断レポートのコンポーネント

基本インスタンス情報: インスタンスID、インスタンスタイプ、エンジンバージョン、インスタンスがデプロイされているゾーンなど、インスタンスの基本情報を表示します。
Summary: インスタンスの健全性ステータスのスコアを表示し、ポイントが差し引かれる理由を説明します。
パフォーマンスレベル: インスタンスに関連する主要なパフォーマンスメトリックの統計と状態を表示します。
最大数の低速クエリを受信するトップ10ノード: 最大数の低速クエリを受信するトップ10のデータノードを表示し、低速クエリに関する情報を提供します。

基本インスタンス情報

このセクションには、インスタンスID、インスタンスタイプ、エンジンバージョン、およびインスタンスがデプロイされているリージョンが表示されます。

概要

このセクションには、診断結果とインスタンスの健全性ステータスのスコアが表示されます。最高のスコアは100です。インスタンスのスコアが100未満の場合は、診断項目と詳細を確認できます。

パフォーマンスレベル

このセクションには、インスタンスに関連する主要なパフォーマンスメトリックの統計と状態が表示されます。 ハザード状態にあるパフォーマンス指標に注意を払う必要があります。

説明

インスタンスがクラスターアーキテクチャまたは読み書き分離アーキテクチャで実行されている場合は、パフォーマンスメトリックが歪んでいるかどうかを確認し、データノードが歪んでいるかどうかを確認する必要があります。クラスターおよび読み書き分離アーキテクチャの詳細については、「クラスターマスターレプリカインスタンス」および「読み書き分離インスタンス」をご参照ください。さらに、[上位5ノード] セクションの各パフォーマンスメトリックの曲線グラフに基づいて、負荷の高いデータノードに注目することをお勧めします。

パフォーマンスメトリック	しきい値	影響	考えられる原因とトラブルシューティング方法
CPU使用率	60%	ApsaraDB for RedisインスタンスのCPU使用率が高い場合、インスタンスのスループットとクライアントへの応答時間が影響を受けます。場合によっては、クライアントは応答できないことがある。	考えられる原因：インスタンスは、時間の複雑さを必要とするコマンドを実行します。ホットキーが存在します。接続は頻繁に確立されます。これらの問題のトラブルシューティング方法の詳細については、「ApsaraDB For Redisインスタンスの高CPU使用率のトラブルシューティング」をご参照ください。
メモリ使用量	80%	ApsaraDB for Redisインスタンスのメモリ使用量が継続的に増加すると、応答時間が長くなり、1秒あたりのクエリ数 (QPS) が不安定になり、キーが頻繁に追い出される可能性があります。これはビジネスに影響します。	考えられる原因：メモリが使い果たされます。多数の大きなキーが存在する。これらの問題をトラブルシューティングする方法の詳細については、「ApsaraDB For Redisインスタンスの高メモリ使用量のトラブルシューティング」をご参照ください。
データノードの接続使用量	80%	データノードへの接続数が上限に達すると、接続要求がタイムアウトまたは失敗する可能性があります。説明このメトリックは、クライアントが直接接続モードでApsaraDB for Redisクラスターインスタンスに接続したときに収集されます。ダイレクト接続モードの詳細については、「ダイレクト接続モードの有効化」をご参照ください。クライアントがプロキシノードを使用してApsaraDB for Redisクラスターインスタンスまたは読み書き分離インスタンスに接続する場合、このメトリックは収集されません。この場合、プロキシノードの接続数を監視する必要があります。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。	考えられる原因：ユーザーのトラフィックが急増します。アイドル接続は長期間解放されません。これらの問題をトラブルシューティングする方法の詳細については、「インスタンスセッション」をご参照ください。
インバウンドトラフィック	80%	インバウンドトラフィックまたはアウトバウンドトラフィックがインスタンスタイプによって提供される最大帯域幅を超えると、クライアントのパフォーマンスが影響を受けます。	考えられる原因：ワークロードが急増します。大きなキーは頻繁に読み書きされます。これらの問題のトラブルシューティングの詳細については、「ApsaraDB For Redisインスタンスでの高トラフィック使用量のトラブルシューティング」をご参照ください。
送信トラフィック	80%

インスタンスがクラスターアーキテクチャまたは読み書き分離アーキテクチャで実行されている場合、システムは前述のパフォーマンスメトリックに基づいてインスタンスの全体的なアクセスパフォーマンスを測定し、その結果を診断レポートに表示します。次の表に、スキューされたリクエストを判断するために使用される基準、スキューされたリクエストの考えられる原因、およびトラブルシューティング方法を示します。

説明

インスタンスが特定のパフォーマンスメトリックに対するリクエストをスキューしていることを診断レポートが示している場合は、スキューされたリクエストが送信されるノードを確認する必要があります。

基準

考えられる原因

トラブルシューティング方法

次の条件が満たされています。

ApsaraDB for Redisインスタンスのすべてのデータノードのパフォーマンスメトリクスのピーク値は、次のしきい値よりも大きくなります。
- CPU使用率: 10% 。
- メモリ使用量: 20% 。
- インバウンドトラフィックとアウトバウンドトラフィック: 5 Mbit/s。
- 接続使用法: 5% 。
残高スコアは、以下の式: max {全データノードの平均性能値} /全データノードの性能中央値を用いて計算される、1.3より大きい。
たとえば、ApsaraDB For Redisインスタンスには4つのデータノードがあり、4つのノードの平均CPU使用率は10% 、30% 、50% 、60% です。次に、中央値を40% し、結果を60%/40% から1.5する。計算された値1.5は1.3より大きい。そのため、インスタンスのCPU使用率が歪んでいると見なされます。

データノードは、過度に大きなキーを有する。
データノードにはホットキーがあります。
ハッシュタグが不適切に設定されています。
説明
キーが同じハッシュタグで構成されている場合、キーは同じデータノードに格納されます。多数のキーが同じハッシュタグで構成されている場合、ノードはこれらのキーに圧倒されます。

最大数の低速クエリを受信するトップ10ノード

このセクションでは、最大数の低速クエリを受け取る上位10個のデータノードと、低速クエリに関する統計情報を表示します。統計には、次のスローログが含まれます。

システム監査ログに保存されているデータノードのスローログ。これらのスローログは4日間のみ保持されます。
データノードに保存されているスローログ。最新の1,024ログエントリのみが保持されます。 redis-cliを使用してインスタンスに接続し、SLOWLOG GETコマンドを実行してこれらのスローログを表示できます。

低速クエリを分析し、不適切なコマンドが存在するかどうかを判断できます。このようにして、さまざまな問題の解決策を見つけることができます。

原因	解決策
keys * など、時間の複雑さがO(N) のコマンド、または大量のCPUリソースを消費するコマンド。	FLUSHALL、KEYS、HGETALLなど、リスクが高く、CPUリソースを大量に消費するコマンドを評価および無効にします。詳細については、「高リスクコマンドの無効化」をご参照ください。
データノードから頻繁に読み書きされる大きなキー。	大きなキーを分析して評価します。詳細については、「オフラインキー分析機能の使用」をご参照ください。次に、ビジネス要件に基づいてこれらの大きなキーを分割します。