Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Überwachung der Nutzung mit CloudWatch Metrics
ElastiCache bietet Metriken, mit denen Sie Ihre Cluster überwachen können. Sie können auf diese Metriken zugreifen über CloudWatch. Weitere Informationen zu CloudWatch finden Sie in der [CloudWatch Dokumentation.](https://aws.amazon.com/documentation/cloudwatch/)
ElastiCache bietet sowohl Metriken auf Host-Ebene (z. B. CPU-Auslastung) als auch Metriken, die für die Cache-Engine-Software spezifisch sind (z. B. Cache-Abrufe und Cache-Fehlschläge). Diese Metriken werden für jeden Cache-Knoten in 60-Sekunden-Intervallen gemessen und veröffentlicht.
**Wichtig**
Sie sollten erwägen, CloudWatch Alarme für bestimmte wichtige Messwerte einzurichten, damit Sie benachrichtigt werden, wenn sich die Leistung Ihres Clusters zu verschlechtern beginnt. Weitere Informationen finden Sie unter [Welche Metriken sollte ich überwachen?](CacheMetrics.WhichShouldIMonitor.md) in diesem Handbuch.
**Topics**
+ [Metriken auf Host-Ebene](CacheMetrics.HostLevel.md)
+ [Metriken für Valkey und Redis OSS](CacheMetrics.Redis.md)
+ [Metriken für Memcached](CacheMetrics.Memcached.md)
+ [Welche Metriken sollte ich überwachen?](CacheMetrics.WhichShouldIMonitor.md)
+ [Auswählen von Metrikstatistiken und -zeiträumen](CacheMetrics.ChoosingStatisticsAndPeriods.md)
+ [Überwachung von CloudWatch Cluster- und Knotenmetriken](CloudWatchMetrics.md)
# Metriken auf Host-Ebene
Der `AWS/ElastiCache`-Namespace enthält die folgenden Metriken auf Host-Ebene für einzelne Cache-Knoten. Diese Metriken werden für jeden Cache-Knoten in 60-Sekunden-Intervallen erfasst und veröffentlicht.
**Weitere Informationen finden Sie auch unter:**
+ [Metriken für Valkey und Redis OSS](CacheMetrics.Redis.md)
| Metrik | Beschreibung | Einheit |
| --- | --- | --- |
| CPUUtilization | Der Prozentsatz der CPU-Nutzung für den gesamten Host. Da Valkey und Redis OSS Single-Threading verwenden, empfehlen wir Ihnen, die EngineCPUUtilization Metrik für Knoten mit 4 oder mehr v zu überwachen. CPUs | Prozent |
| CPUCreditBalance | Die Anzahl verdienter CPU-Guthaben, die eine Instance angesammelt hat, seit sie gestartet wurde. Bei T2 Standard beinhaltet der CPUCredit Saldo auch die Anzahl der angesammelten Startguthaben. Guthaben werden auf dem Guthaben-Konto angesammelt, nachdem sie verdient wurden, und davon entfernt, wenn sie verbraucht werden. Der Guthaben-Kontostand hat ein maximales Limit, das anhand der Instance-Größe bestimmt wird. Nachdem das Limit erreicht ist, verfallen alle neu verdienten Guthabenpunkte. Für T2 Standard zählen Startguthaben nicht zum Limit. Die Guthaben im CPUCredit Saldo stehen der Instance zur Verfügung, um die CPU-Grundauslastung zu überschreiten. Die Metriken für CPU-Guthaben sind nur mit einer fünfminütigen Frequenz verfügbar. Diese Metrik ist nicht für T2-Instances mit Spitzenleistung verfügbar. | Guthaben (vCPU-Minuten) |
| CPUCreditUsage | Die Anzahl der von der Instance für die CPU-Nutzung verbrauchten CPU-Guthaben. Ein CPU-Guthaben entspricht einer vCPU, die eine Minute lang bei 100% Auslastung läuft, oder einer äquivalenten Kombination aus vCPUs, Auslastung und Zeit (z. B. eine vCPU, die zwei Minuten lang bei 50% Auslastung läuft, oder zwei v, die zwei Minuten lang bei 25% Auslastung CPUs laufen). Die Metriken für CPU-Guthaben sind nur mit einer fünfminütigen Frequenz verfügbar. Wenn Sie einen Zeitraum von mehr als fünf Minuten angeben, verwenden Sie die Summen-Statistik anstelle der Durchschnitts-Statistik. Diese Metrik ist nicht für T2-Instances mit Spitzenleistung verfügbar. | Guthaben (vCPU-Minuten) |
| FreeableMemory | Größe des freien Arbeitsspeichers auf dem Host. Dies ist von RAM, Puffern und Cache abgeleitet, die vom Betriebssystem als freigebbar eingestuft werden. | Bytes |
| NetworkBytesIn | Anzahl der Byte, die der Host aus dem Netzwerk gelesen hat. | Bytes |
| NetworkBytesOut | Anzahl der von der Instance auf allen Netzwerkschnittstellen gesendeten Byte. | Bytes |
| NetworkPacketsIn | Anzahl der von der Instance auf allen Netzwerkschnittstellen empfangenen Pakete. Diese Metrik gibt das an eine einzelne Instance eingehende Netzwerkdatenvolumen an, ausgedrückt in Anzahl an Paketen. | Anzahl |
| NetworkPacketsOut | Anzahl der von der Instance auf allen Netzwerkschnittstellen gesendeten Pakete. Diese Metrik gibt das von einer einzelnen Instance ausgehende Netzwerkdatenvolumen an, ausgedrückt in Anzahl an Paketen. | Anzahl |
| NetworkBandwidthInAllowanceExceeded | Die Anzahl der Pakete, die in die Warteschlange gestellt oder verworfen wurden, da die eingehende aggregierte Bandbreite das Maximum für die Instance überschritten hat. | Anzahl |
| NetworkConntrackAllowanceExceeded | Die Anzahl der verworfenen Pakete, weil die Verbindungsverfolgung das Maximum für die Instance überschritten hat und keine neuen Verbindungen hergestellt werden konnten. Dies kann zu einem Paketverlust für den Datenverkehr zur oder von der Instance führen. | Anzahl |
| NetworkBandwidthOutAllowanceExceeded | Die Anzahl der Pakete, die in die Warteschlange gestellt oder verworfen wurden, weil die ausgehende aggregierte Bandbreite das Maximum für die Instance überschritten hat. | Anzahl |
| NetworkPacketsPerSecondAllowanceExceeded | Die Anzahl der Pakete, die in Warteschlangen gestellt oder verworfen wurden, weil Anzahl der bidirektionalen Pakete pro Sekunde das Maximum für die Instance überschritten hat. | Anzahl |
| NetworkMaxBytesIn | Die maximale Anzahl an empfangenen Bytes pro Sekunde pro Sekunde pro Minute. | Bytes |
| NetworkMaxBytesOut | Die maximale Anzahl an übertragenen Byte pro Sekunde pro Sekunde pro Minute. | Bytes |
| NetworkMaxPacketsIn | Die maximale Anzahl pro Sekunde empfangener Pakete pro Sekunde pro Minute. | Anzahl |
| NetworkMaxPacketsOut | Die maximale Anzahl an übertragenen Paketen pro Sekunde pro Sekunde pro Minute. | Anzahl |
| SwapUsage | Größe des belegten Auslagerungsspeichers auf dem Host. | Bytes |
# Metriken für Valkey und Redis OSS
Der `Amazon ElastiCache` Namespace umfasst die folgenden Valkey- und Redis-OSS-Metriken. Diese Metriken sind identisch, wenn die Valkey-Engine verwendet wird.
Mit Ausnahme von`ReplicationLag`, `EngineCPUUtilization` `SuccessfulWriteRequestLatency``SuccessfulReadRequestLatency`, und werden diese Metriken aus dem **info** Befehl abgeleitet. Jede Metrik wird zu jeder Cache-Knotenebene berechnet.
Eine vollständige Dokumentation des **info** Befehls finden Sie unter [http://valkey. io/commands/info](https://valkey.io/commands/info).
**Weitere Informationen finden Sie auch unter:**
+ [Metriken auf Host-Ebene](CacheMetrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/CacheMetrics.Redis.html)
**CPUUtilization Verfügbarkeit der Engine**
AWS Die unten aufgeführten Regionen sind für alle unterstützten Knotentypen verfügbar.
| Region | Name der Region |
| --- | --- |
| us-east-2 | US East (Ohio) |
| us-east-1 | USA Ost (Nord-Virginia) |
| us-west-1 | USA West (Nordkalifornien) |
| us-west-2 | USA West (Oregon) |
| ap-northeast-1 | Asien-Pazifik (Tokio) |
| ap-northeast-2 | Asien-Pazifik (Seoul) |
| ap-northeast-3 | Asien-Pazifik (Osaka) |
| ap-east-1 | Asien-Pazifik (Hongkong) |
| ap-south-1 | Asien-Pazifik (Mumbai) |
| ap-southeast-1 | Asien-Pazifik (Singapur) |
| ap-southeast-2 | Asien-Pazifik (Sydney) |
| ap-southeast-3 | Asien-Pazifik (Jakarta) |
| ca-central-1 | Kanada (Zentral) |
| cn-north-1 | China (Peking) |
| cn-northwest-2 | China (Ningxia) |
| me-south-1 | Naher Osten (Bahrain) |
| eu-central-1 | Europe (Frankfurt) |
| eu-west-1 | Europa (Irland) |
| eu-west-2 | Europa (London) |
| eu-west-3 | EU (Paris) |
| eu-south-1 | Europa (Milan) |
| af-south-1 | Afrika (Kapstadt) |
| eu-north-1 | Europa (Stockholm) |
| sa-east-1 | Südamerika (São Paulo) |
| us-gov-west-1 | AWS GovCloud (US-West) |
| us-gov-east-1 | AWS GovCloud (US-Ost) |
Im Folgenden finden Sie Zusammenfassungen bestimmter Befehle, die von **info commandstats** abgeleitet sind. Der Abschnitt „commandstats“ (Befehlsstatistiken) bietet Statistiken auf der Grundlage des Befehlstyps, einschließlich der Anzahl der Aufrufe, des gesamten durch diese Befehle verursachten CPU-Zeitaufwands und des durchschnittlichen CPU-Verbrauchs pro Befehlsausführung. Für jeden Befehlstyp wird die folgende Zeile hinzugefügt: `cmdstat_XXX: calls=XXX,usec=XXX,usec_per_call=XXX`.
[Die unten aufgeführten Latenzmetriken werden anhand der Commandstats-Statistik von INFO berechnet.](https://valkey.io/commands/info) Diese werden auf folgende Weise berechnet: `delta(usec)/delta(calls)`. `delta` wird als Differenz innerhalb einer Minute berechnet. Die Latenz ist definiert als die CPU-Zeit, die für die Verarbeitung des ElastiCache Befehls benötigt wird. Beachten Sie, dass für Cluster, die Daten-Tiering verwenden, die zum Abrufen von Elementen vom SSD benötigte Zeit in diesen Messungen nicht enthalten ist.
Eine vollständige Liste der verfügbaren Befehle finden Sie in der Valkey-Dokumentation unter [Befehle](https://valkey.io/commands).
| Metrik | Description | Einheit |
| --- | --- | --- |
| ClusterBasedCmds | Die Gesamtanzahl der Cluster-basierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die auf einen Cluster einwirken (cluster slotcluster info, usw.). | Anzahl |
| ClusterBasedCmdsLatency | Latenz von Cluster-basierten Befehlen. | Mikrosekunden |
| EvalBasedCmds | Die Gesamtzahl der Befehle für EVAL-basierte Befehle. Dies wird aus der commandstats Statistik durch Summieren von, abgeleitet. eval evalsha | Anzahl |
| EvalBasedCmdsLatency | Latenz von eval-basierten Befehlen. | Mikrosekunden |
| GeoSpatialBasedCmds | Die Gesamtzahl der Befehle für raumbezogene Befehle. Dies wird aus der commandstats Statistik abgeleitet. Es wird abgeleitet, indem alle Befehle des Geo-Typs summiert werden:geoadd, geodist, geohash, geopos, georadius und georadiusbymember. | Anzahl |
| GeoSpatialBasedCmdsLatency | Latenz von raumbezogenen Befehlen. | Mikrosekunden |
| GetTypeCmds | Gesamtanzahl der auf read-only basierenden Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle read-only Typbefehle (get,, hget scardlrange, usw.) summiert werden. | Anzahl |
| GetTypeCmdsLatency | Latenz von Lesebefehlen. | Mikrosekunden |
| HashBasedCmds | Gesamtanzahl der Hash-basierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die auf einen oder mehrere Hashes (hget,, hkeys hvalshdel, usw.) einwirken. | Anzahl |
| HashBasedCmdsLatency | Latenz von Hash-basierten Befehlen. | Mikrosekunden |
| HyperLogLogBasedCmds | Gesamtanzahl der auf HyperLogLog basierenden Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehlstypen (pfadd, pfcountpfmerge, usw.) summiert werden. pf | Anzahl |
| HyperLogLogBasedCmdsLatency | Latenz von HyperLogLog basierten Befehlen. | Mikrosekunden |
| JsonBasedCmds | Die Gesamtzahl der JSON-Befehle, einschließlich Lese- und Schreibbefehlen. Dies wird aus der commandstats Statistik abgeleitet, indem alle JSON-Befehle summiert werden, die sich auf JSON-Schlüssel beziehen. | Anzahl |
| JsonBasedCmdsLatency | Die Latenz der JSON-Befehle, einschließlich Lese- und Schreibbefehlen. | Mikrosekunden |
| JsonBasedGetCmds | Gesamtanzahl der JASON-Schreibschutzbefehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle JSON-Lesebefehle summiert werden, die sich auf JSON-Schlüssel auswirken. | Anzahl |
| JsonBasedGetCmdsLatency | Latenz der JSON-Schreibschutzbefehle. | Mikrosekunden |
| JsonBasedSetCmds | Gesamtanzahl der JASON-Schreibbefehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle JSON-Schreibbefehle summiert werden, die sich auf JSON-Schlüssel auswirken. | Anzahl |
| JsonBasedSetCmdsLatency | Latenz von JSON-Schreibbefehlen. | Mikrosekunden |
| KeyBasedCmds | Gesamtanzahl der schlüsselbasierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die auf einen oder mehrere Schlüssel in mehreren Datenstrukturen (del, expirerename, usw.) einwirken. | Anzahl |
| KeyBasedCmdsLatency | Latenz von schlüsselbasierten Befehlen. | Mikrosekunden |
| ListBasedCmds | Gesamtanzahl der listenbasierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die sich auf eine oder mehrere Listen auswirken (lindex,, lrange lpushltrim, usw.). | Anzahl |
| ListBasedCmdsLatency | Latenz von listenbasierten Befehlen. | Mikrosekunden |
| NonKeyTypeCmds | Gesamtanzahl der nicht schlüsselbasierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die sich nicht auf eine Taste auswirken, z. B., oder. acl dbsize info | Anzahl |
| NonKeyTypeCmdsLatency | Latenz der Befehle. non-key-based | Mikrosekunden |
| PubSubBasedCmds | Die Gesamtzahl der Befehle für die pub/sub Funktionalität. Dies wird aus den commandstats Statistiken abgeleitet, indem alle für die pub/sub Funktionalität verwendeten Befehle summiert werden: psubscribepublish,pubsub,punsubscribe,ssubscribe,sunsubscribe, spublishsubscribe, undunsubscribe. | Anzahl |
| PubSubBasedCmdsLatency | Latenz von pub/sub-basierten Befehlen. | Mikrosekunden |
| SetBasedCmds | Gesamtanzahl der Set-basierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die sich auf einen oder mehrere Sätze auswirken (scard,sdiff, saddsunion, usw.). | Anzahl |
| SetBasedCmdsLatency | Latenz von Set-basierten Befehlen. | Mikrosekunden |
| SetTypeCmds | Gesamtanzahl der auf write basierenden Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle mutative Befehlstypen summiert werden, die mit Daten arbeiten (set,hset, saddlpop, usw.) | Anzahl |
| SetTypeCmdsLatency | Latenz von Schreibbefehlen. | Mikrosekunden |
| SortedSetBasedCmds | Gesamtanzahl der Sorted Set-basierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die sich auf eine oder mehrere sortierte Sätze (zcount,, zrange zrankzadd, usw.) auswirken. | Anzahl |
| SortedSetBasedCmdsLatency | Latenz von Sortierungs-basierten Befehlen. | Mikrosekunden |
| StringBasedCmds | Gesamtanzahl der Zeichenfolge-basierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die sich auf eine oder mehrere Zeichenketten (strlen, setexsetrange, usw.) auswirken. | Anzahl |
| StringBasedCmdsLatency | Latenz von Zeichenfolgen-basierten Befehlen. | Mikrosekunden |
| StreamBasedCmds | Die Gesamtanzahl Stream-basierter Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die sich auf einen oder mehrere Stream-Datentypen (xrange,, xlen xaddxdel, usw.) auswirken. | Anzahl |
| StreamBasedCmdsLatency | Latenz von Stream-basierten Befehlen. | Mikrosekunden |
| SearchBasedCmds | Die Gesamtzahl der Suchbefehle, einschließlich Lese- und Schreibbefehlen. Dies wird aus der Commandstats-Statistik abgeleitet, indem alle Suchbefehle summiert werden. | Anzahl |
| SearchBasedCmdsLatency | Latenz aller Suchbefehle, einschließlich Lese- und Schreibbefehlen. | Mikrosekunden |
| SearchBasedGetCmds | Die Gesamtzahl der schreibgeschützten Suchbefehle. Dies wird aus der Commandstats-Statistik abgeleitet, indem alle Lesebefehle von Search summiert werden. | Anzahl |
| SearchBasedGetCmdsLatency | Latenz der schreibgeschützten Search-Befehle. | Mikrosekunden |
| SearchBasedSetCmds | Die Gesamtzahl der Such-Schreibbefehle. Dies wird aus der Commandstats-Statistik abgeleitet, indem alle Search-Schreibbefehle summiert werden. | Anzahl |
| SearchBasedSetCmdsLatency | Latenz der Such-Schreibbefehle. | Mikrosekunden |
# Metriken für Memcached
Der `AWS/ElastiCache`-Namespace enthält die folgenden Memcache-Metriken.
Der ElastiCache Namespace AWS/enthält die folgenden Metriken, die vom Befehl Memcached stats abgeleitet sind. Jede Metrik wird zu jeder Cache-Knotenebene berechnet.
**Informationen finden Sie auch unter:**
+ [Metriken auf Host-Ebene](CacheMetrics.HostLevel.md)
| Metrik | Beschreibung | Einheit |
| --- | --- | --- |
| BytesReadIntoMemcached | Anzahl der Byte, die vom Cache-Knoten aus dem Netzwerk gelesen wurden. | Bytes |
| BytesUsedForCacheItems | Anzahl der Byte, die zum Speichern von Cache-Elementen verwendet werden. | Bytes |
| BytesWrittenOutFromMemcached | Anzahl der Byte, die vom Cache-Knoten in das Netzwerk geschrieben wurden. | Bytes |
| CasBadval | Anzahl der CAS-Anforderungen (check and set), die vom Cache empfangen wurden, bei denen der CAS-Wert nicht mit dem gespeicherten CAS-Wert übereinstimmt. | Anzahl |
| CasHits | Anzahl der CAS-Anforderungen, die vom Cache empfangen wurden, bei denen der angeforderte Schlüssel gefunden wurde und die CAS-Werte übereinstimmen. | Anzahl |
| CasMisses | Anzahl der CAS-Anforderungen, die vom Cache empfangen wurden, bei denen der angeforderte Schlüssel nicht gefunden wurde. | Anzahl |
| CmdFlush | Anzahl der flush-Befehle, die der Cache erhalten hat. | Anzahl |
| CmdGet | Die Anzahl der get-Befehle, die der Cache erhalten hat. | Anzahl |
| CmdSet | Die Anzahl der Set-Befehle, die der Cache empfangen hat. | Anzahl |
| CurrConnections | Zählt die Anzahl der Verbindungen, die zu einem bestimmten Zeitpunkt mit dem Cache verbunden sind. ElastiCache verwendet 2 bis 3 der Verbindungen zur Überwachung des Clusters. Zusätzlich zu den oben genannten erstellt memcached eine Anzahl von internen Verbindungen, die dem Doppelten der für den Knotentyp verwendeten Threads entsprechen. Die Thread-Anzahl für die verschiedenen Knotentypen ist in `Nodetype Specific Parameters` der entsprechenden Parametergruppe zu sehen. Die Gesamtzahl der Verbindungen ist die Summe der Clientverbindungen, der zu überwachenden Verbindungen und der oben genannten internen Verbindungen. | Anzahl |
| CurrItems | Die Anzahl der zu einem bestimmten Zeitpunkt mit dem Cache verbundenen Verbindungen. | Anzahl |
| DecrHits | Die Anzahl der Dekrementierungsanforderungen, die vom Cache empfangen wurden und bei denen der angeforderte Schlüssel gefunden wurde. | Anzahl |
| DecrMisses | Die Anzahl der Dekrementierungsanforderungen, die vom Cache empfangen wurden und bei denen der angeforderte Schlüssel nicht gefunden wurde. | Anzahl |
| DeleteHits | Die Anzahl der Löschanforderungen, die vom Cache empfangen wurden und bei denen der angeforderte Schlüssel gefunden wurde. | Anzahl |
| DeleteMisses | Die Anzahl der Löschanforderungen, die vom Cache empfangen wurden und bei denen der angeforderte Schlüssel nicht gefunden wurde. | Anzahl |
| Evictions | Die Anzahl nicht abgelaufener Elemente, die vom Cache bereinigt wurden, um Platz für neue Schreibvorgänge zu schaffen. | Anzahl |
| GetHits | Die Anzahl der get-Anforderungen, die vom Cache empfangen wurden und bei denen der angeforderte Schlüssel gefunden wurde. | Anzahl |
| GetMisses | Anzahl der get-Anforderungen, die vom Cache empfangen wurden und bei denen der angeforderte Schlüssel nicht gefunden wurde. | Anzahl |
| IncrHits | Die Anzahl der Inkrementierungsanforderungen, die vom Cache empfangen wurden und bei denen der angeforderte Schlüssel nicht gefunden wurde. | Anzahl |
| IncrMisses | Die Anzahl der Inkrementierungsanforderungen, die vom Cache empfangen wurden und bei denen der angeforderte Schlüssel nicht gefunden wurde. | Anzahl |
| Reclaimed | Die Anzahl abgelaufener Elemente, die vom Cache bereinigt wurden, um Platz für neue Schreibvorgänge zu schaffen. | Anzahl |
Für Memcached 1.4.14 stehen die folgenden zusätzlichen Metriken zur Verfügung.
| Metrik | Beschreibung | Einheit |
| --- | --- | --- |
| BytesUsedForHash | Die Anzahl der Byte, die derzeit von Hash-Tabellen verwendet werden. | Bytes |
| CmdConfigGet | Die kumulative Anzahl an config get-Anforderungen. | Anzahl |
| CmdConfigSet | Die kumulative Anzahl an config set-Anforderungen. | Anzahl |
| CmdTouch | Die kumulative Anzahl an touch-Anforderungen. | Anzahl |
| CurrConfig | Die aktuelle Anzahl gespeicherter Konfigurationen. | Anzahl |
| EvictedUnfetched | Die Anzahl der aus dem LRU-Cache (Last Recently Used, "am längsten nicht verwendeten") entfernten gültigen Elemente, auf die nie zugegriffen wurde, nachdem sie festgelegt worden waren. | Anzahl |
| ExpiredUnfetched | Die Anzahl der aus dem LRU-Cache wiedergewonnenen abgelaufenen Elemente, auf die nie zugegriffen wurde, nachdem sie festgelegt worden waren. | Anzahl |
| SlabsMoved | Die Gesamtanzahl der Slab Pages, die verschoben worden sind. | Anzahl |
| TouchHits | Die Anzahl der Schlüssel, auf die zugegriffen wurde und die mit einer neuen Ablaufzeit versehen wurden. | Anzahl |
| TouchMisses | Die Anzahl der Elemente, auf die zwar zugegriffen wurde, die aber nicht gefunden werden konnten. | Anzahl |
Der ElastiCache Namespace AWS/enthält die folgenden berechneten Metriken auf Cache-Ebene.
| Metrik | Beschreibung | Einheit |
| --- | --- | --- |
| NewConnections | Die Anzahl der neuen Verbindungen, die der Cache erhalten hat. Dies wird von der memcached-Statistik total\$1connections abgeleitet, indem die Änderung in total\$1connections über einen bestimmten Zeitraum aufgezeichnet wird. Dieser Wert wird immer mindestens 1 sein, da eine Verbindung für a reserviert ist. ElastiCache | Anzahl |
| NewItems | Die Anzahl der neuen Elemente, die im Cache gespeichert wurden. Dies wird von der memcached-Statistik total\$1items abgeleitet, indem die Änderung in total\$1items über einen bestimmten Zeitraum aufgezeichnet wird. | Anzahl |
| UnusedMemory | Die Größe des nicht von Daten belegten Speichers. Dies wird von den Memcached-Statistiken limit\$1maxbytes und bytes abgeleitet, indem bytes von limit\$1maxbytes subtrahiert werden. Da der Memcached-Overhead zusätzlich zu dem für Daten verwendeten Speicher belegt, UnusedMemory sollte dieser Wert nicht als die Menge an Speicher angesehen werden, die für zusätzliche Daten zur Verfügung steht. Möglicherweise treten Bereinigungen auch dann auf, wenn noch etwas ungenutzter Speicherplatz vorhanden ist. Detailliertere Informationen erhalten Sie unter [Memcached item memory usage](https://web.archive.org/web/20190422040715/https://www.deplication.net/2016/02/memcached-item-memory-usage/). | Bytes |
# Welche Metriken sollte ich überwachen?
Die folgenden CloudWatch Kennzahlen bieten einen guten Einblick in die ElastiCache Leistung. In den meisten Fällen empfehlen wir, CloudWatch Alarme für diese Kennzahlen einzurichten, damit Sie Korrekturmaßnahmen ergreifen können, bevor Leistungsprobleme auftreten.
**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [Modul CPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage (Valkey und Redis OSS)](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [Speicher (Valkey und Redis OSS)](#metrics-memory)
+ [Netzwerk](#metrics-network)
+ [Latenz](#metrics-latency)
+ [Replikation](#metrics-replication)
+ [Verkehrsmanagement (Valkey und Redis OSS)](#traffic-management)
## CPUUtilization
Diese Metrik auf Hostebene wird in Prozent angegeben. Weitere Informationen finden Sie unter [Metriken auf Host-Ebene](CacheMetrics.HostLevel.md).
**Valkey und Redis OSS**
Verwenden Sie bei kleineren Knotentypen mit 2 V CPUs oder weniger die `CPUUtilization ` Metrik, um Ihre Arbeitslast zu überwachen.
Generell empfehlen wir, den Schwellenwert auf 90 % der verfügbaren CPU-Kapazität festzulegen. Da Valkey und Redis OSS beide Single-Threading verwenden, sollte der tatsächliche Schwellenwert als Bruchteil der Gesamtkapazität des Knotens berechnet werden. Angenommen, Sie verwenden einen Knotentyp mit zwei Kernen. In diesem Fall CPUUtilization wäre der Schwellenwert für 90/2 oder 45%.
Sie müssen eigene Grenzwerte basierend auf der Anzahl der Kerne im verwendeten Cache-Knoten festlegen. Wenn Sie diesen Schwellenwert überschreiten und Ihre Hauptlast aus Leseanfragen besteht, skalieren Sie Ihren Cluster, indem Sie Read Replicas hinzufügen. Wenn der Workload hauptsächlich aus Schreibanfragen stammt, empfehlen wir Ihnen abhängig von Ihrer Cluster-Konfiguration:
+ **Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert):** Skalieren Sie, indem Sie einen größeren Cache-Instance-Typ verwenden.
+ **Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert):** Fügen Sie weitere Shards hinzu, um die Schreiblast auf mehr Primärknoten zu verteilen.
**Tipp**
Anstatt die Metrik auf Host-Ebene zu verwenden`CPUUtilization`, können Valkey- und Redis OSS-Benutzer möglicherweise die Metrik verwenden`EngineCPUUtilization`, die den Prozentsatz der Nutzung auf dem Valkey- oder Redis OSS-Engine-Kern angibt. Um zu sehen, ob diese Metrik auf Ihren Knoten verfügbar ist, und weitere Informationen finden Sie unter [Metriken](CacheMetrics.Redis.md) für Valkey und Redis OSS.
Für größere Knotentypen mit 4 V CPUs oder mehr können Sie die `EngineCPUUtilization` Metrik verwenden, die den Prozentsatz der Nutzung auf dem Valkey- oder Redis OSS-Engine-Kern angibt. Um zu sehen, ob diese Metrik auf Ihren Knoten verfügbar ist, und weitere Informationen finden Sie unter [Metriken für](CacheMetrics.Redis.md) Redis OSS.
**Memcached**
Da Memcached mit mehreren Threads arbeitet, darf diese Metrik bis zu 90 % erreichen. Wenn Sie diesen Schwellenwert überschreiten, skalieren Sie Ihren Cluster, indem Sie einen größeren Cache-Knotentyp verwenden, oder skalieren Sie ihn, indem Sie weitere Cache-Knoten hinzufügen.
## Modul CPUUtilization
Für größere Knotentypen mit 4 V CPUs oder mehr möchten Sie möglicherweise die `EngineCPUUtilization` Metrik verwenden, die den Prozentsatz der Nutzung auf dem Kern der Redis OSS-Engine angibt. Um zu sehen, ob diese Metrik auf Ihren Knoten verfügbar ist, und weitere Informationen finden Sie unter [Metriken für Valkey und](CacheMetrics.Redis.md) Redis OSS.
Weitere Informationen finden Sie im **CPUs**Abschnitt [Bewährte Methoden zur Überwachung von Amazon ElastiCache für Redis OSS mithilfe von Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/).
## SwapUsage (Valkey und Redis OSS)
Diese Metrik auf Hostebene wird in Bytes angegeben. Weitere Informationen finden Sie unter [Metriken auf Host-Ebene](CacheMetrics.HostLevel.md).
Liegt die `FreeableMemory` CloudWatch Metrik nahe 0 (d. h. unter 100 MB) oder ist sie größer als die `SwapUsage` `FreeableMemory` Metrik, deutet dies darauf hin, dass ein Knoten unter Speicherauslastung steht. Beachten Sie in diesem Fall folgende Themen
+ [Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen](BestPractices.BGSAVE.md)
+ [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md)
## Evictions
Dies ist eine Metrik für die Cache-Engine. Wir empfehlen Ihnen, einen eigenen Grenzwert für diese Metrik basierend auf den Anforderungen Ihrer Anwendung zu bestimmen.
Wenn Sie Memcached verwenden und den von Ihnen gewählten Schwellenwert überschreiten, skalieren Sie Ihren Cluster, indem Sie einen größeren Knotentyp verwenden, oder skalieren Sie, indem Sie weitere Knoten hinzufügen.
## CurrConnections
Dies ist eine Metrik für die Cache-Engine. Wir empfehlen Ihnen, einen eigenen Grenzwert für diese Metrik basierend auf den Anforderungen Ihrer Anwendung zu bestimmen.
Eine zunehmende Anzahl von *CurrConnections*kann auf ein Problem mit Ihrer Anwendung hinweisen. Um dieses Problem zu beheben, müssen Sie das Verhalten der Anwendung untersuchen.
Weitere Informationen finden Sie im Abschnitt **Verbindungen** unter [Bewährte Methoden zur Überwachung von Amazon ElastiCache für Redis OSS mithilfe von Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/).
## Speicher (Valkey und Redis OSS)
Speicher ist ein Kernaspekt von Valkey und Redis OSS. Es ist notwendig, die Speicherauslastung Ihres Clusters zu verstehen, um Datenverluste zu vermeiden und das zukünftige Wachstum Ihres Datasets berücksichtigen zu können. Statistiken über die Speicherauslastung eines Knotens sind im Speicherbereich des [INFO-Befehls](https://valkey.io/commands/info) verfügbar.
Weitere Informationen finden Sie im Abschnitt **Speicher** unter [Bewährte Methoden zur Überwachung mit Amazon ElastiCache für Redis OSS mithilfe von Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/).
## Netzwerk
Einer der entscheidenden Faktoren für die Kapazität der Netzwerkbandbreite Ihres Clusters ist der von Ihnen ausgewählte Knotentyp. Weitere Informationen zur Netzwerkkapazität Ihres Nodes finden Sie unter [ ElastiCache Amazon-Preise](https://aws.amazon.com/elasticache/pricing/).
Weitere Informationen finden Sie im Abschnitt **Netzwerk** unter [Bewährte Methoden zur Überwachung von Amazon ElastiCache für Redis OSS mithilfe von Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/).
## Latenz
Die Messung der Antwortzeit für eine ElastiCache for Valkey-Instance kann je nach erforderlicher Granularität auf unterschiedliche Weise erfolgen. Die wichtigsten Phasen, die zur gesamten serverseitigen Reaktionszeit von ElastiCache for Valkey beitragen, sind die Befehlsvorverarbeitung, Befehlsausführung und Befehlsnachverarbeitung.
Befehlsspezifische Latenzmetriken, die aus dem Befehl Valkey [INFO](https://valkey.io/commands/info) abgeleitet wurden, wie GetTypeCmdsLatency z. B. SetTypeCmdsLatency Metriken, konzentrieren sich speziell auf die Ausführung der zentralen Befehlslogik für den Befehl Valkey. Diese Metriken sind hilfreich, wenn Sie in Ihrem Anwendungsfall die Ausführungszeit von Befehlen oder die aggregierten Latenzen pro Datenstruktur bestimmen möchten.
Die Latenzmetriken `SuccessfulWriteRequestLatency` und `SuccessfulReadRequestLatency` messen die Gesamtzeit, die die ElastiCache for Valkey-Engine benötigt, um auf eine Anfrage zu antworten.
**Anmerkung**
Überhöhte Werte für `SuccessfulWriteRequestLatency` und `SuccessfulReadRequestLatency` Metriken können auftreten, wenn Valkey-Pipelining verwendet wird und CLIENT REPLY auf dem Valkey-Client aktiviert ist. Valkey-Pipelining ist eine Technik zur Leistungssteigerung, indem mehrere Befehle gleichzeitig ausgegeben werden, ohne auf die Antwort auf jeden einzelnen Befehl warten zu müssen. [Um überhöhte Werte zu vermeiden, empfehlen wir, Ihren Valkey-Client so zu konfigurieren, dass er Befehle weiterleitet, wenn CLIENT REPLY OFF ist.](https://valkey.io/commands/client-reply/)
Weitere Informationen finden Sie im Abschnitt **Latenz** unter [Bewährte Methoden zur Überwachung mit Amazon ElastiCache mithilfe von Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/).
## Replikation
Das Datenvolumen, das repliziert wird, ist über die `ReplicationBytes`-Metrik ersehbar. Obwohl diese Metrik für die Schreiblast der Replikationsgruppe repräsentativ ist, gibt sie keine Einblicke in den Replikationsstatus. Für diesem Zweck können Sie die `ReplicationLag`-Metrik verwenden.
Weitere Informationen finden Sie im Abschnitt **Replikation** unter [Bewährte Methoden zur Überwachung von Amazon ElastiCache für Redis OSS mithilfe von Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/).
## Verkehrsmanagement (Valkey und Redis OSS)
ElastiCache für Redis OSS verwaltet OSS automatisch den Datenverkehr für einen Knoten, wenn mehr eingehende Befehle an den Knoten gesendet werden, als von Valkey oder Redis OSS verarbeitet werden können. Dies geschieht, um den optimalen Betrieb und die Stabilität der Engine aufrechtzuerhalten.
Wenn der Datenverkehr auf einem Knoten aktiv verwaltet wird, gibt die Metrik `TrafficManagementActive` den Datenpunkt 1 aus. Dies weist darauf hin, dass der Knoten für den bereitgestellten Workload möglicherweise unterskaliert ist. Wenn diese Metrik über einen längeren Zeitraum 1 bleibt, evaluieren Sie den Cluster, um zu entscheiden, ob eine Hoch- oder Aufskalierung erforderlich ist.
Sehen Sie sich die Metrik `TrafficManagementActive` auf der Seite [Metriken](CacheMetrics.Redis.md) an, um mehr zu erfahren.
# Auswählen von Metrikstatistiken und -zeiträumen
CloudWatch Sie können zwar eine beliebige Statistik und einen beliebigen Zeitraum für jede Metrik auswählen, aber nicht alle Kombinationen sind nützlich. Beispielsweise CPUUtilization sind die Statistiken „Durchschnitt“, „Minimum“ und „Maximum“ nützlich, die Summenstatistik jedoch nicht.
Alle ElastiCache Samples werden für einen Zeitraum von 60 Sekunden für jeden einzelnen Cache-Knoten veröffentlicht. Eine Metrik für einen Cache-Knoten enthält für einen 60-Sekunden-Zeitraum immer nur eine Stichprobe.
Weitere Informationen zum Abrufen von Metriken für Cache-Knoten finden Sie unter [Überwachung von CloudWatch Cluster- und Knotenmetriken](CloudWatchMetrics.md).
# Überwachung von CloudWatch Cluster- und Knotenmetriken
ElastiCache und CloudWatch sind integriert, sodass Sie eine Vielzahl von Metriken sammeln können. Sie können diese Metriken überwachen mit CloudWatch.
**Anmerkung**
Für die folgenden Beispiele sind die CloudWatch Befehlszeilentools erforderlich. Weitere Informationen zu den Entwicklertools CloudWatch und zum Herunterladen finden Sie auf der [ CloudWatch Produktseite](https://aws.amazon.com/cloudwatch).
Die folgenden Verfahren zeigen Ihnen, wie Sie Speicherplatzstatistiken für einen Cluster für die letzte Stunde sammeln können. CloudWatch
**Anmerkung**
Die Werte für `StartTime` und `EndTime` in diesen Beispielen unten dienen nur zur Veranschaulichung. Sie müssen die entsprechenden Werte für den Start- und Endzeitpunkt Ihrer Cache-Knoten einsetzen.
Informationen zu ElastiCache Grenzwerten finden Sie unter [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_elasticache) für ElastiCache.
## Überwachung von CloudWatch Cluster- und Knotenmetriken (Konsole)
**So erfassen Sie CPU-Nutzungsstatistiken für einen Cache-Cluster**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie die Cache-Knoten aus, für die Sie Metriken anzeigen möchten.
**Anmerkung**
Bei der Auswahl von mehr als 20 Knoten wird die Ansicht von Metriken auf der Konsole deaktiviert.
1. Klicken Sie auf der Seite **Cache-Cluster** der AWS Management Console auf den Namen eines oder mehrerer Cluster.
Die Detailseite für den Cluster wird angezeigt.
1. Klicken Sie oben im Fenster auf die Registerkarte **Nodes**.
1. Wählen Sie auf der Registerkarte **Nodes** des Detailfensters die Cache-Knoten aus, für die Sie Metriken anzeigen möchten.
Eine Liste der verfügbaren CloudWatch Metriken wird unten im Konsolenfenster angezeigt.
1. Klicken Sie auf die Metrik **CPU Utilization**.
Die CloudWatch Konsole wird geöffnet und zeigt Ihre ausgewählten Metriken an. Sie können die Dropdown-Listenfelder **Statistic** und **Period** und die Registerkarte **Time Range** verwenden, um die angezeigten Metriken zu ändern.
## Überwachen von CloudWatch Cluster- und Knotenmetriken mit der CloudWatch CLI
**So erfassen Sie CPU-Nutzungsstatistiken für einen Cache-Cluster**
+ Für Linux, macOS oder 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
```
Für 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
```
## Überwachung von CloudWatch Cluster- und Knotenmetriken mithilfe der CloudWatch API
**So erfassen Sie CPU-Nutzungsstatistiken für einen Cache-Cluster**
+ Rufen Sie die CloudWatch API `GetMetricStatistics` mit den folgenden Parametern auf (beachten Sie, dass die Start- und Endzeiten nur als Beispiele angezeigt werden; Sie müssen Ihre eigenen entsprechenden Start- und Endzeiten ersetzen):
+ `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=
```