Azure Cache for Redis を監視する

この記事では、次の内容について説明します。

• このサービスに対して収集できる監視データの種類。
• そのデータを分析する方法。

Note

このサービスや Azure Monitor を既に使い慣れていて、監視データの分析方法だけを確認したい場合は、この記事で後述する分析に関するセクションをご覧ください。

Azure リソースに依存するクリティカルなアプリケーションやビジネス プロセスがある場合は、システムを監視し、そのアラートを受け取る必要があります。 Azure Monitor サービスでは、システムのすべてのコンポーネントからメトリックとログを収集して集計します。 Azure Monitor を使用すると、可用性、パフォーマンス、回復性を視覚化し、問題に関する通知を受け取ることができます。 Azure portal、PowerShell、Azure CLI、REST API、またはクライアント ライブラリは、監視データの設定および表示に使用できます。

• Azure Monitor の詳細については、「Azure Monitor の概要」を参照してください。
• Azure リソース全般の監視方法の詳細については、「Azure Monitor を使用した Azure リソースの監視」をご覧ください。

分析情報

Azure の一部のサービスについては、サービスを監視するための開始点となる監視ダッシュボードが Azure portal に組み込まれています。 これらのダッシュボードは、"分析情報" と呼ばれており、Azure portal の Azure Monitor の [分析情報ハブ] にあります。

Azure Cache for Redis 用の分析情報は、次のエクスペリエンスを提供します。

• 大規模な分析観点 (サブスクリプションにまたがる Azure Cache for Redis リソースについて)。 評価するサブスクリプションとリソースのみに選択的にスコープを設定できます。
• ドリルダウン分析 (ある Azure Cache for Redis リソースについて)。 問題を診断するために、使用率、障害、容量、操作の詳細な分析を確認でき、関連情報の詳細なビューを表示できます。
• カスタマイズ (Azure Monitor ブック テンプレートに基づいて作成)。 表示されるメトリックを変更したり、制限に合うようにしきい値を変更または設定したりできます。 カスタム ブックに変更を保存し、ブック グラフを Azure ダッシュボードにピン留めすることができます。

Azure Cache for Redis 用の分析情報には、何の有効化も構成も必要ありません。 Azure Cache for Redis の情報は既定で収集され、分析情報にアクセスするための追加料金は発生しません。

Azure Cache for Redis の分析情報を表示、構成、カスタマイズする方法については、「Azure Cache for Redis 用の Azure Monitor の分析情報」を参照してください。

リソースの種類

Azure では、リソースの種類と ID の概念を使用して、サブスクリプション内のすべてを識別します。 リソースの種類は、Azure で実行されているすべてのリソースのリソース ID の一部でもあります。 たとえば、Microsoft.Compute/virtualMachines は、仮想マシンのリソースの種類の 1 つです。 サービスとそれに関連付けられるリソースの種類の一覧については、リソース プロバイダーに関するページをご覧ください。

同様に、Azure Monitor では、コア監視データがリソースの種類 (名前空間とも呼ばれます) に基づいてメトリックとログに整理されます。 リソースの種類に応じてさまざまなメトリックとログが使用できます。 サービスは、複数のリソースの種類に関連付けられる可能性があります。

Azure Cache for Redis のリソースの種類の詳細については、「Azure Cache for Redis 監視データ リファレンス」を参照してください。

データ ストレージ

Azure Monitor の場合:

• メトリック データは、Azure Monitor メトリック データベースに保存されます。
• ログ データは、Azure Monitor ログ ストアに保存されます。 Log Analytics は、Azure portal のツールの 1 つであり、このストアに対してクエリを実行することができます。
• Azure アクティビティ ログは、Azure Portal 内の独自のインターフェイスを持つ別のストアです。

必要に応じて、メトリックおよびアクティビティ ログ データを Azure Monitor ログ ストアにルーティングできます。 次に、Log Analytics を使用してデータのクエリを実行し、他のログ データと関連付けることができます。

