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.
# Protokollierung und Überwachung
Die Überwachung ist ein wichtiger Bestandteil der Aufrechterhaltung der Zuverlässigkeit, Verfügbarkeit und Leistung von MemoryDB und Ihren anderen AWS Lösungen. AWS bietet die folgenden Überwachungstools, um MemoryDB zu überwachen, zu melden, wenn etwas nicht stimmt, und gegebenenfalls automatische Maßnahmen zu ergreifen:
+ *Amazon CloudWatch* überwacht Ihre AWS Ressourcen und die Anwendungen, auf denen Sie laufen, AWS in Echtzeit. Sie können Kennzahlen erfassen und verfolgen, benutzerdefinierte Dashboards erstellen und Alarme festlegen, die Sie benachrichtigen oder Maßnahmen ergreifen, wenn eine bestimmte Metrik einen von Ihnen festgelegten Schwellenwert erreicht. Sie können beispielsweise die CPU-Auslastung oder andere Kennzahlen Ihrer EC2 Amazon-Instances CloudWatch verfolgen und bei Bedarf automatisch neue Instances starten. Weitere Informationen finden Sie im [ CloudWatch Amazon-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ Mit *Amazon CloudWatch Logs* können Sie Ihre Protokolldateien von EC2 Amazon-Instances und anderen Quellen überwachen CloudTrail, speichern und darauf zugreifen. CloudWatch Logs kann Informationen in den Protokolldateien überwachen und Sie benachrichtigen, wenn bestimmte Schwellenwerte erreicht werden. Sie können Ihre Protokolldaten auch in einem sehr robusten Speicher archivieren. Weitere Informationen finden Sie im [Amazon CloudWatch Logs-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).
+ *AWS CloudTrail*erfasst API-Aufrufe und zugehörige Ereignisse, die von oder im Namen Ihres AWS Kontos getätigt wurden, und übermittelt die Protokolldateien an einen von Ihnen angegebenen Amazon S3 S3-Bucket. Sie können feststellen, welche Benutzer und Konten angerufen wurden AWS, von welcher Quell-IP-Adresse aus die Anrufe getätigt wurden und wann die Aufrufe erfolgten. Weitere Informationen finden Sie im [AWS CloudTrail -Benutzerhandbuch](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
# 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=
```
# Überwachung von MemoryDB-Ereignissen
Wenn für einen Cluster wichtige Ereignisse eintreten, sendet MemoryDB eine Benachrichtigung an ein bestimmtes Amazon SNS SNS-Thema. Zu den wichtigen Ereignissen zählen beispielsweise das fehlgeschlagene Hinzufügen eines Knotens, das erfolgreiche Hinzufügen eines Knotens und die Änderung einer Sicherheitsgruppe. Durch die Überwachung wichtiger Schlüsselereignisse können Sie den aktuellen Status Ihrer Cluster erfahren und, je nach Ereignis, Korrekturen vornehmen.
**Topics**
+ [MemoryDB Amazon SNS SNS-Benachrichtigungen verwalten](mdbevents.sns.md)
+ [MemoryDB-Ereignisse anzeigen](mdbevents.viewing.md)
+ [Ereignisbenachrichtigungen und Amazon SNS](memorydbsns.md)
# MemoryDB Amazon SNS SNS-Benachrichtigungen verwalten
Mit Amazon Simple Notification Service (Amazon SNS) können Sie MemoryDB so konfigurieren, dass Benachrichtigungen für wichtige Cluster-Ereignisse gesendet werden. In diesen Beispielen konfigurieren Sie einen Cluster mit dem Amazon-Ressourcenname (ARN) eines Amazon-SNS-Themas, um Benachrichtigungen zu erhalten.
**Anmerkung**
In diesem Thema wird davon ausgegangen, dass Sie sich bei Amazon SNS angemeldet und ein Amazon-SNS-Thema eingerichtet und abonniert haben. Informationen dazu finden Sie im [Entwicklerhandbuch zu Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/).
## Hinzufügen eines Amazon-SNS-Themas
In den folgenden Abschnitten erfahren Sie, wie Sie mithilfe der AWS Konsole, der oder der MemoryDB-API ein Amazon SNS SNS-Thema hinzufügen. AWS CLI
### Hinzufügen eines Amazon-SNS-Themas (Konsole)
Das folgende Verfahren zeigt Ihnen, wie Sie ein Amazon-SNS-Thema für einen Cluster hinzufügen.
**Anmerkung**
Diese Vorgehensweise kann auch zum Ändern des Amazon-SNS-Themas verwendet werden.
**So fügen Sie ein Amazon-SNS-Thema für einen Cluster hinzu oder ändern es (Konsole)**
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 unter **Cluster** den Cluster aus, für den Sie einen Amazon-SNS-Thema-ARN hinzufügen oder ändern möchten.
1. Wählen Sie **Ändern** aus.
1. Wählen Sie im Feld **Modify Cluster (Cluster ändern)** unter **Topic for SNS Notification** (Thema für SNS-Benachrichtigung)** das SNS-Thema aus, das Sie hinzufügen möchten, oder wählen Sie **Manual ARN input (Manuelle ARN-Eingabe) aus und geben Sie den ARN des Amazon-SNS-Themas ein.
1. Wählen Sie **Ändern** aus.
### Hinzufügen eines Amazon SNS SNS-Themas (AWS CLI)
Verwenden Sie den AWS CLI Befehl`update-cluster`, um ein Amazon SNS SNS-Thema für einen Cluster hinzuzufügen oder zu ändern.
Das folgende Codebeispiel fügt einen Amazon-SNS-Themen-ARN zu *my-cluster* hinzu.
Für Linux, macOS oder Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Für Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Weitere Informationen finden Sie unter [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
### Hinzufügen eines Amazon SNS SNS-Themas (MemoryDB-API)
Um ein Amazon SNS SNS-Thema für einen Cluster hinzuzufügen oder zu aktualisieren, rufen Sie die `UpdateCluster` Aktion mit den folgenden Parametern auf:
+ `ClusterName``=my-cluster`
+ `SnsTopicArn``=arn%3Aaws%3Asns%3Aus-east-1%3A565419523791%3AmemorydbNotifications`
Um ein Amazon SNS SNS-Thema für einen Cluster hinzuzufügen oder zu aktualisieren, rufen Sie die `UpdateCluster` Aktion auf.
Weitere Informationen finden Sie unter [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
## Aktivieren und Deaktivieren von Amazon-SNS-Benachrichtigungen
Sie können Benachrichtigungen für einen Cluster aktivieren oder deaktivieren. Das folgende Verfahren zeigt, wie Sie Amazon-SNS-Benachrichtigungen deaktivieren.
### Aktivieren und Deaktivieren von Amazon-SNS-Benachrichtigungen (Konsole)
**Um Amazon SNS SNS-Benachrichtigungen zu deaktivieren, verwenden Sie den AWS-Managementkonsole**
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 das Optionsfeld links neben dem Cluster aus, für den Sie die Benachrichtigung ändern möchten.
1. Wählen Sie **Ändern** aus.
1. Wählen Sie im Feld **Modify Cluster** unter **Topic for SNS Notification** die Option *Disable Notifications* aus.
1. Wählen Sie **Ändern** aus.
### Amazon SNS SNS-Benachrichtigungen (AWS CLI) aktivieren und deaktivieren
Verwenden Sie zum Deaktivieren von Amazon-SNS-Benachrichtigungen den Befehl `update-cluster` mit folgenden Parametern:
Für Linux, macOS oder Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-status inactive
```
Für Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-status inactive
```
### Amazon SNS SNS-Benachrichtigungen aktivieren und deaktivieren (MemoryDB-API)
Rufen Sie zum Deaktivieren von Amazon-SNS-Benachrichtigungen die `UpdateCluster`-Aktion mit folgenden Parametern auf:
+ `ClusterName``=my-cluster`
+ `SnsTopicStatus``=inactive`
Diese Aktion führt zu folgender oder einer ähnlichen Ausgabe:
**Example**
```
1. https://memory-db.us-east-1.amazonaws.com/
2. ?Action=UpdateCluster
3. &ClusterName=my-cluster
4. &SnsTopicStatus=inactive
5. &Version=2021-01-01
6. &SignatureVersion=4
7. &SignatureMethod=HmacSHA256
8. &Timestamp=20210801T220302Z
9. &X-Amz-Algorithm=Amazon4-HMAC-SHA256
10. &X-Amz-Date=20210801T220302Z
11. &X-Amz-SignedHeaders=Host
12. &X-Amz-Expires=20210801T220302Z
13. &X-Amz-Credential=
14. &X-Amz-Signature=
```
# MemoryDB-Ereignisse anzeigen
MemoryDB protokolliert Ereignisse, die sich auf Ihre Cluster, Sicherheitsgruppen und Parametergruppen beziehen. Diese Informationen beinhalten Datum und Zeit eines Ereignisses, den Quellnamen und Quelltyp sowie eine Beschreibung des Ereignisses. Sie können Ereignisse einfach mit der MemoryDB-Konsole, dem AWS CLI `describe-events` Befehl oder der MemoryDB-API-Aktion aus dem Protokoll abrufen. `DescribeEvents`
Die folgenden Verfahren zeigen Ihnen, wie Sie alle MemoryDB-Ereignisse der letzten 24 Stunden (1440 Minuten) anzeigen können.
## MemoryDB-Ereignisse anzeigen (Konsole)
Das folgende Verfahren zeigt Ereignisse mithilfe der MemoryDB-Konsole an.
**Um Ereignisse mit der MemoryDB-Konsole anzuzeigen**
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 im linken Navigationsbereich Ereignisse aus.**
Der Bildschirm „*Ereignisse*“ wird angezeigt und listet alle verfügbaren Ereignisse auf. Jede Zeile der Liste steht für ein Ereignis und zeigt die Ereignisquelle, den Ereignistyp (wie Cluster, Parametergruppe, ACL, Sicherheitsgruppe oder Subnetzgruppe), die GMT-Zeit des Ereignisses und die Beschreibung des Ereignisses an.
Mit der Option **Filter** können Sie angeben, ob alle Ereignisse oder nur Ereignisse eines bestimmten Typs in der Ereignisliste enthalten sein sollen.
## MemoryDB-Ereignisse anzeigen (CLI)AWS
Verwenden Sie den Befehl, um mit dem eine Liste von MemoryDB-Ereignissen zu generieren. AWS CLI`describe-events` Mit optionalen Parametern können Sie u. a. den Typ und den Zeitrahmen der aufgelisteten Ereignisse sowie die maximale Anzahl der aufzulistenden Ereignisse steuern.
Der folgende Code listet bis zu 40 Cluster-Ereignisse auf.
```
aws memorydb describe-events --source-type cluster --max-results 40
```
Mit dem folgenden Code werden alle Ereignisse der letzten 24 Stunden (1 440 Minuten) aufgelistet.
```
aws memorydb describe-events --duration 1440
```
Die Ausgabe des Befehls `describe-events` sieht in etwa wie folgt aus:
```
{
"Events": [
{
"Date": "2021-03-29T22:17:37.781Z",
"Message": "Added node 0001 in Availability Zone us-east-1a",
"SourceName": "memorydb01",
"SourceType": "cluster"
},
{
"Date": "2021-03-29T22:17:37.769Z",
"Message": "cluster created",
"SourceName": "memorydb01",
"SourceType": "cluster"
}
]
}
```
Weitere Informationen z. B. zu den verfügbaren Parametern und den zulässigen Parameterwerten finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html).
## MemoryDB-Ereignisse anzeigen (MemoryDB-API)
Verwenden Sie die Aktion, um mithilfe der MemoryDB-API eine Liste von MemoryDB-Ereignissen zu generieren. `DescribeEvents` Mit optionalen Parametern können Sie u. a. den Typ und den Zeitrahmen der aufgelisteten Ereignisse sowie die maximale Anzahl der aufzulistenden Ereignisse steuern.
Der folgende Code listet die 40 neuesten -Cluster-Ereignisse auf.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&MaxResults=40
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
Der folgende Code listet die Cluster-Ereignisse der letzten 24 Stunden (1440 Minuten) auf.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&Duration=1440
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
Die Ausgabe der oben angegebenen Aktionen sollte in etwa wie folgt aussehen:
```
cluster created
cluster
2021-08-02T18:22:18.202Z
my-memorydb-primary
(...output omitted...)
e21c81b4-b9cd-11e3-8a16-7978bb24ffdf
```
Weitere Informationen z. B. zu den verfügbaren Parametern und den zulässigen Parameterwerten finden Sie unter [https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html).
# Ereignisbenachrichtigungen und Amazon SNS
MemoryDB kann Nachrichten mithilfe von Amazon Simple Notification Service (SNS) veröffentlichen, wenn wichtige Ereignisse in einem Cluster auftreten. Diese Funktion kann verwendet werden, um die Serverlisten auf Client-Computern zu aktualisieren, die mit einzelnen Knotenendpunkten eines Clusters verbunden sind.
**Anmerkung**
Weitere Informationen zum Amazon Simple Notification Service (SNS) sowie Informationen zu Preisen und Links zur Amazon-SNS-Dokumentation finden Sie auf der [Produktseite zu Amazon SNS](https://aws.amazon.com/sns).
Benachrichtigungen werden in einem bestimmten Amazon-SNS*-Thema* veröffentlicht. Für Benachrichtigungen müssen folgende Voraussetzungen erfüllt sein:
+ Für MemoryDB-Benachrichtigungen kann nur ein Thema konfiguriert werden.
+ Das AWS Konto, dem das Amazon SNS SNS-Thema gehört, muss dasselbe Konto sein, das den Cluster besitzt, auf dem Benachrichtigungen aktiviert sind.
## MemoryDB-Ereignisse
Die folgenden MemoryDB-Ereignisse lösen Amazon SNS SNS-Benachrichtigungen aus:
| Ereignisname | Fehlermeldung | Beschreibung |
| --- | --- | --- |
| MemoryDB: AddNodeComplete | "Modified number of nodes from %d to %d" | Ein Knoten wurde dem Cluster hinzugefügt und ist einsatzbereit. |
| MemoryDB: AddNodeFailed aufgrund unzureichender freier IP-Adressen | "Failed to modify number of nodes from %d to %d due to insufficient free IP addresses" | Ein Knoten konnte nicht hinzugefügt werden, da nicht genügend IP-Adressen verfügbar sind. |
| Speicher-DB: ClusterParametersChanged | "Updated parameter group for the cluster" Beim Erstellen wird auch `"Updated to use a ParameterGroup %s"` gesendet. | Ein oder mehrere Cluster-Parameter wurden geändert. |
| MemoryDB: ClusterProvisioningComplete | "Cluster created." | Die Bereitstellung eines Clusters ist abgeschlossen und die Knoten im Cluster sind einsatzbereit. |
| MemoryDB: ClusterProvisioningFailed aufgrund eines inkompatiblen Netzwerkstatus | "Failed to create cluster due to incompatible network state. %s" | Es wurde versucht, einen neuen Cluster in einer nicht existierenden Virtual Private Cloud (VPC) zu starten. |
| Speicher-DB: ClusterRestoreFailed | "Restore from %s failed for node %s. %s" | MemoryDB konnte den Cluster nicht mit Snapshot-Daten füllen. Dies könnte an einer nicht vorhandenen Snapshot-Datei in Amazon S3 oder an falschen Berechtigungen für diese Datei liegen. Wenn Sie den Cluster beschreiben, lautet der Status. `restore-failed` Sie müssen den Cluster löschen und von vorne beginnen. Weitere Informationen finden Sie unter [Einen neuen Cluster mit einem extern erstellten Snapshot erstellen](snapshots-seeding-redis.md). |
| Speicher-DB: ClusterScalingComplete | `"Succeeded applying modification to node type to %s."` | Die Skalierung für den Cluster wurde erfolgreich abgeschlossen. |
| Speicher-DB: ClusterScalingFailed | `"Failed applying modification to node type to %s."` | Der Scale-Up-Vorgang auf dem Cluster ist fehlgeschlagen. |
| Speicher-DB: NodeReplaceStarted | "Recovering node %s" | MemoryDB hat festgestellt, dass der Host, auf dem ein Knoten läuft, heruntergefahren oder nicht erreichbar ist, und hat begonnen, den Knoten zu ersetzen. Der DNS-Eintrag für den ersetzten Knoten wurde nicht geändert. In den meisten Fällen müssen Sie die Serverliste für die Clients nicht aktualisieren, wenn dieses Ereignis auftritt. Einige Clientbibliotheken verwenden den Knoten möglicherweise auch dann nicht mehr, wenn MemoryDB den Knoten ersetzt hat. In diesem Fall sollte die Anwendung die Serverliste aktualisieren, wenn dieses Ereignis eintritt. |
| MemoryDB: NodeReplaceComplete | "Finished recovery for node %s" | MemoryDB hat festgestellt, dass der Host, auf dem ein Knoten ausgeführt wird, heruntergefahren oder nicht erreichbar ist, und hat den Austausch des Knotens abgeschlossen. Der DNS-Eintrag für den ersetzten Knoten wurde nicht geändert. In den meisten Fällen müssen Sie die Serverliste für die Clients nicht aktualisieren, wenn dieses Ereignis auftritt. Einige Clientbibliotheken verwenden den Knoten möglicherweise auch dann nicht mehr, wenn MemoryDB den Knoten ersetzt hat. In diesem Fall sollte die Anwendung die Serverliste aktualisieren, wenn dieses Ereignis eintritt. |
| MemoryDB: CreateClusterComplete | "Cluster created" | Der Cluster wurde erfolgreich erstellt. |
| Memory-DB: CreateClusterFailed | "Failed to create cluster due to unsuccessful creation of its node(s)." und "Deleting all nodes belonging to this cluster." | Der Cluster wurde nicht erstellt. |
| Speicher-DB: DeleteClusterComplete | "Cluster deleted." | Das Löschen eines Clusters und aller zugehörigen Knoten ist abgeschlossen. |
| MemoryDB: FailoverComplete | `"Failover to replica node %s completed"` | Failover zu einem Replikationsknoten wurde erfolgreich abgeschlossen. |
| Speicher-DB: NodeReplacementCanceled | "The replacement of node %s which was scheduled during the maintenance window from start time: %s, end time: %s has been canceled" | Ein Knoten in Ihrem Cluster, der ersetzt werden sollte, soll nicht länger ersetzt werden. |
| Speicher-DB: NodeReplacementRescheduled | "The replacement in maintenance window for node %s has been re-scheduled from previous start time: %s, previous end time: %s to new start time: %s, new end time: %s" | Für einen zu ersetzenden Knoten in Ihrem Cluster wurde eine spätere Ersetzung im neuen Fenster geplant, das in der Benachrichtigung angegeben wurde. Weitere Informationen zu den möglichen Aktionen erhalten Sie unter [Ersetzen von Knoten](nodes.nodereplacement.md). |
| Speicher-DB: NodeReplacementScheduled | "The node %s is scheduled for replacement during the maintenance window from start time: %s to end time: %s" | Ein Knoten in Ihrem Cluster soll während des in der Benachrichtigung beschriebenen Fensters ersetzt werden. Weitere Informationen zu den möglichen Aktionen erhalten Sie unter [Ersetzen von Knoten](nodes.nodereplacement.md). |
| Speicher-DB: RemoveNodeComplete | "Removed node %s" | Ein Knoten wurde aus dem Cluster entfernt. |
| Speicher-DB: SnapshotComplete | "Snapshot %s succeeded for node %s" | Ein Snapshot wurde erfolgreich abgeschlossen. |
| Memory-DB: SnapshotFailed | "Snapshot %s failed for node %s" | Ein Snapshot ist fehlgeschlagen. Eine detailliertere Ursache finden Sie in den Ereignissen des Clusters. Wenn Sie den Snapshot beschreiben (siehe [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html)), ist dessen Status `failed`. |
# MemoryDB-API-Aufrufe protokollieren mit AWS CloudTrail
MemoryDB ist in einen Dienst integriert AWS CloudTrail, der eine Aufzeichnung der Aktionen bereitstellt, die von einem Benutzer, einer Rolle oder einem AWS Dienst in MemoryDB ausgeführt wurden. CloudTrail erfasst alle API-Aufrufe für MemoryDB als Ereignisse, einschließlich Aufrufe von der MemoryDB-Konsole und von Codeaufrufen an die MemoryDB-API-Operationen. Wenn Sie einen Trail erstellen, können Sie die kontinuierliche Bereitstellung von CloudTrail Ereignissen an einen Amazon S3 S3-Bucket aktivieren, einschließlich Ereignissen für MemoryDB. Wenn Sie keinen Trail konfigurieren, können Sie die neuesten Ereignisse trotzdem in der CloudTrail Konsole im **Ereignisverlauf** anzeigen. Anhand der von CloudTrail gesammelten Informationen können Sie die Anfrage an MemoryDB, die IP-Adresse, von der aus die Anfrage gestellt wurde, wer die Anfrage gestellt hat, wann sie gestellt wurde, und weitere Details ermitteln.
Weitere Informationen CloudTrail dazu finden Sie im [AWS CloudTrail Benutzerhandbuch](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## MemoryDB-Informationen in CloudTrail
CloudTrail ist in Ihrem AWS Konto aktiviert, wenn Sie das Konto erstellen. Wenn eine Aktivität in MemoryDB auftritt, wird diese Aktivität zusammen mit anderen AWS Dienstereignissen im CloudTrail Ereignisverlauf in einem **Ereignis** aufgezeichnet. Sie können aktuelle Ereignisse in Ihrem AWS Konto anzeigen, suchen und herunterladen. Weitere Informationen finden Sie unter [Ereignisse mit CloudTrail Ereignisverlauf anzeigen](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Für eine fortlaufende Aufzeichnung der Ereignisse in Ihrem AWS Konto, einschließlich Ereignissen für MemoryDB, erstellen Sie einen Trail. Ein Trail ermöglicht CloudTrail die Übermittlung von Protokolldateien an einen Amazon S3 S3-Bucket. Wenn Sie einen Trail in der Konsole anlegen, gilt dieser standardmäßig für alle Regionen. Der Trail protokolliert Ereignisse aus allen Regionen der AWS Partition und übermittelt die Protokolldateien an den von Ihnen angegebenen Amazon S3 S3-Bucket. Darüber hinaus können Sie andere AWS Dienste konfigurieren, um die in den CloudTrail Protokollen gesammelten Ereignisdaten weiter zu analysieren und darauf zu reagieren. Weitere Informationen finden Sie hier:
+ [Übersicht zum Erstellen eines Trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Unterstützte Dienste und Integrationen](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Konfiguration von Amazon SNS SNS-Benachrichtigungen für CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Empfangen von CloudTrail Protokolldateien aus mehreren Regionen](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) und [Empfangen von CloudTrail Protokolldateien von mehreren Konten](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Alle MemoryDB-Aktionen werden von protokolliert. CloudTrail Beispielsweise generieren Aufrufe von `DescribeClusters` und `UpdateCluster` Aktionen Einträge in den CloudTrail Protokolldateien. `CreateCluster`
Jeder Ereignis- oder Protokolleintrag enthält Informationen zu dem Benutzer, der die Anforderung generiert hat. Die Identitätsinformationen unterstützen Sie bei der Ermittlung der folgenden Punkte:
+ Gibt an, ob die Anforderung mit Root- oder IAM-Benutzer-Anmeldeinformationen ausgeführt wurde.
+ Gibt an, ob die Anforderung mit temporären Sicherheitsanmeldeinformationen für eine Rolle oder einen Verbundbenutzer gesendet wurde.
+ Ob die Anfrage von einem anderen AWS Dienst gestellt wurde.
Weitere Informationen finden Sie unter [CloudTrail userIdentity-Element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Grundlegendes zu MemoryDB-Protokolldateieinträgen
Ein Trail ist eine Konfiguration, die die Übertragung von Ereignissen als Protokolldateien an einen von Ihnen angegebenen Amazon S3 S3-Bucket ermöglicht. CloudTrail Protokolldateien enthalten einen oder mehrere Protokolleinträge. Ein Ereignis stellt eine einzelne Anforderung aus einer beliebigen Quelle dar und enthält Informationen über die angeforderte Aktion, Datum und Uhrzeit der Aktion, Anforderungsparameter usw. CloudTrail Protokolldateien sind kein geordneter Stack-Trace der öffentlichen API-Aufrufe, sodass sie nicht in einer bestimmten Reihenfolge angezeigt werden.
Das folgende Beispiel zeigt einen CloudTrail Protokolleintrag, der die `CreateCluster` Aktion demonstriert.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T17:56:46Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"nodeType": "db.r6g.large",
"subnetGroupName": "memorydb-subnet-group",
"aCLName": "open-access"
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "creating",
"numberOfShards": 1,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"enginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "09:00-10:00",
"aCLName": "open-access",
"dataTiering": "false",
"autoMinorVersionUpgrade": true
}
},
"requestID": "506fc951-9ae2-42bb-872c-98028dc8ed11",
"eventID": "2ecf3dc3-c931-4df0-a2b3-be90b596697e",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
Das folgende Beispiel zeigt einen CloudTrail Protokolleintrag, der die `DescribeClusters` Aktion demonstriert. Beachten Sie, dass bei allen MemoryDB-Aufrufen Describe und List (`Describe*`und`List*`) der `responseElements` Abschnitt entfernt wird und als angezeigt wird. `null`
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T18:39:51Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "DescribeClusters",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.describe-clusters",
"requestParameters": {
"maxResults": 50,
"showShardDetails": true
},
"responseElements": null,
"requestID": "5e831993-52bb-494d-9bba-338a117c2389",
"eventID": "32a3dc0a-31c8-4218-b889-1a6310b7dd50",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
Das folgende Beispiel zeigt einen CloudTrail Protokolleintrag, der eine `UpdateCluster` Aktion aufzeichnet.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:23:20Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "UpdateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.update-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"snapshotWindow": "04:00-05:00",
"shardConfiguration": {
"shardCount": 2
}
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "updating",
"numberOfShards": 2,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"address": "clustercfg.memorydb-cluster.cde8da.memorydb.us-east-1.amazonaws.com",
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "04:00-05:00",
"autoMinorVersionUpgrade": true,
"DataTiering": "false"
}
},
"requestID": "dad021ce-d161-4365-8085-574133afab54",
"eventID": "e0120f85-ab7e-4ad4-ae78-43ba15dee3d8",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
Das folgende Beispiel zeigt einen CloudTrail Protokolleintrag, der die `CreateUser` Aktion demonstriert. Beachten Sie, dass bei MemoryDB-Aufrufen, die vertrauliche Daten enthalten, diese Daten beim entsprechenden CloudTrail Ereignis unkenntlich gemacht werden, wie im `requestParameters` folgenden Abschnitt dargestellt.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:56:13Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-user",
"requestParameters": {
"userName": "memorydb-user",
"authenticationMode": {
"type": "password",
"passwords": [
"HIDDEN_DUE_TO_SECURITY_REASONS"
]
},
"accessString": "~* &* -@all +@read"
},
"responseElements": {
"user": {
"name": "memorydb-user",
"status": "active",
"accessString": "off ~* &* -@all +@read",
"aCLNames": [],
"minimumEngineVersion": "6.2",
"authentication": {
"type": "password",
"passwordCount": 1
},
"aRN": "arn:aws:memorydb:us-east-1:123456789012:user/memorydb-user"
}
},
"requestID": "ae288b5e-80ab-4ff8-989a-5ee5c67cd193",
"eventID": "ed096e3e-16f1-4a23-866c-0baa6ec769f6",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```