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.
# MemoryDB mit Amazon überwachen CloudWatch
Sie können MemoryDB mithilfe von CloudWatch MemoryDB überwachen. Dabei werden Rohdaten gesammelt und zu lesbaren Metriken verarbeitet, die nahezu in Echtzeit verfügbar sind. Diese Statistiken werden 15 Monate gespeichert, damit Sie auf Verlaufsinformationen zugreifen können und einen besseren Überblick darüber erhalten, wie Ihre Webanwendung oder der Service ausgeführt werden. Sie können auch Alarme einrichten, die auf bestimmte Grenzwerte achten und Benachrichtigungen senden oder Aktivitäten auslösen, wenn diese Grenzwerte erreicht werden. Weitere Informationen finden Sie im [ CloudWatch Amazon-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
In den folgenden Abschnitten sind die Metriken und Dimensionen für MemoryDB aufgeführt.
**Topics**
+ [
# Metriken auf Host-Ebene
](metrics.HostLevel.md)
+ [
# Metriken für MemoryDB
](metrics.memorydb.md)
+ [
# Welche Metriken sollte ich überwachen?
](metrics.whichshouldimonitor.md)
+ [
# Auswählen von Metrikstatistiken und -zeiträumen
](metrics.ChoosingStatisticsAndPeriods.md)
+ [
# CloudWatch Metriken überwachen
](cloudwatchmetrics.md)
# Metriken auf Host-Ebene
Der `AWS/MemoryDB` Namespace umfasst die folgenden Metriken auf Host-Ebene für einzelne Knoten.
**Weitere Informationen finden Sie auch unter:**
+ [Metriken für MemoryDB](metrics.memorydb.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 |
| FreeableMemory | Größe des freien Arbeitsspeichers auf dem Host. Diese Zahl wird aus dem Arbeitsspeicher und den Puffern abgeleitet, die das Betriebssystem als frei verfügbar meldet. | 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 wurde geformt, weil die eingehende aggregierte Bandbreite das Maximum für die Instance überschritten hat. | Anzahl |
| NetworkConntrackAllowanceExceeded | Die Anzahl der Pakete wurde geformt, 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 wurde geformt, weil die ausgehende aggregierte Bandbreite das Maximum für die Instance überschritten hat. | Anzahl |
| NetworkPacketsPerSecondAllowanceExceeded | Die Anzahl der Pakete, die geformt wurden, weil Anzahl der bidirektionalen Pakete pro Sekunde das Maximum für die Instance überschritten hat. | Anzahl |
| NetworkMaxBytesIn | Die maximale Anzahl an empfangenen Byte 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 an empfangenen Paketen pro Sekunde 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 MemoryDB
Der `AWS/MemoryDB`-Namespace enthält die folgenden Metriken.
Mit Ausnahme von`ReplicationLag`, `EngineCPUUtilization` `SuccessfulWriteRequestLatency``SuccessfulReadRequestLatency`, und werden diese Metriken aus den OSS-Befehlen Valkey und Redis abgeleitet. **info** Jede Metrik wird auf Knotenebene berechnet.
Eine vollständige Dokumentation des **INFO** Befehls finden Sie unter [INFO](http://valkey.io/commands/info).
**Weitere Informationen finden Sie auch unter:**
+ [Metriken auf Host-Ebene](metrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/memorydb/latest/devguide/metrics.memorydb.html)
Im Folgenden finden Sie Zusammenfassungen bestimmter Befehle, die von **info commandstats** abgeleitet sind. Der Abschnitt commandstats enthält Statistiken, die auf dem Befehlstyp basieren, einschließlich der Anzahl der Aufrufe.
Eine vollständige Liste der verfügbaren Befehle finden Sie unter [Befehle](https://valkey.io/commands).
| Metrik | Beschreibung | Einheit |
| --- | --- | --- |
| EvalBasedCmds | Die Gesamtzahl der Befehle für EVAL-basierte Befehle. Dies wird aus der commandstats Statistik durch Summierung eval und abgeleitet. evalsha | Anzahl |
| 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 |
| 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 |
| 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 |
| HyperLogLogBasedCmds | Gesamtanzahl der auf HyperLogLog basierenden Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehlstypen (pfadd, pfcountpfmerge, usw.) summiert werden. pf | Anzahl |
| JsonBasedCmds | Die Gesamtanzahl der JSON-basierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die sich auf ein oder mehrere JSON-Dokumentobjekte auswirken. | Anzahl |
| KeyBasedCmds | Gesamtanzahl der schlüsselbasierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die sich auf einen oder mehrere Schlüssel in mehreren Datenstrukturen auswirken (del, expirerename, usw.). | Anzahl |
| 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 |
| PubSubBasedCmds | Die Gesamtzahl der Befehle für pub/sub die Funktionalität. Dies wird aus den commandstats Statistiken abgeleitet, indem alle für die pub/sub Funktionalität verwendeten Befehle summiert werden:psubscribe,publish,pubsub, punsubscribesubscribe, undunsubscribe. | Anzahl |
| SearchBasedCmds | Die Gesamtzahl der sekundären Index- und Suchbefehle, einschließlich Lese- und Schreibbefehlen. Dies wird aus der commandstats Statistik abgeleitet, indem alle Suchbefehle summiert werden, die sich auf sekundäre Indizes auswirken. | Anzahl |
| SearchBasedGetCmds | Gesamtzahl der Befehle für den sekundären Index und die schreibgeschützte Suche. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle für sekundäre Indizes und Suchabfragen summiert werden. | Anzahl |
| SearchBasedSetCmds | Gesamtzahl der sekundären Index- und Suchbefehle zum Schreiben. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle für den sekundären Index und die Suchgruppe summiert werden. | Anzahl |
| SearchNumberOfIndexes | Gesamtzahl der Indizes. | Anzahl |
| SearchNumberOfIndexedKeys | Gesamtzahl der indizierten Schlüssel | Anzahl |
| SearchTotalIndexSize | Speicher (Byte), der von allen Indizes verwendet wird. | Bytes |
| SetBasedCmds | Gesamtanzahl der Set-basierten Befehle. Dies wird aus der commandstats Statistik abgeleitet, indem alle Befehle summiert werden, die auf einen oder mehrere Sätze (scard,, sdiff saddsunion, usw.) einwirken. | Anzahl |
| 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 |
| 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 |
| 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 |
| 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 |
# Welche Metriken sollte ich überwachen?
Die folgenden CloudWatch Metriken bieten einen guten Einblick in die Leistung von MemoryDB. In den meisten Fällen empfehlen wir, CloudWatch Alarme für diese Metriken einzurichten, damit Sie Korrekturmaßnahmen ergreifen können, bevor Leistungsprobleme auftreten.
**Topics**
+ [
## CPUUtilization
](#metrics-cpu-utilization)
+ [
## Motor CPUUtilization
](#metrics-engine-cpu-utilization)
+ [
## SwapUsage
](#metrics-swap-usage)
+ [
## Evictions
](#metrics-evictions)
+ [
## CurrConnections
](#metrics-curr-connections)
+ [
## Arbeitsspeicher
](#metrics-memory)
+ [
## Netzwerk
](#metrics-network)
+ [
## Latency
](#metrics-latency)
+ [
## Replikation
](#metrics-replication)
## CPUUtilization
Diese Metrik auf Hostebene wird in Prozent angegeben. Weitere Informationen finden Sie unter [Metriken auf Host-Ebene](metrics.HostLevel.md).
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 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%. Informationen zur Anzahl der Kerne (vCPUs) Ihres Knotentyps finden Sie unter [MemoryDB-Preise](https://aws.amazon.com/memorydb/pricing/?p=ps).
Sie müssen Ihren eigenen Schwellenwert festlegen, der auf der Anzahl der Kerne in dem Knoten basiert, den Sie verwenden. Wenn Sie diesen Schwellenwert überschreiten und Ihre Hauptlast aus Leseanfragen besteht, skalieren Sie Ihren Cluster, indem Sie Read Replicas hinzufügen. Wenn die Hauptlast aus Schreibanforderungen besteht, empfehlen wir Ihnen, mehr Shards hinzuzufügen, um die Schreiblast auf mehr Primärknoten zu verteilen.
**Tipp**
Anstatt die Metrik auf Host-Ebene zu verwenden`CPUUtilization`, können Sie möglicherweise die Metrik verwenden`EngineCPUUtilization`, die den Prozentsatz der Nutzung auf dem Valkey- oder Redis-OSS-Engine-Kern meldet. [Um zu sehen, ob diese Metrik auf Ihren Knoten verfügbar ist, und weitere Informationen finden Sie unter Metriken für MemoryDB.](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html)
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](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html) für MemoryDB.
## Motor CPUUtilization
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](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html) für MemoryDB.
## SwapUsage
Diese Metrik auf Hostebene wird in Bytes angegeben. Weitere Informationen finden Sie unter [Metriken auf Host-Ebene](metrics.HostLevel.md).
Wenn entweder die `FreeableMemory` CloudWatch Metrik nahe 0 ist (d. h. unter 100 MB) oder die `SwapUsage` Metrik größer als die `FreeableMemory` Metrik ist, dann könnte ein Knoten unter Speicherdruck stehen.
## Evictions
Dies ist eine Motormetrik. Wir empfehlen Ihnen, einen eigenen Grenzwert für diese Metrik basierend auf den Anforderungen Ihrer Anwendung zu bestimmen.
## CurrConnections
Dies ist eine Motormetrik. 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.
## Arbeitsspeicher
Speicher ist ein Kernaspekt von Valkey und von 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.
## 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 [Amazon MemoryDB-Preise](https://aws.amazon.com/memorydb/pricing/).
## Latency
Die Latenzmetriken `SuccessfulWriteRequestLatency` und `SuccessfulReadRequestLatency` messen die Gesamtzeit, die MemoryDB für die 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 Redis-Client so zu konfigurieren, dass er Befehle weiterleitet, wenn CLIENT REPLY OFF ist.](https://valkey.io/commands/client-reply/)
## Replikation
Das Datenvolumen, das repliziert wird, ist über die `ReplicationBytes`-Metrik ersehbar. Sie können den Durchsatz der Replikationskapazität `MaxReplicationThroughput` anhand der Replikationskapazität überwachen. Es wird empfohlen, weitere Shards hinzuzufügen, wenn der maximale Durchsatz für die Replikationskapazität erreicht ist.
`ReplicationDelayedWriteCommands`kann auch angeben, ob die Arbeitslast den maximalen Durchsatz der Replikationskapazität überschreitet. Weitere Informationen zur Replikation in MemoryDB finden Sie unter [Grundlegendes](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html) zur MemoryDB-Replikation
# Auswählen von Metrikstatistiken und -zeiträumen
Es ermöglicht CloudWatch Ihnen zwar, für jede Metrik eine beliebige Statistik und einen beliebigen Zeitraum auszuwählen, aber nicht alle Kombinationen sind sinnvoll. Beispielsweise CPUUtilization sind die Statistiken Durchschnitt, Minimum und Maximum für nützlich, die Summenstatistik jedoch nicht.
Alle MemoryDB-Samples werden für einen Zeitraum von 60 Sekunden für jeden einzelnen Knoten veröffentlicht. Für jeden Zeitraum von 60 Sekunden enthält eine Knotenmetrik nur eine einzige Stichprobe.
# CloudWatch Metriken überwachen
MemoryDB 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 in den folgenden Beispielen angegebenen `EndTime` Werte `StartTime` und dienen der Veranschaulichung. Stellen Sie sicher, dass Sie Ihre Knoten durch geeignete Start- und Endzeitwerte ersetzen.
Informationen zu MemoryDB-Grenzwerten finden Sie unter [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_memorydb) for MemoryDB.
## Metriken überwachen CloudWatch (Konsole)
**Um Statistiken zur CPU-Auslastung für einen Cluster zu sammeln**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die MemoryDB-Konsole unter. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Wählen Sie die 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 **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 **Knoten** des Detailfensters die 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.
## CloudWatch Metriken mit der CloudWatch CLI überwachen
**Um Statistiken zur CPU-Auslastung für einen Cluster zu sammeln**
+ Verwenden Sie den CloudWatch Befehl **aws cloudwatch get-metric-statistics** mit den folgenden Parametern (beachten Sie, dass die Start- und Endzeiten nur als Beispiele angezeigt werden; Sie müssen Ihre eigenen entsprechenden Start- und Endzeiten ersetzen):
Für Linux, macOS oder Unix:
```
1. aws cloudwatch get-metric-statistics CPUUtilization \
2. --dimensions=ClusterName=mycluster,NodeId=0002" \
3. --statistics=Average \
4. --namespace="AWS/MemoryDB" \
5. --start-time 2013-07-05T00:00:00 \
6. --end-time 2013-07-06T00:00:00 \
7. --period=60
```
Für Windows:
```
1. mon-get-stats CPUUtilization ^
2. --dimensions=ClusterName=mycluster,NodeId=0002" ^
3. --statistics=Average ^
4. --namespace="AWS/MemoryDB" ^
5. --start-time 2013-07-05T00:00:00 ^
6. --end-time 2013-07-06T00:00:00 ^
7. --period=60
```
## Überwachung von CloudWatch Metriken mithilfe der CloudWatch API
**Um Statistiken zur CPU-Auslastung für einen Cluster zu sammeln**
+ 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/MemoryDB`
+ `StartTime``=2013-07-05T00:00:00`
+ `EndTime``=2013-07-06T00:00:00`
+ `Period``=60`
+ `MeasureName``=CPUUtilization`
+ `Dimensions``=ClusterName=mycluster,NodeId=0002`
**Example**
```
1. http://monitoring.amazonaws.com/
2. ?SignatureVersion=4
3. &Action=GetMetricStatistics
4. &Version=2014-12-01
5. &StartTime=2013-07-16T00:00:00
6. &EndTime=2013-07-16T00:02:00
7. &Period=60
8. &Statistics.member.1=Average
9. &Dimensions.member.1="ClusterName=mycluster"
10. &Dimensions.member.2="NodeId=0002"
11. &Namespace=Amazon/memorydb
12. &MeasureName=CPUUtilization
13. &Timestamp=2013-07-07T17%3A48%3A21.746Z
14. &AWS;AccessKeyId=<&AWS; Access Key ID>
15. &Signature=
```