多くのサービスで診断設定を使用して、メトリックとログ データを Azure Monitor の外部の他のストレージの場所に送信できます。 たとえば、Azure Storage、ホステッド パートナー システム、Event Hubs を使用する Azure 以外のパートナー システムなどがあります。

Azure Monitor によるデータの保存方法の詳細については、「Azure Monitor データ プラットフォーム」を参照してください。

Azure Monitor プラットフォームのメトリック

Azure Monitor により、ほとんどのサービスに関するプラットフォーム メトリックが提供されます。 これらのメトリックは次のとおりです。

• 名前空間ごとに個別に定義されます。
• Azure Monitor 時系列メトリック データベースに保存されます。
• 軽量であり、凖リアルタイムのアラートをサポートできます。
• リソースのパフォーマンスを時間の経過と共に追跡するために使用されます。

収集: Azure Monitor では、プラットフォーム メトリックを自動的に収集します。 構成は必要ありません。

ルーティング: また、いくつかのプラットフォーム メトリックを Azure Monitor ログまたは Log Analytics にルーティングして、他のログ データを使用してクエリを実行することもできます。 各メトリックの DS エクスポート設定を確認して、診断設定を使用してメトリックを Azure Monitor ログまたは Log Analytics にルーティングできるかどうかを確認します。

• 詳細については、「メトリック診断設定」を参照してください。
• サービスの診断設定を構成する場合は、「Azure Monitor の診断設定を作成する」を参照してください。

Azure Monitor ですべてのリソースに対して収集できるすべてのメトリックの一覧については、Azure Monitor でサポートされるメトリックに関する記事を参照してください。

Azure Cache for Redis で使用可能なメトリックの一覧については、「Azure Cache for Redis 監視データ リファレンス」を参照してください。

Azure Monitor リソース ログ

リソース ログでは、Azure リソースによって実行された操作に関する分析情報を提供します。 ログは自動的に生成されますが、保存するかクエリを実行するには、Azure Monitor ログにルーティングする必要があります。 ログはカテゴリに分類されています。 特定の名前空間に複数のリソース ログ カテゴリが含まれる場合があります。

収集: リソース ログは、"診断設定" を作成してログを 1 つ以上の場所にルーティングするまでは収集および保存されません。 診断設定を作成するときは、収集するログのカテゴリを指定します。 診断設定を作成して管理するには、Azure portal、プログラム、Azure Policy など、複数の方法があります。

ルーティング: 既定で推奨されるのは、リソース ログを Azure Monitor ログにルーティングして、他のログ データを使用してクエリを実行できるようにすることです。 Azure Storage、Azure Event Hubs、特定の Microsoft 監視パートナーなど、その他の場所も利用できます。 詳細については、「Azure リソース ログ」およびリソース ログの送信先に関するページを参照してください。

リソース ログの収集、保存、ルーティングの詳細については、「Azure Monitor の診断設定」を参照してください。

Azure Monitor で使用可能なすべてのリソース ログ カテゴリの一覧については、Azure Monitor でサポートされているリソース ログに関するページを参照してください。

Azure Monitor 内のすべてのリソース ログには、同じヘッダー フィールドの後にサービス固有のフィールドがあります。 共通のスキーマの概要については、Azure Monitor リソース ログのスキーマに関する記事をご覧ください。

使用可能なリソース ログ カテゴリ、それに関連する Log Analytics テーブル、および Azure Cache for Redis のログ スキーマについては、「Azure Cache for Redis 監視データ リファレンス」を参照してください。

Azure Cache for Redis リソース ログ

Azure Cache for Redis では、ログに対して次の 2 つのオプションがあります。

• キャッシュ メトリック ("AllMetrics"): Azure Monitor からのメトリックをログします
• 接続ログは、セキュリティと診断の目的でキャッシュへの接続をログに記録します。

キャッシュ メトリック

