翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# CloudWatch メトリクスの使用状況のモニタリング
ElastiCache には、クラスターを監視できるようにするメトリクスが用意されています。CloudWatch を通じてこれらのメトリクスにアクセスできます。CloudWatch の詳細については、「[CloudWatch のドキュメント](https://aws.amazon.com/documentation/cloudwatch/)」を参照してください。
ElastiCache では、ホストレベルのメトリクス（たとえば、CPU 使用率など）とキャッシュエンジンソフトウェアに固有のメトリクス（たとえば、キャッシュの取得やキャッシュの損失など）の両方が提供されます。これらのメトリクスは 60 秒間隔で各キャッシュノードに対して測定および発行されます。
**重要**
クラスターのパフォーマンスが低下し始めた場合に通知を受け取ることができるように、特定の主要メトリクスに CloudWatch アラームを設定することを検討してください。詳細については、このガイドの「[モニタリングすべきメトリクス](CacheMetrics.WhichShouldIMonitor.md)」を参照してください。
**Topics**
+ [ホストレベルのメトリクス](CacheMetrics.HostLevel.md)
+ [Valkey と Redis OSS のメトリクス](CacheMetrics.Redis.md)
+ [Memcached のメトリクス](CacheMetrics.Memcached.md)
+ [モニタリングすべきメトリクス](CacheMetrics.WhichShouldIMonitor.md)
+ [メトリクスの統計と期間の選択](CacheMetrics.ChoosingStatisticsAndPeriods.md)
+ [CloudWatch クラスターとノードメトリクスのモニタリング](CloudWatchMetrics.md)
# ホストレベルのメトリクス
`AWS/ElastiCache` 名前空間は、各キャッシュノードに対する以下のホストレベルのメトリクスが含まれます。これらのメトリクスは 60 秒間隔で各キャッシュノードに対して測定および発行されます。
**以下の資料も参照してください**
+ [Valkey と Redis OSS のメトリクス](CacheMetrics.Redis.md)
| メトリクス | 説明 | 単位 |
| --- | --- | --- |
| CPUUtilization | ホスト全体の CPU 使用率の割合 (%)。Valkey および Redis OSS はシングルスレットであるため、4 個以上の vCPU を持つノードで EngineCPUUtilization メトリクスをモニタリングすることをお勧めします。 | 割合 (%) |
| CPUCreditBalance | インスタンスが起動または開始後に蓄積した獲得 CPU クレジットの数。T2 スタンダードの場合、CPUCreditBalance には蓄積された起動クレジットの数も含まれます。 クレジットは獲得後にクレジット残高に蓄積され、消費されるとクレジット残高から削除されます。クレジット残高にはインスタンスサイズによって決まる上限があります。制限に到達すると、獲得された新しいクレジットはすべて破棄されます。T2 スタンダードの場合、起動クレジットは制限に対してカウントされません。 CPUCreditBalance のクレジットは、インスタンスがそのベースライン CPU 使用率を超えてバーストするために消費できます。 CPU クレジットメトリクスは、5 分間隔でのみ利用可能です。 このメトリクスは、T2 バーストパフォーマンスインスタンスでは利用できません。 | クレジット (vCPU 分) |
| CPUCreditUsage | CPU 使用率に関してインスタンスで消費される CPU クレジットの数。1 つの CPU クレジットは、1 個の vCPU が 100% の使用率で 1 分間実行されること、または、vCPU、使用率、時間の同等の組み合わせ (例えば、1 個の vCPU が 50% の使用率で 2 分間実行されるか、2 個の vCPU が 25% の使用率で 2 分間実行される) に相当します。 CPU クレジットメトリクスは、5 分間隔でのみ利用可能です。5 分を超える期間を指定する場合は、Average 統計の代わりに Sum 統計を使用します。 このメトリクスは、T2 バーストパフォーマンスインスタンスでは利用できません。 | クレジット (vCPU 分) |
| FreeableMemory | ホストで使用可能な空きメモリの量。OS によって解放できる可能性があるとレポートされる RAM、バッファ、およびキャッシュから算出されます。 | バイト |
| NetworkBytesIn | ホストがネットワークから読み取ったバイト数。 | バイト |
| NetworkBytesOut | すべてのネットワークインターフェイスでの、このインスタンスから送信されたバイトの数。 | バイト |
| NetworkPacketsIn | すべてのネットワークインターフェイスでの、このインスタンスによって受信されたパケットの数。このメトリクスは受信トラフィックのボリュームを単一インスタンスでのパケット数として識別します。 | カウント |
| NetworkPacketsOut | すべてのネットワークインターフェイスでの、このインスタンスから送信されたパケットの数。このメトリクスは送信トラフィックのボリュームを単一インスタンスでのパケット数として識別します。 | カウント |
| NetworkBandwidthInAllowanceExceeded | インバウンド集計帯域幅がインスタンスの最大値を超えたためにキューまたはドロップされたパケットの数。 | カウント |
| NetworkConntrackAllowanceExceeded | 接続トラッキングがインスタンスの最大数を超え、新しい接続を確立できなかったためにドロップされたパケットの数。これにより、インスタンスとの間で送受信されるトラフィックのパケット損失が発生する可能性があります。 | カウント |
| NetworkBandwidthOutAllowanceExceeded | アウトバウンド集計帯域幅がインスタンスの最大値を超えたためにキューまたはドロップされたパケットの数。 | カウント |
| NetworkPacketsPerSecondAllowanceExceeded | 1 秒あたりの双方向パケットがインスタンスの最大値を超えたためにキューまたはドロップされたパケットの数。 | カウント |
| NetworkMaxBytesIn | 1 分間の受信バイトの最大毎秒バースト量。 | バイト |
| NetworkMaxBytesOut | 1 分間の送信バイトの最大毎秒バースト量。 | バイト |
| NetworkMaxPacketsIn | 1 分間の受信パケットの最大毎秒バースト量。 | カウント |
| NetworkMaxPacketsOut | 1 分間の送信パケットの最大毎秒バースト量。 | カウント |
| SwapUsage | ホストで使用されるスワップの量。 | バイト |
# Valkey と Redis OSS のメトリクス
`Amazon ElastiCache` 名前空間には、次の Valkey と Redis OSS のメトリクスが含まれます。これらのメトリクスは、Valkey エンジンを使用する場合も同じです。
`ReplicationLag`、`EngineCPUUtilization`、`SuccessfulWriteRequestLatency`、`SuccessfulReadRequestLatency` を除き、これらのメトリクスは **info** コマンドから算出されます。各メトリクスは、キャッシュノードレベルで算出されます。
**info** コマンドの詳細なドキュメントは、[http://valkey.io/commands/info](https://valkey.io/commands/info) を参照してください。
**以下の資料も参照してください**。
+ [ホストレベルのメトリクス](CacheMetrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/CacheMetrics.Redis.html)
**EngineCPUUtilization の利用可能性**
AWS以下にリストされているリージョンは、サポートされているすべてのノードタイプで使用できます。
| リージョン | リージョン名 |
| --- | --- |
| us-east-2 | 米国東部(オハイオ) |
| us-east-1 | 米国東部 (バージニア北部) |
| us-west-1 | 米国西部 (北カリフォルニア) |
| us-west-2 | 米国西部 (オレゴン) |
| ap-northeast-1 | アジアパシフィック (東京) |
| ap-northeast-2 | アジアパシフィック (ソウル) |
| ap-northeast-3 | アジアパシフィック (大阪) |
| ap-east-1 | アジアパシフィック (香港) |
| ap-south-1 | アジアパシフィック (ムンバイ) |
| ap-southeast-1 | アジアパシフィック (シンガポール) |
| ap-southeast-2 | アジアパシフィック (シドニー) |
| ap-southeast-3 | アジアパシフィック (ジャカルタ) |
| ca-central-1 | カナダ (中部) |
| cn-north-1 | 中国 (北京) |
| cn-northwest-2 | 中国 (寧夏) |
| me-south-1 | 中東 (バーレーン) |
| eu-central-1 | 欧州 (フランクフルト) |
| eu-west-1 | 欧州 (アイルランド) |
| eu-west-2 | 欧州 (ロンドン) |
| eu-west-3 | 欧州 (パリ) |
| eu-south-1 | 欧州 (ミラノ) |
| af-south-1 | アフリカ (ケープタウン) |
| eu-north-1 | 欧州 (ストックホルム) |
| sa-east-1 | 南米 (サンパウロ) |
| us-gov-west-1 | AWS GovCloud (米国西部) |
| us-gov-east-1 | AWS GovCloud (米国東部) |
以下は特定の種類のコマンドの集計で、**info commandstats** から算出されています。commandstats セクションには、コール数、これらのコマンドによって消費された合計 CPU 時間、およびコマンド実行あたりの平均 CPU 消費など、コマンドタイプに基づいた統計情報が表示されます。コマンドタイプごとに、次の行が追加されます: `cmdstat_XXX: calls=XXX,usec=XXX,usec_per_call=XXX`。
以下に示すレイテンシーメトリクスは、[INFO](https://valkey.io/commands/info) からの commandstats 統計を使用して計算されます。それらは次のように計算されます: `delta(usec)/delta(calls)`。`delta` は、1 分以内の差分として計算されます。レイテンシーは、ElastiCache がコマンドを処理するのにかかった CPU 時間として定義されます。データ階層化を使用するクラスターの場合、SSD から項目を取得するのにかかる時間はこれらの測定に含まれないことにご注意ください。
利用可能なコマンドの完全なリストについては、Valkey ドキュメントの「[commands](https://valkey.io/commands)」を参照してください。
| メトリクス | 説明 | Unit |
| --- | --- | --- |
| ClusterBasedCmds | クラスターベースのコマンドの総数。これは、クラスターに対して実行されるすべてのコマンド (cluster slot、cluster info など) を合計することによって commandstats 統計から算出されます。 | カウント |
| ClusterBasedCmdsLatency | クラスターベースのコマンドのレイテンシー。 | マイクロ秒 |
| EvalBasedCmds | eval ベースのコマンドの合計数。これは、eval、evalsha を合計することによって commandstats 統計から算出されます。 | カウント |
| EvalBasedCmdsLatency | Eval ベースのコマンドのレイテンシー。 | マイクロ秒 |
| GeoSpatialBasedCmds | 地理空間ベースのコマンドの総数。これは commandstats 統計から算出されます。これは、すべての geo の種類のコマンド (geoadd、geodist、geohash、geopos、georadius、および georadiusbymember) を合計することによって算出されます。 | カウント |
| GeoSpatialBasedCmdsLatency | 地理空間ベースのコマンドのレイテンシー。 | マイクロ秒 |
| GetTypeCmds | read-only 型のコマンドの合計数。これは、すべての read-only の種類のコマンド (get、hget、scard、lrange など) を合計することによって commandstats 統計から算出されます。 | カウント |
| GetTypeCmdsLatency | 読み取りコマンドのレイテンシー。 | マイクロ秒 |
| HashBasedCmds | ハッシュベースのコマンドの総数。これは、1 つ以上のハッシュに対して実行されるすべてのコマンド (hget、hkeys、hvals、hdel など) を合計することによって commandstats 統計から算出されます。 | カウント |
| HashBasedCmdsLatency | ハッシュベースのコマンドのレイテンシー。 | マイクロ秒 |
| HyperLogLogBasedCmds | HyperLogLog ベースのコマンドの合計数。これは、すべての pf の種類のコマンド (pfadd、pfcount、pfmerge など) を合計することによって commandstats 統計から算出されます。 | カウント |
| HyperLogLogBasedCmdsLatency | HyperLogLogBased コマンドのレイテンシー。 | マイクロ秒 |
| JsonBasedCmds | 読み取りコマンドと書き込みコマンドの両方を含む JSON コマンドの合計数。これは、JSON キーに対して実行されるすべての JSON コマンドを合計することによって commandstats 統計から算出されます。 | カウント |
| JsonBasedCmdsLatency | 読み取りコマンドと書き込みコマンドの両方を含む、すべての JSON コマンドのレイテンシー。 | マイクロ秒 |
| JsonBasedGetCmds | JSON 読み取り専用コマンドの合計数。これは、JSON キーに対して実行されるすべての JSON 読み取りコマンドを合計することによって commandstats 統計から算出されます。 | カウント |
| JsonBasedGetCmdsLatency | JSON 読み取り専用コマンドのレイテンシー。 | マイクロ秒 |
| JsonBasedSetCmds | JSON 書き込みコマンドの合計数。これは、JSON キーに対して実行されるすべての JSON 書き込みコマンドを合計することによって commandstats 統計から算出されます。 | カウント |
| JsonBasedSetCmdsLatency | JSON 書き込みコマンドのレイテンシー。 | マイクロ秒 |
| KeyBasedCmds | キーベースのコマンドの総数。これは、複数のデータ構造で 1 つ以上のキーに対して実行されるすべてのコマンド (del、expire、rename など) を合計することによって、commandstats 統計から算出されます。 | カウント |
| KeyBasedCmdsLatency | キーベースのコマンドのレイテンシー。 | マイクロ秒 |
| ListBasedCmds | リストベースのコマンドの総数。これは、1 つ以上のリストに対して実行されるすべてのコマンド (lindex、lrange、lpush、ltrim など) を合計することによって commandstats 統計から算出されます。 | カウント |
| ListBasedCmdsLatency | リストベースのコマンドのレイテンシー。 | マイクロ秒 |
| NonKeyTypeCmds | キーベースではないコマンドの合計数。これは、キーに対して実行されないすべてのコマンド (acl、dbsize、info など) を合計することによって commandstats 統計から算出されます。 | カウント |
| NonKeyTypeCmdsLatency | キーベースではないのコマンドのレイテンシー。 | マイクロ秒 |
| PubSubBasedCmds | pub/sub 機能のコマンドの総数。これは、pub/sub 機能で使用されるすべてのコマンド (psubscribe、publish、pubsub、punsubscribe、ssubscribe、sunsubscribe、spublish、subscribe、unsubscribe) を合計することによって commandstats 統計から算出されます。 | カウント |
| PubSubBasedCmdsLatency | PubSubBased コマンドのレイテンシー。 | マイクロ秒 |
| SetBasedCmds | セットベースのコマンドの総数。これは、1 つ以上のセットに対して実行されるすべてのコマンド (scard、sdiff、sadd、sunion など) を合計することによって commandstats 統計から算出されます。 | カウント |
| SetBasedCmdsLatency | セットベースのコマンドのレイテンシー。 | マイクロ秒 |
| SetTypeCmds | write 型のコマンドの合計数。これは、データ上で動作する mutative の種類のすべてのコマンド (set、hset、sadd、lpop など) を合計することによって commandstats 統計から算出されます。 | カウント |
| SetTypeCmdsLatency | 書き込みコマンドのレイテンシー。 | マイクロ秒 |
| SortedSetBasedCmds | ソートされたセットベースのコマンドの総数。これは、1 つ以上のソートされたセットに対して実行されるすべてのコマンド (zcount、zrange、zrank、zadd など) を合計することによって commandstats 統計から算出されます。 | カウント |
| SortedSetBasedCmdsLatency | ソートベースのコマンドのレイテンシー。 | マイクロ秒 |
| StringBasedCmds | 文字列ベースのコマンドの総数。これは、1 つ以上の文字列に対して実行されるすべてのコマンド (strlen、setex、setrange など) を合計することによって commandstats 統計から算出されます。 | カウント |
| StringBasedCmdsLatency | 文字列ベースのコマンドのレイテンシー。 | マイクロ秒 |
| StreamBasedCmds | ストリームベースのコマンドの総数。これは、1 つ以上のストリームデータの種類に対して実行されるすべてのコマンド (xrange、xlen、xadd、xdel など) を合計することによって commandstats 統計から算出されます。 | カウント |
| StreamBasedCmdsLatency | ストリームベースのコマンドのレイテンシー。 | マイクロ秒 |
| SearchBasedCmds | 読み取りコマンドと書き込みコマンドの両方を含む、検索コマンドの総数。これは、すべての検索コマンドを合計することによって commandstats 統計から算出されます。 | カウント |
| SearchBasedCmdsLatency | 読み取りコマンドと書き込みコマンドの両方を含む、すべての検索コマンドのレイテンシー。 | マイクロ秒 |
| SearchBasedGetCmds | 検索読み取り専用コマンドの総数。これは、すべての検索読み取りコマンドを合計することによって commandstats 統計から算出されます。 | カウント |
| SearchBasedGetCmdsLatency | 検索読み取り専用コマンドのレイテンシー。 | マイクロ秒 |
| SearchBasedSetCmds | 検索書き込みコマンドの総数。これは、すべての検索書き込みコマンドを合計することによって commandstats 統計から算出されます。 | カウント |
| SearchBasedSetCmdsLatency | 検索書き込みコマンドのレイテンシー。 | マイクロ秒 |
# Memcached のメトリクス
`AWS/ElastiCache` 名前空間には、次の Memcached メトリクスが含まれています。
AWS/ElastiCache 名前空間には、Memcached stats コマンドから派生した次のメトリクスが含まれています。各メトリクスは、キャッシュノードレベルで算出されます。
**関連情報**
+ [ホストレベルのメトリクス](CacheMetrics.HostLevel.md)
| メトリクス | 説明 | 単位 |
| --- | --- | --- |
| BytesReadIntoMemcached | キャッシュノードによってネットワークから読み取られたバイト数。 | バイト |
| BytesUsedForCacheItems | キャッシュ項目の格納に使用したバイト数。 | バイト |
| BytesWrittenOutFromMemcached | キャッシュノードによってネットワークに書き込まれたバイト数。 | バイト |
| CasBadval | キャッシュが受信したが、その Cas (チェックと設定) 値と格納されている Cas 値が一致しない CAS リクエストの数。 | カウント |
| CasHits | キャッシュが受信し、リクエストされたキーが見つかって Cas 値が一致した Cas リクエストの数。 | カウント |
| CasMisses | キャッシュが受信したが、リクエストされたキーが見つからない Cas リクエストの数。 | カウント |
| CmdFlush | キャッシュが受信した flush コマンドの数。 | カウント |
| CmdGet | キャッシュが受信した get コマンドの数。 | カウント |
| CmdSet | キャッシュが受信した set コマンドの数。 | カウント |
| CurrConnections | 特定の時点でキャッシュに接続された接続回数。ElastiCache は、2～3 の接続を使用してクラスターをモニタリングします。 上記に加えて、memcached は、ノードタイプに使用されているスレッドの 2 倍に等しい数の内部接続を作成します。ノードタイプ別のスレッド数は、該当するパラメータグループの `Nodetype Specific Parameters` で確認できます。 合計接続数は、クライアント接続、モニタリング用の接続、および上記の内部接続の合計数です。 | カウント |
| CurrItems | キャッシュに現在格納されている項目の数。 | カウント |
| DecrHits | キャッシュが受信し、リクエストされたキーが見つかったデクリメントリクエストの数。 | カウント |
| DecrMisses | キャッシュが受信したが、リクエストされたキーが見つからなかったデクリメントリクエストの数。 | カウント |
| DeleteHits | キャッシュが受信し、リクエストされたキーが見つかった削除リクエストの数。 | カウント |
| DeleteMisses | キャッシュが受信したが、リクエストされたキーが見つからなかった削除リクエストの数。 | カウント |
| Evictions | 新しく書き込むための領域を確保するためにキャッシュが排除した、期限切れではない項目の数。 | カウント |
| GetHits | キャッシュが受信し、リクエストされたキーが見つかった get リクエストの数。 | カウント |
| GetMisses | キャッシュが受信したが、リクエストされたキーが見つからなかった get リクエストの数。 | カウント |
| IncrHits | キャッシュが受信し、リクエストされたキーが見つかったインクリメントリクエストの数。 | カウント |
| IncrMisses | キャッシュが受信したが、リクエストされたキーが見つからなかったインクリメントリクエストの数。 | カウント |
| Reclaimed | 新しく書き込むための領域を確保するためにキャッシュが排除した、期限切れ項目の数。 | カウント |
Memcached 1.4.14 では、次のメトリクスが追加で提供されます。
| メトリクス | 説明 | 単位 |
| --- | --- | --- |
| BytesUsedForHash | ハッシュテーブルで現在使用されているバイト数。 | バイト |
| CmdConfigGet | config get リクエストの累積数。 | カウント |
| CmdConfigSet | config set リクエストの累積数。 | カウント |
| CmdTouch | touch リクエストの累積数。 | カウント |
| CurrConfig | 現在格納されている設定の数。 | カウント |
| EvictedUnfetched | 設定されてからまったくタッチされていない LRU キャッシュから排除された有効な項目の数。 | カウント |
| ExpiredUnfetched | 設定されてからまったくタッチされていない LRU キャッシュから再生された有効期限切れの項目の数。 | カウント |
| SlabsMoved | 移動されたスラブページの合計数。 | カウント |
| TouchHits | タッチされて新しい有効期限を与えられたキーの数。 | カウント |
| TouchMisses | タッチされたが見つからなかった項目の数。 | カウント |
AWS/ElastiCache 名前空間には、以下の計算されたキャッシュレベルのメトリクスが含まれています。
| メトリクス | 説明 | 単位 |
| --- | --- | --- |
| NewConnections | キャッシュが受信した新しい接続の数。この値は、ある期間の変更を total\$1connections に記録することによって memcached total\$1connections 統計から派生したものです。この値は、ElastiCache 用に予約された接続が 1 つあるため、常に 1 以上になります。 | カウント |
| NewItems | キャッシュが格納した新しい項目の数。この値は、ある期間の変更を total\$1items に記録することによって memcached total\$1items 統計から派生したものです。 | カウント |
| UnusedMemory | データに使用されていないメモリの量。この値は、Memcached 統計の limit\$1maxbytes と bytes の間で、limit\$1maxbytes から bytes を引くことによって算出されます。 Memcached はデータに加えてオーバーヘッドにもメモリを使用するため、UnusedMemory を追加データ用のメモリ量と見なしてはなりません。未使用メモリがまだ残っている状態でも削除が発生する場合があります。 詳細については、「[Memcached item memory usage](https://web.archive.org/web/20190422040715/https://www.deplication.net/2016/02/memcached-item-memory-usage/)」を参照してください。 | バイト |
# モニタリングすべきメトリクス
次の CloudWatch メトリクスは、ElastiCache パフォーマンスを把握するのに役立ちます。ほとんどの場合、パフォーマンスの問題が発生する前に修正作業を行うことができるように、これらのメトリクスに CloudWatch アラームを設定することをお勧めします。
**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [EngineCPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage (Valkey および Redis OSS)](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [メモリ (Valkey および Redis OSS)](#metrics-memory)
+ [Network](#metrics-network)
+ [レイテンシー](#metrics-latency)
+ [レプリケーション](#metrics-replication)
+ [トラフィック管理 (Valkey および Redis OSS)](#traffic-management)
## CPUUtilization
パーセント値でレポートされるホストレベルのメトリクスです。詳細については、「[ホストレベルのメトリクス](CacheMetrics.HostLevel.md)」を参照してください。
**Valkey および Redis OSS**
2 個以下の vCPU を持つ小さなノードタイプの場合は、`CPUUtilization ` メトリクスを使用してワークロードをモニタリングします。
一般的に、利用可能な CPU の 90% にしきい値を設定することをお勧めします。Valkey および Redis OSS はどちらもシングルスレッドであるため、実際のしきい値はノードの総容量の一部として計算すべきです。例えば、2 個のコアを搭載するノードタイプを使用しているとします。この場合、CPUUtilization のしきい値は 90/2、つまり 45% になります。
使用しているキャッシュノードのコア数に基づいて独自のしきい値を決定する必要があります。このしきい値を超えた場合で、主なワークロードが読み込みリクエストから生成されている場合、リードレプリカを追加してクラスターをスケールします。主なワークロードが書き込みリクエストからのものである場合、クラスター設定に応じて、以下のことをお勧めします。
+ **Valkey または Redis OSS (クラスターモードが無効) クラスター:** より大きなキャッシュインスタンスタイプを使用してスケールアップします。
+ **Valkey または Redis OSS (クラスターモードが有効) クラスター:** より多くのシャードを追加して、より多くのプライマリノード間で書き込みワークロードを分散します。
**ヒント**
Valkey または Redis OSS ユーザーは、ホストレベルのメトリクス `CPUUtilization` を使用する代わりに、Valkey または Redis OSS エンジンコアでの使用量のパーセント値をレポートするメトリクス `EngineCPUUtilization` を使用できる場合があります。ノードでこのメトリクスが利用できるかどうか、およびその詳細については、「[Valkey と Redis OSS のメトリクス](CacheMetrics.Redis.md)」を参照してください。
4 個以上の vCPU を持つ大きなノードタイプでは、Valkey または Redis OSS エンジンコアでの使用量のパーセント値をレポートする `EngineCPUUtilization` メトリクスを使用することをお勧めします。ノードでこのメトリクスが利用できるかどうか、およびその詳細については、「[Metrics for Redis OSS](CacheMetrics.Redis.md)」を参照してください。
**Memcached**
Memcached はマルチスレッドのため、このメトリクスは約 90% です。このしきい値を超えた場合、より大きいキャッシュノードタイプを使用してクラスターをスケールするか、さらにキャッシュノードを追加してスケールアウトします。
## EngineCPUUtilization
4 個以上の vCPU を持つ大きなノードタイプでは、Redis OSS エンジンコアでの使用量のパーセント値をレポートする `EngineCPUUtilization` メトリクスを使用することをお勧めします。ノードでこのメトリクスが利用できるかどうか、およびその詳細については、「[Valkey と Redis OSS のメトリクス](CacheMetrics.Redis.md)」を参照してください。
詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS によるベストプラクティスのモニタリング](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**CPU**」セクションを参照してください。
## SwapUsage (Valkey および Redis OSS)
バイト単位でレポートされるホストレベルのメトリクスです。詳細については、「[ホストレベルのメトリクス](CacheMetrics.HostLevel.md)」を参照してください。
`FreeableMemory` CloudWatch メトリクスが 0 に近い (つまり 100 MB 未満) または `SwapUsage` メトリクスが `FreeableMemory` メトリクスより大きい場合、ノードがメモリプレッシャーを受けていることを示します。このような場合は、以下のトピックを参照してください。
+ [Valkey または Redis OSS スナップショットを作成するのに十分なメモリがあることを確認する](BestPractices.BGSAVE.md)
+ [Valkey および Redis OSS の予約済みメモリを管理する](redis-memory-management.md)
## Evictions
これは、キャッシュエンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。
Memcached を使用していて、選択したしきい値を超えた場合は、より大きいノードタイプを使用してクラスターをスケールするか、さらにノードを追加してスケールアウトします。
## CurrConnections
これは、キャッシュエンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。
*CurrConnections* の値が大きくなった場合、アプリケーションに問題があることを示している可能性があります。アプリケーション動作を調査してこの問題を解決する必要があります。
詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS によるベストプラクティスのモニタリング](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**接続**」セクションを参照してください。
## メモリ (Valkey および Redis OSS)
メモリは Valkey および Redis OSS の中核的な側面です。クラスターのメモリ使用率を理解することは、データの損失を回避し、データセットの将来の増加に対応するために必要です。ノードのメモリ使用率に関する統計は、[INFO](https://valkey.io/commands/info) コマンドのメモリセクションで確認できます。
詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS によるベストプラクティスのモニタリング](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**メモリ**」セクションを参照してください。
## Network
クラスターのネットワーク帯域幅容量の決定要因の 1 つは、選択したノードの種類です。ノードのネットワーク容量の詳細については、「[Amazon ElastiCache 料金表](https://aws.amazon.com/elasticache/pricing/)」を参照してください。
詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS によるベストプラクティスのモニタリング](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**ネットワーク**」セクションを参照してください。
## レイテンシー
ElastiCache for Valkey インスタンスの応答時間を測定するには、必要な粒度レベルに応じてさまざまな方法があります。ElastiCache for Valkey のサーバー側の応答時間全体に影響する主なステージは、コマンドの前処理、コマンドの実行、およびコマンドの後処理です。
GetTypeCmdsLatency や SetTypeCmdsLatency メトリクスなど、Valkey [INFO](https://valkey.io/commands/info) コマンドから派生したコマンド固有のレイテンシーメトリクスは、Valkey コマンドのコアコマンドロジックの実行に特に重点を置いています。これらのメトリクスは、コマンドの実行時間やデータ構造ごとの合計レイテンシーを決定するユースケースに役立ちます。
レイテンシーメトリクス `SuccessfulWriteRequestLatency` および `SuccessfulReadRequestLatency` は、ElastiCache for Valkey エンジンがリクエストに応答するのにかかる合計時間を測定します。
**注記**
Valkey クライアントで CLIENT REPLY を有効にして Valkey パイプラインを使用すると、`SuccessfulWriteRequestLatency` および `SuccessfulReadRequestLatency` メトリクスの値が異常に大きくなる場合があります。Valkey パイプラインは、個々のコマンドへの応答を待たずに複数のコマンドを一度に実行することでパフォーマンスを向上させる手法です。値が異常に大きくなるのを防ぐために、[CLIENT REPLY OFF](https://valkey.io/commands/client-reply/) の状態でコマンドをパイプラインするように Valkey クライアントを設定することをお勧めします。
詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache のモニタリングのベストプラクティス](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**レイテンシー**」セクションを参照してください。
## レプリケーション
レプリケーションされるデータの量は、`ReplicationBytes` メトリクスを介して見ることができます。このメトリクスは、レプリケーショングループに対する書き込み負荷を表しますが、レプリケーションの状態に関するインサイトは提供されません。この目的のために、`ReplicationLag` メトリクスを使用できます。
詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS によるベストプラクティスのモニタリング](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**レプリケーション**」セクションを参照してください。
## トラフィック管理 (Valkey および Redis OSS)
ElastiCache for Redis OSS は、Valkey または Redis OSS が処理できる数よりも多くのコマンドがノードに送信された場合に、ノードに対するトラフィックを自動的に管理します。これにより、エンジンの最適な動作と安定性を維持します。
ノードでトラフィックがアクティブに管理されている場合、メトリクス `TrafficManagementActive` は 1 のデータポイントを出力します。これは、提供されているワークロードに対してノードが過小評価されている可能性を示します。このメトリクスが長期にわたって 1 を示している場合は、クラスターを評価してスケールアップまたはスケールアウトする必要があるかどうかを判断します。
詳細については、「[メトリクス](CacheMetrics.Redis.md)」ページの `TrafficManagementActive` メトリクスを参照してください。
# メトリクスの統計と期間の選択
CloudWatch では、各メトリクスの統計および期間を選択できますが、すべての組み合わせが役に立つとは言えません。例えば、CPUUtilization の Average、Minimum、および Maximum 統計は役に立ちますが、Sum 統計は役に立ちません。
ElastiCache のすべてのサンプルは、個々のキャッシュノードに対して 60 秒間発行されています。任意の 60 秒間において、キャッシュノードメトリクスに含められるサンプルは 1 つだけです。
キャッシュノードのメトリクスを取得する方法の詳細については、「[CloudWatch クラスターとノードメトリクスのモニタリング](CloudWatchMetrics.md)」を参照してください。
# CloudWatch クラスターとノードメトリクスのモニタリング
ElastiCache と CloudWatch は、多様なメトリクスを収集できるように統合されています。CloudWatch を使用して、これらのメトリクスをモニタリングできます。
**注記**
次の例には、CloudWatch コマンドラインツールが必要です。CloudWatch の詳細とデベロッパーツールのダウンロードについては、「[CloudWatch 製品ページ](https://aws.amazon.com/cloudwatch)」を参照してください。
次の手順は、CloudWatch を使用して、過去 1 時間のクラスターのストレージ領域統計を収集する方法を示しています。
**注記**
以下の例で指定されている `StartTime` 値と `EndTime` 値は、例示を目的としています。実際のキャッシュノードに適した開始時刻値および終了時刻値で置き換える必要があります。
ElastiCache 制限の詳細については、ElastiCache の 「[AWSサービス制限](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_elasticache)」を参照してください。
## CloudWatch クラスターとノードメトリクスのモニタリング（コンソール）
**キャッシュクラスターの CPU 使用率統計を収集するには**
1. にサインインAWS マネジメントコンソールし、[https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/) で ElastiCache コンソールを開きます。
1. メトリクスを表示するキャッシュノードを選択します。
**注記**
20 個を超えるノードを選択すると、コンソールでメトリクスを表示できなくなります。
1. AWSマネジメントコンソールの**キャッシュクラスター**ページで、1 つ以上のクラスターの名前をクリックします。
クラスターの詳細ページが表示されます。
1. ウィンドウ上部にある **Nodes** タブをクリックします。
1. 詳細ウィンドウの [**Nodes**] タブで、メトリクスを表示するキャッシュノードを選択します。
使用可能な CloudWatch メトリクスのリストがコンソールウィンドウの下部に表示されます。
1. **CPU Utilization** メトリクスをクリックします。
CloudWatch コンソールが開き、選択されたメトリクスが表示されます。**Statistic** および **Period** ドロップダウンリストボックスや **Time Range** タブを使用すると、表示されるメトリクスを変更できます。
## CloudWatch CLI を使用した CloudWatch クラスターとノードメトリクスのモニタリング
**キャッシュクラスターの CPU 使用率統計を収集するには**
+ Linux、macOS、Unix の場合:
```
aws cloudwatch get-metric-statistics \
--namespace AWS/ElastiCache \
--metric-name CPUUtilization \
--dimensions='[{"Name":"CacheClusterId","Value":"test"},{"Name":"CacheNodeId","Value":"0001"}]' \
--statistics=Average \
--start-time 2018-07-05T00:00:00 \
--end-time 2018-07-06T00:00:00 \
--period=3600
```
Windows の場合:
```
aws cloudwatch get-metric-statistics ^
--namespace AWS/ElastiCache ^
--metric-name CPUUtilization ^
--dimensions='[{"Name":"CacheClusterId","Value":"test"},{"Name":"CacheNodeId","Value":"0001"}]' ^
--statistics=Average ^
--start-time 2018-07-05T00:00:00 ^
--end-time 2018-07-06T00:00:00 ^
--period=3600
```
## CloudWatch API を使用した CloudWatch クラスターとノードメトリックスのモニタリング
**キャッシュクラスターの CPU 使用率統計を収集するには**
+ 以下のパラメータを指定して、CloudWatch API `GetMetricStatistics` を呼び出します（示されている開始時刻と終了時刻は例です。適切な開始時刻と終了時刻に置き換える必要があります）。
+ `Statistics.member.1``=Average`
+ `Namespace``=AWS/ElastiCache`
+ `StartTime``=2013-07-05T00:00:00`
+ `EndTime``=2013-07-06T00:00:00`
+ `Period``=60`
+ `MeasureName``=CPUUtilization`
+ `Dimensions``=CacheClusterId=mycachecluster,CacheNodeId=0002`
**Example**
```
1. http://monitoring.amazonaws.com/
2. ?Action=GetMetricStatistics
3. &SignatureVersion=4
4. &Version=2014-12-01
5. &StartTime=2018-07-05T00:00:00
6. &EndTime=2018-07-06T23:59:00
7. &Period=3600
8. &Statistics.member.1=Average
9. &Dimensions.member.1="CacheClusterId=mycachecluster"
10. &Dimensions.member.2="CacheNodeId=0002"
11. &Namespace=&AWS;/ElastiCache
12. &MeasureName=CPUUtilization
13. &Timestamp=2018-07-07T17%3A48%3A21.746Z
14. &AWS;AccessKeyId=<&AWS; Access Key ID>
15. &Signature=
```