Azure Cache for Redis は、ログに役立つ Server Load や Connections per Second などの多くのメトリックを出力します。 AllMetrics オプションを選択すると、これらのキャッシュ メトリックとその他のキャッシュ メトリックをログに記録できます。 メトリックが保持される期間を構成できます。

接続ログ

Azure Cache for Redis では、Azure 診断設定を使用して、キャッシュに対するクライアント接続に関する情報がログに記録されます。 この診断設定のログ記録と分析は、キャッシュに接続しているユーザーと、それらの接続のタイムスタンプを把握するのに役立ちます。 このログ データは、セキュリティ侵害の範囲を特定するため、およびセキュリティ監査の目的に使用できます。

接続ログは、Azure Cache for Redis のレベルが異なると、実装、内容、およびセットアップ手順が若干異なります。 詳細については、Azure Monitor の診断設定に関する記事を参照してください。

Azure activity log

アクティビティ ログには、Azure リソースごとに操作を追跡する、そのリソースの外から見たサブスクリプションレベルのイベント (新しいリソースの作成や仮想マシンの起動など) が含まれます。

収集: アクティビティ ログ イベントは、Azure portal で表示するために、個別のストアに自動的に生成および収集されます。

ルート指定: アクティビティ ログ データを Azure Monitor ログに送信して、他のログ データと共に分析できます。 Azure Storage、Azure Event Hubs、特定の Microsoft 監視パートナーなど、その他の場所も利用できます。 アクティビティ ログをルーティングする方法の詳細については、Azure アクティビティ ログの概要に関するページをご覧ください。

監視データを分析する

監視データを分析するためのツールは多数あります。

Azure Monitor ツール

Azure Monitor は、次の基本的なツールをサポートします。

• メトリックス エクスプローラー。Azure リソースのメトリックを表示および分析できる Azure portal のツール。 詳細については、「Azure Monitor メトリック ス エクスプローラーを使用したメトリックの分析」を参照してください。

• Log Analytics は、Kusto クエリ言語 (KQL) を使用して、ログ データのクエリと分析を可能にする Azure Portal のツールです。 詳細については、「Azure Monitor でログ クエリの使用を開始する」を参照してください。

• アクティビティ ログ。表示および基本的な検索用のユーザー インターフェイスが Azure portal に用意されています。 より詳細な分析を行うには、データを Azure Monitor ログにルーティングし、Log Analytics でより複雑なクエリを実行する必要があります。

より複雑な視覚化を可能にするツールは次のとおりです。

• ダッシュボードを使用すると、さまざまな種類のデータを組み合わせて、Azure portal 内の 1 つのペインに表示できます。
• ブック。Azure portal で作成できるカスタマイズ可能なレポート。 ブックには、テキスト、メトリック、ログ クエリを含めることができます。
• Grafana。運用ダッシュボードに優れたオープン プラットフォーム ツール。 Grafana を使用して、Azure Monitor 以外の複数のソースからのデータを含むダッシュボードを作成できます。
• Power BI。さまざまなデータ ソースにわたって対話型の視覚化を提供するビジネス分析サービス。 Azure Monitor からログ データを自動的にインポートするように Power BI を構成して、これらの視覚化を利用できます。

Azure Monitor エクスポート ツール

次の方法を使用して、Azure Monitor から他のツールにデータを取得できます。

• メトリック: メトリック用 REST API を使用して、Azure Monitor メトリック データベースからメトリック データを抽出します。 この API では、取得したデータを絞り込むためのフィルター式がサポートされています。 詳細については、Azure Monitor REST API のリファレンスをご覧ください。

• ログ: REST API または関連するクライアント ライブラリを使用します。

• もう 1 つのオプションは、ワークスペース データのエクスポートです。

Azure Monitor 用 REST API の使用を開始するには、「Azure 監視 REST API のチュートリアル」を参照してください。

Azure Cache for Redis のメトリック

Azure Cache for Redis インスタンスのメトリックは、Redis INFO コマンドを使用して収集されます。 メトリックは 1 分あたり約 2 回収集されるため、メトリック グラフに表示してアラート ルールによって評価できます。 データが保持される期間と、異なる保持ポリシーを構成する方法については、Azure Monitor ログでのデータの保持とアーカイブに関するページを参照してください。

メトリックは、[過去 1 時間]、[本日]、[過去 1 週間]、[カスタム] などのいくつかのレポート期間で報告されます。 各メトリック グラフには、グラフ内の各メトリックの平均値、最小値、および最大値が表示され、一部のメトリックでは指定のレポート期間における合計が表示されます。

各メトリックには 2 つのバージョンが含まれています。1 つのメトリックでは、キャッシュ全体と、クラスタリングを使用するキャッシュのパフォーマンスを測定します。 メトリックの 2 番目のバージョン (名前に (Shard 0-9) が含まれているもの) では、キャッシュ内の 1 つのシャードのパフォーマンスが測定されます。 たとえば、キャッシュに 4 つのシャードがある場合、Cache Hits はキャッシュ全体の総ヒット数で、Cache Hits (Shard 3) はキャッシュの当該シャードのヒット数のみ測定します。

キャッシュ メトリックを表示する

Azure Cache for Redis の Azure Monitor メトリックは、Azure portal の Azure Cache for Redis リソースから直接表示できます。

ポータルで Azure Cache for Redis インスタンスを選びます。 [概要] ページには、事前定義された [メモリ使用量] と [Redis サーバーの負荷] の監視グラフが表示されます。 これらはキャッシュの状態を簡単に確認できる便利な概要のグラフです。

さらに詳細な情報については、[リソース] メニューの [監視] セクションから以下の便利な Azure Cache for Redis メトリックを監視できます。

Azure Cache for Redis のメトリック	詳細情報
ネットワーク帯域幅の使用量	キャッシュ パフォーマンス - 使用できる帯域幅
接続されているクライアント数	既定の Redis サーバー構成 - maxclients
サーバーの負荷	Redis サーバーの負荷
メモリ使用量	キャッシュのパフォーマンス - サイズ

独自のメトリックを作成する

確認するメトリックを追跡するための独自のカスタム グラフを作成できます。 キャッシュ メトリックは、 [過去 1 時間] 、 [今日] 、 [過去 1 週間] 、 [カスタム] などの期間でレポートが作成されます。 左側の [監視] セクションの [メトリック] を選択します。 各メトリック グラフには、グラフ内の各メトリックの平均値、最小値、および最大値が表示され、一部のメトリックでは指定のレポート期間における合計が表示されます。

各メトリックには 2 つのバージョンが含まれています。1 つのメトリックでは、キャッシュ全体と、クラスタリングを使用するキャッシュのパフォーマンスを測定します。 メトリックの 2 番目のバージョン (名前に (Shard 0-9) が含まれているもの) では、キャッシュ内の 1 つのシャードのパフォーマンスが測定されます。 たとえば、キャッシュに 4 つのシャードがある場合、Cache Hits はキャッシュ全体の総ヒット数で、Cache Hits (Shard 3) はキャッシュの当該シャードのヒット数のみ測定します。

左側の [リソース] メニューの [監視] で [メトリック] を選択します。 ここでは、メトリックの種類と集計の種類を定義して、キャッシュのための独自のグラフを設計します。

集計タイプ

集計の種類の一般情報については、「集計を構成する」を参照してください。

通常のキャッシュ条件下では、Avg と Max は似ています。これは、プライマリ ノードだけがこれらのメトリックを出力するためです。 接続されたクライアントの数が急激に変化するシナリオでは、Max、Avg、および Min の値は異なりますが、これも予期された動作です。

Count および Sum の種類は、接続されたクライアントなどの特定のメトリックについては、誤解を招く可能性があります。 代わりに、Avg メトリックを参照し、Sum メトリックを参照しないことをお勧めします。

Note

キャッシュがアイドル状態で、アクティブなクライアント アプリケーションに接続されていない場合でも、接続されているクライアント、メモリの使用状況、実行中の操作などのキャッシュ アクティビティが表示されることがあります。 このアクティビティは、キャッシュの操作としては正常です。

クラスター化されていないキャッシュの場合は、サフィックス Instance Based を付けずにメトリックを使用することをお勧めします。 たとえば、キャッシュ インスタンスのサーバー負荷を調べるには、メトリック "サーバー負荷" を使用します。

一方、クラスター化されたキャッシュの場合は、サフィックス Instance Based を付けてメトリックを使用してください。 その後、ShardId に分割またはフィルターを追加します。 たとえば、シャード 1 のサーバー負荷を調べるには、メトリック "サーバー負荷 (インスタンス ベース)" を使用してから、フィルター ShardId = 1 を適用します。

Kusto クエリ

Kusto クエリ言語 (KQL) を使用して、Azure Monitor ログ/Log Analytics ストアの監視データを分析できます。

重要

ポータルでサービスのメニューから [ログ] を選択すると、クエリ スコープが現在のサービスに設定された状態で Log Analytics が開きます。 このスコープは、ログ クエリにその種類のリソースのデータのみが含まれることを意味します。 他の Azure サービスのデータを含むクエリを実行する場合は、[Azure Monitor] メニューから [ログ] を選択します。 詳細については、「Azure Monitor Log Analytics のログ クエリのスコープと時間範囲」を参照してください。

いずれかのサービスに関する一般的なクエリの一覧については、Log Analytics クエリ インターフェイスに関するページを参照してください。

Log Analytics クエリ

注意

Azure Log Analytics の使用方法に関するチュートリアルについては、「Azure Monitor の Log Analytics の概要」を参照してください。 ログが Log Analtyics に表示されるまでに最大 90 分かかる場合があることに注意してくだい。

ここでは、モデルとして使用する基本的なクエリをいくつか示します。

Basic、Standard、Premium レベルでのクエリ

• 指定された IP アドレス範囲内の 1 時間あたりの Azure Cache for Redis クライアント接続:

let IpRange = "10.1.1.0/24";
ACRConnectedClientList
// For particular datetime filtering, add '| where TimeGenerated between (StartTime .. EndTime)'
| where ipv4_is_in_range(ClientIp, IpRange)
| summarize ConnectionCount = sum(ClientCount) by TimeRange = bin(TimeGenerated, 1h)

• キャッシュに接続している一意の Redis クライアント IP アドレス:

ACRConnectedClientList
| summarize count() by ClientIp

Enterprise および Enterprise Flash レベルでのクエリ

• 指定された IP アドレス範囲内の 1 時間あたりの Azure Cache for Redis 接続数:

REDConnectionEvents
// For particular datetime filtering, add '| where EventTime between (StartTime .. EndTime)'
// For particular IP range filtering, add '| where ipv4_is_in_range(ClientIp, IpRange)'
// IP range can be defined like this 'let IpRange = "10.1.1.0/24";' at the top of query.
| extend EventTime = unixtime_seconds_todatetime(EventEpochTime)
| where EventType == "new_conn"
| summarize ConnectionCount = count() by TimeRange = bin(EventTime, 1h)

• 指定された IP アドレス範囲内の 1 時間あたりの Azure Cache for Redis 認証要求数:

REDConnectionEvents
| extend EventTime = unixtime_seconds_todatetime(EventEpochTime)
// For particular datetime filtering, add '| where EventTime between (StartTime .. EndTime)'
// For particular IP range filtering, add '| where ipv4_is_in_range(ClientIp, IpRange)'
// IP range can be defined like this 'let IpRange = "10.1.1.0/24";' at the top of query.
| where EventType == "auth"
| summarize AuthenticationRequestsCount = count() by TimeRange = bin(EventTime, 1h)

• キャッシュに接続している一意の Redis クライアント IP アドレス:

REDConnectionEvents
// https://docs.redis.com/latest/rs/security/audit-events/#status-result-codes
// EventStatus :
// 0    AUTHENTICATION_FAILED    -    Invalid username and/or password.
// 1    AUTHENTICATION_FAILED_TOO_LONG    -    Username or password are too long.
// 2    AUTHENTICATION_NOT_REQUIRED    -    Client tried to authenticate, but authentication isn’t necessary.
// 3    AUTHENTICATION_DIRECTORY_PENDING    -    Attempting to receive authentication info from the directory in async mode.
// 4    AUTHENTICATION_DIRECTORY_ERROR    -    Authentication attempt failed because there was a directory connection error.
// 5    AUTHENTICATION_SYNCER_IN_PROGRESS    -    Syncer SASL handshake. Return SASL response and wait for the next request.
// 6    AUTHENTICATION_SYNCER_FAILED    -    Syncer SASL handshake. Returned SASL response and closed the connection.
// 7    AUTHENTICATION_SYNCER_OK    -    Syncer authenticated. Returned SASL response.
// 8    AUTHENTICATION_OK    -    Client successfully authenticated.
| where EventType == "auth" and EventStatus == 2 or EventStatus == 8 or EventStatus == 7
| summarize count() by ClientIp

• キャッシュに対する認証試行の失敗

REDConnectionEvents
// https://docs.redis.com/latest/rs/security/audit-events/#status-result-codes
// EventStatus : 
// 0    AUTHENTICATION_FAILED    -    Invalid username and/or password.
// 1    AUTHENTICATION_FAILED_TOO_LONG    -    Username or password are too long.
// 2    AUTHENTICATION_NOT_REQUIRED    -    Client tried to authenticate, but authentication isn’t necessary.
// 3    AUTHENTICATION_DIRECTORY_PENDING    -    Attempting to receive authentication info from the directory in async mode.
// 4    AUTHENTICATION_DIRECTORY_ERROR    -    Authentication attempt failed because there was a directory connection error.
// 5    AUTHENTICATION_SYNCER_IN_PROGRESS    -    Syncer SASL handshake. Return SASL response and wait for the next request.
// 6    AUTHENTICATION_SYNCER_FAILED    -    Syncer SASL handshake. Returned SASL response and closed the connection.
// 7    AUTHENTICATION_SYNCER_OK    -    Syncer authenticated. Returned SASL response.
// 8    AUTHENTICATION_OK    -    Client successfully authenticated.
| where EventType == "auth" and EventStatus != 2 and EventStatus != 8 and EventStatus != 7
| project ClientIp, EventStatus, ConnectionId

警告

Azure Monitor のアラートにより、監視データで特定の状態が見つかったときに事前に通知を受け取ります。 アラートにより、ユーザーが気付く前に、管理者が問題を識別して対処できます。 詳細については、Azure Monitor アラートに関するページを参照してください。

Azure リソースに関する一般的なアラートのソースは数多くあります。 Azure リソースに関する一般的なアラートの例については、ログ アラート クエリのサンプルに関するページをご覧ください。 Azure Monitor ベースライン アラート (AMBA) サイトには、重要なプラットフォーム メトリック アラート、ダッシュボード、ガイドラインを実装するための半自動化された方法が用意されています。 このサイトは、Azure ランディング ゾーン (ALZ) の一部であるすべてのサービスを含む、Azure サービスの継続的に拡張されるサブセットに適用されます。

共通アラート スキーマを使用すると、Azure Monitor のアラート通知の使用を標準化できます。 詳細については、「共通アラート スキーマ」をご覧ください。

アラートの種類

Azure Monitor データ プラットフォームでは、任意のメトリックまたはログ データ ソースに対してアラートを生成できます。 監視するサービスと収集する監視データに応じて、さまざまな種類のアラートがあります。 アラートの種類に応じて、さまざまな利点と欠点があります。 詳細については、適切な種類の監視アラートの選択に関するページをご覧ください。

次の一覧では、作成できる Azure Monitor アラートの種類について説明します。

• メトリック アラートでは、リソース メトリックを定期的に評価します。 メトリックはプラットフォーム メトリック、カスタム メトリック、メトリックに変換された Azure Monitor からのログまたは Application Insights メトリックにすることができます。 メトリック警告では、複数の条件と動的しきい値を適用することもできます。
• ログ アラートでは、ユーザーは Log Analytics クエリを使用して、定義済みの頻度でリソース ログを評価できます。
• アクティビティ ログ アラートは、定義された条件と一致する新しいアクティビティ ログ イベントが発生したときにトリガーされます。 Resource Health アラートと Service Health アラートは、サービスとリソースの正常性を報告するアクティビティ ログ アラートです。

一部の Azure サービスでは、スマート検出アラート、Prometheus アラート、推奨されるアラート ルールもサポートされています。

一部のサービスでは、同じ Azure リージョン内に存在する同じ種類の複数のリソースに同じメトリック警告ルールを適用することで、大規模に監視することができます。 監視対象リソースごとに個別の通知が送信されます。 サポートされている Azure サービスとクラウドについては、「1 つのアラート ルールで複数のリソースを監視する」をご覧ください。

アラートを作成する

メトリックとアクティビティ ログに基づいてアラートを受け取るように設定できます。 Azure Monitor では、アラートがトリガーされたときに次の処理を実行するように構成することができます。

• 電子メール通知を送信する
• Webhook を呼び出す
• Azure Logic App を呼び出す

キャッシュのアラートを構成するには、[リソース] メニューの [監視] で [アラート] を選択します。

Azure Cache for Redis の一般的なアラート ルール

Azure Cache for Redis の一般的で推奨されるアラート ルールを次の表に示します。

アラートの種類	条件	説明
メトリック	待機時間の 99 パーセンタイル値	Azure Cache for Redis インスタンスでのサーバー側コマンドの最悪の場合の待機時間に対してアラートを発行します。 待機時間は、PING コマンドを使用して応答時間を追跡することによって測定されます。 キャッシュ インスタンスの正常性を追跡して、実行時間の長いコマンドが待機時間のパフォーマンスを低下させるかどうかを確認します。
メトリック	高い Server Load 使用率またはスパイク	高いサーバー負荷とは、Redis サーバーが要求に遅れずに対応することができずにタイムアウトになるか、応答が遅くなることを意味します。 潜在的な影響について早期に通知するために、サーバーの負荷などのメトリックに関するアラートを作成します。
メトリック	高いネットワーク帯域幅使用率	サーバーで使用可能な帯域幅を超過すると、データがすぐにはクライアントに送信されません。 サーバーが十分な速さでデータをクライアントにプッシュできないため、クライアント要求はタイムアウトする可能性があります。 Cache Read カウンターと Cache Write カウンターを使用して、サーバー側のネットワーク帯域幅制限に対するアラートをセットアップします。

Advisor の推奨事項

一部のサービスでは、リソースの操作中にクリティカルな条件や差し迫った変更が発生した場合は、ポータルのサービス [概要] ページにアラートが表示されます。 アラートの詳細と推奨される修正は、左側のメニューの [監視] の下の [アドバイザーのレコメンデーション] に表示されます。 通常の操作中、アドバイザーのレコメンデーションは表示されません。

Azure Advisor の詳細については、Azure Advisor の概要に関するページをご覧ください。

次のスクリーンショットは、Azure Cache for Redis のアラートに対する Advisor の推奨事項を示しています。

キャッシュをアップグレードするには、 [今すぐアップグレード] を選択して、価格レベルを変更し、キャッシュのスケーリングを行います。 価格レベルの選択の詳細については、「適切なサービス レベルを選択する」を参照してください。

関連するコンテンツ

• Azure Cache for Redis 用に作成されたメトリック、ログ、およびその他の重要な値のリファレンスについては、「Azure Cache for Redis 監視データ リファレンス」を参照してください。
• Azure リソースの監視に関する一般的な詳細情報については、「Azure Monitor を使用した Azure リソースの監視」を参照してください。