Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Journalisation et surveillance
La surveillance joue un rôle important dans le maintien de la fiabilité, de la disponibilité et des performances de MemoryDB et de vos autres AWS solutions. AWS fournit les outils de surveillance suivants pour surveiller MemoryDB, signaler un problème et prendre des mesures automatiques le cas échéant :
+ *Amazon CloudWatch* surveille vos AWS ressources et les applications que vous utilisez AWS en temps réel. Vous pouvez collecter et suivre les métriques, créer des tableaux de bord personnalisés, et définir des alarmes qui vous informent ou prennent des mesures lorsqu’une métrique spécifique atteint un seuil que vous spécifiez. Par exemple, vous pouvez CloudWatch suivre l'utilisation du processeur ou d'autres indicateurs de vos EC2 instances Amazon et lancer automatiquement de nouvelles instances en cas de besoin. Pour plus d'informations, consultez le [guide de CloudWatch l'utilisateur Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ *Amazon CloudWatch Logs* vous permet de surveiller, de stocker et d'accéder à vos fichiers journaux à partir d' EC2 instances Amazon et d'autres sources. CloudTrail CloudWatch Les journaux peuvent surveiller les informations contenues dans les fichiers journaux et vous avertir lorsque certains seuils sont atteints. Vous pouvez également archiver vos données de journaux dans une solution de stockage hautement durable. Pour plus d'informations, consultez le [guide de l'utilisateur d'Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).
+ *AWS CloudTrail*capture les appels d'API et les événements associés effectués par ou pour le compte de votre AWS compte et envoie les fichiers journaux dans un compartiment Amazon S3 que vous spécifiez. Vous pouvez identifier les utilisateurs et les comptes appelés AWS, l'adresse IP source à partir de laquelle les appels ont été effectués et la date des appels. Pour plus d’informations, consultez le [Guide de l’utilisateur AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
# Surveillance de MemoryDB avec Amazon CloudWatch
Vous pouvez surveiller MemoryDB en utilisant CloudWatch, qui collecte les données brutes et les traite en métriques lisibles en temps quasi réel. Ces statistiques sont enregistrées pour une durée de 15 mois ; par conséquent, vous pouvez accéder aux informations historiques et acquérir un meilleur point de vue de la façon dont votre service ou application web s’exécute. Vous pouvez également définir des alarmes qui surveillent certains seuils et envoient des notifications ou prennent des mesures lorsque ces seuils sont atteints. Pour plus d'informations, consultez le [guide de CloudWatch l'utilisateur Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
Les sections suivantes répertorient les métriques et les dimensions de MemoryDB.
**Topics**
+ [Métriques au niveau de l'hôte](metrics.HostLevel.md)
+ [Métriques pour MemoryDB](metrics.memorydb.md)
+ [Quelles métriques dois-je surveiller ?](metrics.whichshouldimonitor.md)
+ [Choix des périodes et des statistiques de métriques](metrics.ChoosingStatisticsAndPeriods.md)
+ [CloudWatch Métriques de surveillance](cloudwatchmetrics.md)
# Métriques au niveau de l'hôte
L'espace de `AWS/MemoryDB` noms inclut les métriques suivantes au niveau de l'hôte pour les nœuds individuels.
**Voir aussi**
+ [Métriques pour MemoryDB](metrics.memorydb.md)
| Métrique | Description | Unit |
| --- | --- | --- |
| CPUUtilization | Le pourcentage d'utilisation de l'UC pour l'hôte entier. Valkey et Redis OSS étant à thread unique, nous vous recommandons de surveiller les EngineCPUUtilization métriques pour les nœuds contenant 4 v. ou plus. CPUs | Pourcentage |
| FreeableMemory | Espace mémoire disponible sur l'hôte. Ce nombre est dérivé de la mémoire vive et des tampons que le système d'exploitation considère comme libérables. | Octets |
| NetworkBytesIn | Nombre d'octets lus par l'hôte à partir du réseau. | Octets |
| NetworkBytesOut | Nombre d'octets envoyés par l'instance sur toutes les interfaces réseau. | Octets |
| NetworkPacketsIn | Nombre de paquets reçus par l'instance sur toutes les interfaces réseau. Cette métrique identifie le volume du trafic entrant en ce qui concerne le nombre de paquets sur une seule instance. | Nombre |
| NetworkPacketsOut | Nombre de paquets envoyés par l'instance sur toutes les interfaces réseau. Cette métrique identifie le volume du trafic sortant en ce qui concerne le nombre de paquets sur une seule instance. | Nombre |
| NetworkBandwidthInAllowanceExceeded | Nombre de paquets formés parce que la bande passante agrégée entrante a dépassé le maximum de l'instance. | Nombre |
| NetworkConntrackAllowanceExceeded | Nombre de paquets formés parce que le suivi des connexions a dépassé le maximum de l'instance et que de nouvelles connexions n'ont pas pu être établies. Cela peut entraîner une perte de paquets pour le trafic vers ou en provenance de l’instance. | Nombre |
| NetworkBandwidthOutAllowanceExceeded | Nombre de paquets formés parce que la bande passante agrégée sortante a dépassé le maximum de l'instance. | Nombre |
| NetworkPacketsPerSecondAllowanceExceeded | Nombre de paquets formés parce que le PPS bidirectionnel a dépassé le maximum de l’instance. | Nombre |
| NetworkMaxBytesIn | Nombre maximal d'octets reçus par seconde par minute. | Octets |
| NetworkMaxBytesOut | Nombre maximal d'octets transmis par seconde par minute. | Octets |
| NetworkMaxPacketsIn | Nombre maximal de paquets reçus par seconde par minute. | Nombre |
| NetworkMaxPacketsOut | Nombre maximal de paquets transmis par seconde par minute. | Nombre |
| SwapUsage | Nombre de permutations utilisées sur l'hôte. | Octets |
# Métriques pour MemoryDB
L’espace de noms `AWS/MemoryDB` inclut les métriques suivantes.
À l'exception de`ReplicationLag`,`EngineCPUUtilization`, et `SuccessfulWriteRequestLatency``SuccessfulReadRequestLatency`, ces métriques sont dérivées des commandes Valkey et Redis OSS**info**. Chaque métrique est calculée au niveau du nœud.
Pour une documentation complète de la **INFO** commande, voir [INFO](http://valkey.io/commands/info).
**Voir aussi :**
+ [Métriques au niveau de l'hôte](metrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/memorydb/latest/devguide/metrics.memorydb.html)
Voici des regroupements de certains types de commandes, dérivés de **info commandstats**. La section commandstats fournit des statistiques basées sur le type de commande, y compris le nombre d'appels.
Pour une liste complète des commandes disponibles, consultez la section [commandes](https://valkey.io/commands).
| Métrique | Description | Unit |
| --- | --- | --- |
| EvalBasedCmds | Nombre total de commandes pour les commandes basées sur eval. Ceci est dérivé de la commandstats statistique en additionnant eval et. evalsha | Nombre |
| GeoSpatialBasedCmds | Nombre total de commandes pour les commandes basées sur la géolocalisation. Ceci est dérivé de la commandstats statistique. Il est dérivé en additionnant tous les types de commandes géo : geoadd, geodist, geohash, geopos, georadius et georadiusbymember. | Nombre |
| GetTypeCmds | Le nombre total de commandes basées sur les types de commandes read-only. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes de read-only type (gethget,scard,lrange,, etc.) | Nombre |
| HashBasedCmds | Nombre total de commandes basées sur le hachage. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs hachages (hget,,,hkeys, hvalshdel, etc.). | Nombre |
| HyperLogLogBasedCmds | Nombre total de commandes basées sur HyperLogLog. Ceci est dérivé de la commandstats statistique en additionnant tous les pf types de commandes (pfaddpfcount,pfmerge,, etc.). | Nombre |
| JsonBasedCmds | Nombre total de commandes basées sur JSON. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs objets de document JSON. | Nombre |
| KeyBasedCmds | Nombre total de commandes basées sur une clé. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur une ou plusieurs touches dans plusieurs structures de données (delexpire,rename,, etc.). | Nombre |
| ListBasedCmds | Nombre total de commandes basées sur une liste. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur une ou plusieurs listes (lindex,lrange,lpush,ltrim, etc.). | Nombre |
| PubSubBasedCmds | Nombre total de commandes pour les pub/sub fonctionnalités. Ceci est dérivé des commandstats statistiques en additionnant toutes les commandes utilisées pour les pub/sub fonctionnalités :psubscribe,publish,pubsub, punsubscribesubscribe, etunsubscribe. | Nombre |
| SearchBasedCmds | Le nombre total de commandes d'index et de recherche secondaires, y compris les commandes de lecture et d'écriture. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes de recherche qui agissent sur les index secondaires. | Nombre |
| SearchBasedGetCmds | Nombre total de commandes d'index et de recherche secondaires en lecture seule. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes d'index secondaire et de recherche. | Nombre |
| SearchBasedSetCmds | Nombre total de commandes d'écriture et d'index secondaires. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes de l'index secondaire et du set de recherche. | Nombre |
| SearchNumberOfIndexes | Nombre total d'index. | Nombre |
| SearchNumberOfIndexedKeys | Nombre total de clés indexées | Nombre |
| SearchTotalIndexSize | Mémoire (octets) utilisée par tous les index. | Octets |
| SetBasedCmds | Nombre total de commandes basées sur un ensemble. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs ensembles (scard,sdiff,sadd,sunion, etc.). | Nombre |
| SetTypeCmds | Le nombre total de commandes de type write. Ceci est dérivé de la commandstats statistique en additionnant tous les mutative types de commandes qui opèrent sur les données (sethset,sadd,lpop,, etc.) | Nombre |
| SortedSetBasedCmds | Nombre total de commandes qui sont triées en fonction d'un ensemble. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs ensembles triés (zcount,zrange,zrank,zadd, etc.). | Nombre |
| StringBasedCmds | Nombre total de commandes basées sur une chaîne. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur une ou plusieurs chaînes (strlen,setex,setrange, etc.). | Nombre |
| StreamBasedCmds | Nombre total de commandes basées sur un flux. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs types de données de flux (xrange,xlen,xadd,xdel, etc.). | Nombre |
# Quelles métriques dois-je surveiller ?
Les CloudWatch mesures suivantes offrent un bon aperçu des performances de MemoryDB. Dans la plupart des cas, nous vous recommandons de définir des CloudWatch alarmes pour ces mesures afin de pouvoir prendre des mesures correctives avant que des problèmes de performances ne surviennent.
**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [Moteur CPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [Mémoire](#metrics-memory)
+ [Réseau](#metrics-network)
+ [Latence](#metrics-latency)
+ [Réplication](#metrics-replication)
## CPUUtilization
Il s'agit d'une métrique au niveau de l'hôte représentée en pourcentage. Pour de plus amples informations, veuillez consulter [Métriques au niveau de l'hôte](metrics.HostLevel.md).
Pour les types de nœuds plus petits avec 2 V CPUs ou moins, utilisez la `CPUUtilization ` métrique pour surveiller votre charge de travail.
En général, nous vous suggérons de définir votre seuil à 90 % de votre UC disponible. Valkey et Redis OSS étant monothread, la valeur de seuil réelle doit être calculée en tant que fraction de la capacité totale du nœud. Supposons par exemple que vous utilisiez un type de nœud comportant deux cœurs. Dans ce cas, le seuil CPUUtilization serait de 90/2, soit 45 %. Pour connaître le nombre de cœurs (vCPUs) de votre type de nœud, consultez la section Tarification de [MemoryDB](https://aws.amazon.com/memorydb/pricing/?p=ps).
Vous devrez déterminer votre propre seuil, en fonction du nombre de cœurs du nœud que vous utilisez. Si vous dépassez ce seuil et que votre charge de travail principale provient des demandes de lecture, agrandissez votre cluster en ajoutant des répliques de lecture. Si la charge de travail principale provient de demandes d'écriture, nous vous recommandons d'ajouter des partitions supplémentaires afin de répartir la charge de travail d'écriture sur un plus grand nombre de nœuds principaux.
**Astuce**
Au lieu d'utiliser la métrique Host-Level`CPUUtilization`, vous pouvez peut-être utiliser la métrique`EngineCPUUtilization`, qui indique le pourcentage d'utilisation sur le cœur du moteur Valkey ou Redis OSS. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
Pour les types de nœuds plus grands avec 4 V CPUs ou plus, vous pouvez utiliser la `EngineCPUUtilization` métrique, qui indique le pourcentage d'utilisation sur le cœur du moteur Valkey ou Redis OSS. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## Moteur CPUUtilization
Pour les types de nœuds plus grands avec 4 V CPUs ou plus, vous pouvez utiliser la `EngineCPUUtilization` métrique, qui indique le pourcentage d'utilisation sur le cœur du moteur Valkey ou Redis OSS. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## SwapUsage
Il s'agit d'une métrique au niveau de l'hôte, publiée en octets. Pour de plus amples informations, veuillez consulter [Métriques au niveau de l'hôte](metrics.HostLevel.md).
Si la `FreeableMemory` CloudWatch métrique est proche de 0 (c'est-à-dire inférieure à 100 Mo) ou si elle est supérieure à la `SwapUsage` `FreeableMemory` métrique, il se peut qu'un nœud soit soumis à une pression de mémoire.
## Evictions
Il s'agit d'une métrique du moteur. Nous vous recommandons de choisir votre propre seuil d'alarme pour cette métrique en fonction des besoins de votre application.
## CurrConnections
Il s'agit d'une métrique du moteur. Nous vous recommandons de choisir votre propre seuil d'alarme pour cette métrique en fonction des besoins de votre application.
Un nombre croissant de *CurrConnections*chiffres peut indiquer un problème avec votre application ; vous devrez étudier le comportement de l'application pour résoudre ce problème.
## Mémoire
La mémoire est au cœur de Valkey et de Redis OSS. Il est nécessaire de comprendre l'utilisation de la mémoire de votre cluster afin d'éviter la perte de données et de tenir compte de la croissance future de votre jeu de données. Les statistiques relatives à l'utilisation de la mémoire d'un nœud sont disponibles dans la section mémoire de la commande [INFO](https://valkey.io/commands/info).
## Réseau
L'un des facteurs déterminants de la capacité de bande passante réseau de votre cluster est le type de nœud que vous avez sélectionné. Pour plus d'informations sur la capacité réseau de votre nœud, consultez la tarification d'[Amazon MemoryDB](https://aws.amazon.com/memorydb/pricing/).
## Latence
Les métriques `SuccessfulWriteRequestLatency` de latence `SuccessfulReadRequestLatency` mesurent le temps total nécessaire à MemoryDB pour le moteur Valkey pour répondre à une demande.
**Note**
Des valeurs `SuccessfulWriteRequestLatency` et des `SuccessfulReadRequestLatency` métriques gonflées peuvent survenir lors de l'utilisation du pipeline Valkey avec CLIENT REPLY activé sur le client Valkey. Le pipeline Valkey est une technique permettant d'améliorer les performances en émettant plusieurs commandes à la fois, sans attendre la réponse à chaque commande individuelle. Pour éviter les valeurs exagérées, nous vous recommandons de configurer votre client Redis pour qu'il achemine les commandes avec [CLIENT REPLY OFF.](https://valkey.io/commands/client-reply/)
## Réplication
Le volume de données en cours de réplication est visible via le métrique `ReplicationBytes`. Vous pouvez effectuer une surveillance `MaxReplicationThroughput` par rapport au débit de la capacité de réplication. Il est recommandé d'ajouter des partitions supplémentaires lorsque le débit de capacité de réplication maximal est atteint.
`ReplicationDelayedWriteCommands`peut également indiquer si la charge de travail dépasse le débit maximal de capacité de réplication. Pour plus d'informations sur la réplication dans MemoryDB, voir [Comprendre](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html) la réplication MemoryDB
# Choix des périodes et des statistiques de métriques
Bien que CloudWatch vous puissiez choisir n'importe quelle statistique et période pour chaque métrique, toutes les combinaisons ne seront pas utiles. Par exemple, les statistiques moyenne, minimale et maximale pour CPUUtilization sont utiles, mais pas la statistique Sum.
Tous les exemples de MemoryDB sont publiés pour une durée de 60 secondes pour chaque nœud individuel. Pour toute période de 60 secondes, une métrique de nœud ne contiendra qu'un seul échantillon.
# CloudWatch Métriques de surveillance
MemoryDB et CloudWatch sont intégrés afin que vous puissiez collecter une variété de métriques. Vous pouvez surveiller ces indicateurs à l'aide de CloudWatch.
**Note**
Les exemples suivants nécessitent les outils de ligne de CloudWatch commande. Pour plus d'informations sur CloudWatch les outils de développement et pour les télécharger, consultez la [page CloudWatch du produit](https://aws.amazon.com/cloudwatch).
Les procédures suivantes vous montrent comment collecter des statistiques CloudWatch d'espace de stockage pour un cluster au cours de la dernière heure.
**Note**
Les `EndTime` valeurs `StartTime` et fournies dans les exemples suivants sont fournies à titre indicatif. Assurez-vous de remplacer les valeurs d'heure de début et de fin appropriées pour vos nœuds.
Pour plus d'informations sur les limites de MemoryDB, voir Limites de [AWS service](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_memorydb) pour MemoryDB.
## CloudWatch Métriques de surveillance (console)
**Pour recueillir des statistiques d'utilisation du processeur pour un cluster**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Sélectionnez les nœuds pour lesquels vous souhaitez consulter les métriques.
**Note**
L'affichage des métriques sur la console est désactivé si vous sélectionnez plus de 20 nœuds.
1. Sur la page **Clusters** de la console de AWS gestion, cliquez sur le nom d'un ou de plusieurs clusters.
La page détaillée du cluster s'affiche.
1. Cliquez sur l'onglet **Nodes** en haut de la fenêtre.
1. Dans l'onglet **Nœuds** de la fenêtre détaillée, sélectionnez les nœuds pour lesquels vous souhaitez consulter les métriques.
La liste des CloudWatch métriques disponibles apparaît en bas de la fenêtre de console.
1. Cliquez sur la métrique **CPU Utilization**.
La CloudWatch console s'ouvre et affiche les statistiques que vous avez sélectionnées. Vous pouvez utiliser les zones de liste déroulantes **Statistic** et **Period** et l'onglet **Time Range** pour modifier les métriques affichées.
## Surveillance des CloudWatch métriques à l'aide de la CloudWatch CLI
**Pour recueillir des statistiques d'utilisation du processeur pour un cluster**
+ Utilisez la CloudWatch commande **aws cloudwatch get-metric-statistics** avec les paramètres suivants (notez que les heures de début et de fin ne sont indiquées qu'à titre d'exemple ; vous devrez les remplacer par vos propres heures de début et de fin appropriées) :
Pour Linux, macOS ou 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
```
Pour 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
```
## Surveillance des CloudWatch métriques à l'aide de l' CloudWatch API
**Pour recueillir des statistiques d'utilisation du processeur pour un cluster**
+ Appelez l' CloudWatch API `GetMetricStatistics` avec les paramètres suivants (notez que les heures de début et de fin ne sont indiquées qu'à titre d'exemple ; vous devrez les remplacer par vos propres heures de début et de fin appropriées) :
+ `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=
```
# Surveillance des événements MemoryDB
Lorsque des événements importants se produisent pour un cluster, MemoryDB envoie une notification à une rubrique Amazon SNS spécifique. Les exemples incluent des éléments tels que l'échec d'ajout d'un nœud, l'ajout réussi d'un nœud, la modification d'un groupe de sécurité, etc. En surveillant les événements principaux, vous pouvez connaître l'état actuel de vos clusters, et, selon l'événement, prendre des actions correctives.
**Topics**
+ [Gestion des notifications Amazon SNS de MemoryDB](mdbevents.sns.md)
+ [Affichage des événements MemoryDB](mdbevents.viewing.md)
+ [Notifications d'événements Amazon SNS](memorydbsns.md)
# Gestion des notifications Amazon SNS de MemoryDB
Vous pouvez configurer MemoryDB pour envoyer des notifications pour les événements importants du cluster à l'aide d'Amazon Simple Notification Service (Amazon SNS). Dans ces exemples, vous allez configurer un cluster avec l'Amazon Resource Name (ARN) d'une rubrique Amazon SNS pour recevoir des notifications.
**Note**
Cette rubrique suppose que vous êtes inscrit à Amazon SNS, que vous avez souscrit à une rubrique Amazon SNS et que vous l'avez configurée. Pour plus d'informations sur Amazon SNS, veuillez consulter le [Guide du développeur d'Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/).
## Ajout d'une rubrique Amazon SNS
Les sections suivantes expliquent comment ajouter une rubrique Amazon SNS à l'aide de la AWS console, de l'API MemoryDB ou de l' AWS CLI API MemoryDB.
### Ajout d'une rubrique Amazon SNS (console)
La procédure suivante vous indique comment ajouter une rubrique Amazon SNS pour un cluster.
**Note**
Ce processus permet également de modifier la rubrique Amazon SNS.
**Pour ajouter ou modifier une rubrique Amazon SNS pour un cluster (console)**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans **Clusters**, choisissez le cluster pour lequel vous souhaitez ajouter ou modifier un ARN de rubrique Amazon SNS.
1. Sélectionnez **Modifier**.
1. Dans **Modify Cluster (Modifier le cluster)** sous **Topic for SNS Notification (Rubrique pour notification SNS)**, choisissez la rubrique SNS que vous voulez ajouter ou choisissez **Manual ARN input (Saisie d'ARN manuelle)** et tapez l'ARN de la rubrique Amazon SNS.
1. Sélectionnez **Modifier**.
### Ajout d'une rubrique Amazon SNS (CLI)AWS
Pour ajouter ou modifier une rubrique Amazon SNS pour un cluster, utilisez la AWS CLI commande. `update-cluster`
L'exemple de code suivant ajoute un ARN de rubrique Amazon SNS à *my-cluster*.
Pour Linux, macOS ou Unix :
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Pour Windows :
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Pour plus d’informations, consultez [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
### Ajout d'une rubrique Amazon SNS (API MemoryDB)
Pour ajouter ou mettre à jour une rubrique Amazon SNS pour un cluster, lancez l'`UpdateCluster`action avec les paramètres suivants :
+ `ClusterName``=my-cluster`
+ `SnsTopicArn``=arn%3Aaws%3Asns%3Aus-east-1%3A565419523791%3AmemorydbNotifications`
Pour ajouter ou mettre à jour une rubrique Amazon SNS pour un cluster, lancez l'`UpdateCluster`action.
Pour de plus amples informations, veuillez consulter [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
## Activation et désactivation des notifications Amazon SNS
Vous pouvez activer ou désactiver les notifications pour un cluster. Les procédures suivantes vous expliquent comment désactiver les notifications Amazon SNS.
### Activation et désactivation des notifications Amazon SNS (console)
**Pour désactiver les notifications Amazon SNS à l'aide du AWS Management Console**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Cliquez sur le bouton radio situé à gauche du cluster pour lequel vous souhaitez modifier la notification.
1. Sélectionnez **Modifier**.
1. Dans **Modifier le cluster** sous **Rubrique pour notification SNS**, choisissez *Désactiver les notifications*.
1. Sélectionnez **Modifier**.
### Activation et désactivation des notifications Amazon SNS (CLI)AWS
Pour désactiver les notifications Amazon SNS, utilisez la commande `update-cluster` avec les paramètres suivants :
Pour Linux, macOS ou Unix :
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-status inactive
```
Pour Windows :
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-status inactive
```
### Activation et désactivation des notifications Amazon SNS (API MemoryDB)
Pour désactiver les notifications Amazon SNS, appelez l'action `UpdateCluster` avec les paramètres suivants :
+ `ClusterName``=my-cluster`
+ `SnsTopicStatus``=inactive`
Cet appel vous renvoie des informations semblables à ce qui suit :
**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=
```
# Affichage des événements MemoryDB
MemoryDB enregistre les événements liés à vos clusters, groupes de sécurité et groupes de paramètres. Ces informations comprennent la date et l'heure de l'événement, le nom et le type de la source de l'événement, ainsi qu'une description de cet événement. Vous pouvez facilement récupérer les événements du journal à l'aide de la console MemoryDB, de la AWS CLI `describe-events` commande ou de l'action de l'API MemoryDB. `DescribeEvents`
Les procédures suivantes vous montrent comment afficher tous les événements MemoryDB des dernières 24 heures (1440 minutes).
## Affichage des événements MemoryDB (console)
La procédure suivante affiche les événements à l'aide de la console MemoryDB.
**Pour afficher les événements à l'aide de la console MemoryDB**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, sélectionnez **Events**.
L'écran *Événements* affiche la liste de tous les événements disponibles. Chaque ligne de la liste représente un événement et affiche la source de l'événement, le type d'événement (tel que cluster, groupe de paramètres, acl, groupe de sécurité ou groupe de sous-réseaux), l'heure GMT de l'événement et la description de l'événement.
A l'aide du **Filtre**, vous pouvez choisir d'afficher tous les événements ou uniquement ceux d'un type spécifique dans la liste des événements.
## Affichage des événements MemoryDB (CLI)AWS
Pour générer une liste d'événements MemoryDB à l'aide de AWS CLI, utilisez la commande. `describe-events` Vous pouvez utiliser des paramètres facultatifs pour contrôler le type et la période des événements répertoriés, le nombre maximal d'événements à répertorier, etc.
Le code suivant répertorie jusqu'à 40 événements de cluster.
```
aws memorydb describe-events --source-type cluster --max-results 40
```
Le code suivant répertorie tous les événements qui ont eu lieu au cours des dernières 24 heures (1 440 minutes).
```
aws memorydb describe-events --duration 1440
```
La sortie de la commande `describe-events` ressemble à ceci.
```
{
"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"
}
]
}
```
Pour plus d'informations, notamment sur les paramètres disponibles et les valeurs de paramètre autorisées, consultez [https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html).
## Affichage des événements MemoryDB (API MemoryDB)
Pour générer une liste d'événements MemoryDB à l'aide de l'API MemoryDB, utilisez l'action. `DescribeEvents` Vous pouvez utiliser des paramètres facultatifs pour contrôler le type et la période des événements répertoriés, le nombre maximal d'événements à répertorier, etc.
Le code suivant répertorie les 40 événements -cluster les plus récents.
```
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=
```
Le code suivant répertorie les événements du cluster survenus au cours des dernières 24 heures (1 440 minutes).
```
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=
```
Les actions ci-dessus doivent produire un résultat similaire à ce qui suit :
```
cluster created
cluster
2021-08-02T18:22:18.202Z
my-memorydb-primary
(...output omitted...)
e21c81b4-b9cd-11e3-8a16-7978bb24ffdf
```
Pour plus d'informations, notamment sur les paramètres disponibles et les valeurs de paramètre autorisées, consultez [https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html).
# Notifications d'événements Amazon SNS
MemoryDB peut publier des messages à l'aide d'Amazon Simple Notification Service (SNS) lorsque des événements importants se produisent sur un cluster. Cette fonctionnalité peut être utilisée pour actualiser les listes de serveurs sur les machines clientes connectées aux points de terminaison des nœuds individuels d'un cluster.
**Note**
Pour plus d'informations sur Amazon Simple Notification Service (SNS), y compris des informations sur la tarification et des liens vers la documentation Amazon SNS, veuillez consulter [Page produit Amazon SNS](https://aws.amazon.com/sns).
Les notifications sont publiées sur une *rubrique* Amazon SNS spécifiée. Ci-après les exigences concernant les notifications :
+ Un seul sujet peut être configuré pour les notifications MemoryDB.
+ Le AWS compte propriétaire de la rubrique Amazon SNS doit être le même que celui qui possède le cluster sur lequel les notifications sont activées.
## Evénements MemoryDB
Les événements MemoryDB suivants déclenchent les notifications Amazon SNS :
| Nom de l'événement | Message | Description |
| --- | --- | --- |
| Base de données de mémoire : AddNodeComplete | "Modified number of nodes from %d to %d" | Un nœud a été ajouté au cluster et est prêt à être utilisé. |
| MemoryDB : AddNodeFailed en raison d'un nombre insuffisant d'adresses IP libres | "Failed to modify number of nodes from %d to %d due to insufficient free IP addresses" | Impossible d'ajouter un nœud car il n'y a pas suffisamment d'adresses IP disponibles. |
| Base de données de mémoire : ClusterParametersChanged | "Updated parameter group for the cluster" Dans le cas d'une création, envoyez également `"Updated to use a ParameterGroup %s"` | Un ou plusieurs paramètres de cluster ont été modifiés. |
| Base de données de mémoire : ClusterProvisioningComplete | "Cluster created." | Le provisionnement d'un cluster est terminé et les nœuds du cluster sont prêts à être utilisés. |
| MemoryDB : ClusterProvisioningFailed en raison d'un état réseau incompatible | "Failed to create cluster due to incompatible network state. %s" | Une tentative a été faite pour lancer un nouveau cluster dans un cloud privé virtuel (VPC) inexistant. |
| Base de données de mémoire : ClusterRestoreFailed | "Restore from %s failed for node %s. %s" | MemoryDB n'a pas pu remplir le cluster avec des données de capture instantanée. Cela peut être dû à un fichier instantané inexistant dans Amazon S3 ou à des autorisations incorrectes sur ce fichier. Si vous décrivez le cluster, son statut sera`restore-failed`. Vous devrez supprimer le cluster et recommencer à zéro. Pour de plus amples informations, veuillez consulter [Création d'un nouveau cluster avec un instantané créé en externe](snapshots-seeding-redis.md). |
| Base de données de mémoire : ClusterScalingComplete | `"Succeeded applying modification to node type to %s."` | Mise à l'échelle pour que le cluster soit terminé avec succès. |
| Base de données de mémoire : ClusterScalingFailed | `"Failed applying modification to node type to %s."` | L'opération de mise à l'échelle sur le cluster a échoué. |
| Base de données de mémoire : NodeReplaceStarted | "Recovering node %s" | MemoryDB a détecté que l'hôte exécutant un nœud est dégradé ou inaccessible et a commencé à remplacer le nœud. L'entrée DNS du nœud remplacé n'est pas modifiée. Dans la plupart des cas, vous n'aurez pas besoin d'actualiser la liste des serveurs pour vos clients lorsque cet événement se produit. Cependant, certaines bibliothèques clientes peuvent cesser d'utiliser le nœud même après que MemoryDB l'ait remplacé ; dans ce cas, l'application doit actualiser la liste des serveurs lorsque cet événement se produit. |
| Base de données de mémoire : NodeReplaceComplete | "Finished recovery for node %s" | MemoryDB a détecté que l'hôte exécutant un nœud est dégradé ou inaccessible et a terminé de remplacer le nœud. L'entrée DNS du nœud remplacé n'est pas modifiée. Dans la plupart des cas, vous n'aurez pas besoin d'actualiser la liste des serveurs pour vos clients lorsque cet événement se produit. Cependant, certaines bibliothèques clientes peuvent cesser d'utiliser le nœud même après que MemoryDB l'ait remplacé ; dans ce cas, l'application doit actualiser la liste des serveurs lorsque cet événement se produit. |
| Base de données de mémoire : CreateClusterComplete | "Cluster created" | Le cluster a été créé avec succès. |
| Base de données de mémoire : CreateClusterFailed | "Failed to create cluster due to unsuccessful creation of its node(s)." et "Deleting all nodes belonging to this cluster." | Le cluster n'a pas été créé. |
| Base de données de mémoire : DeleteClusterComplete | "Cluster deleted." | La suppression d'un cluster et de tous les nœuds associés est terminée. |
| Base de données de mémoire : FailoverComplete | `"Failover to replica node %s completed"` | Basculement vers un nœud du réplica réussi. |
| Base de données de mémoire : NodeReplacementCanceled | "The replacement of node %s which was scheduled during the maintenance window from start time: %s, end time: %s has been canceled" | Le remplacement d'un nœud de votre cluster qui était prévu a été annulé. |
| Base de données de mémoire : 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" | Le remplacement d'un nœud de cluster a été reprogrammé dans le créneau indiqué dans la notification. Pour plus d'informations sur les actions que vous pouvez effectuer, consultez [Remplacement de nœuds](nodes.nodereplacement.md). |
| Base de données de mémoire : NodeReplacementScheduled | "The node %s is scheduled for replacement during the maintenance window from start time: %s to end time: %s" | Un nœud du cluster doit être remplacé pendant le créneau décrit dans la notification. Pour plus d'informations sur les actions que vous pouvez effectuer, consultez [Remplacement de nœuds](nodes.nodereplacement.md). |
| Base de données de mémoire : RemoveNodeComplete | "Removed node %s" | Un nœud a été supprimé du cluster. |
| Base de données de mémoire : SnapshotComplete | "Snapshot %s succeeded for node %s" | Un instantané s'est terminé avec succès. |
| Base de données de mémoire : SnapshotFailed | "Snapshot %s failed for node %s" | Un instantané a échoué. Consultez les événements du cluster pour une cause plus détaillée. Si vous décrivez l'instantané, consultez [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html), l'état sera `failed`. |
# Journalisation des appels d'API MemoryDB avec AWS CloudTrail
MemoryDB est intégré à AWS CloudTrail un service qui fournit un enregistrement des actions entreprises par un utilisateur, un rôle ou un AWS service dans MemoryDB. CloudTrail capture tous les appels d'API pour MemoryDB sous forme d'événements, y compris les appels depuis la console MemoryDB et les appels de code vers les opérations de l'API MemoryDB. Si vous créez un suivi, vous pouvez activer la diffusion continue d' CloudTrail événements vers un compartiment Amazon S3, y compris des événements pour MemoryDB. Si vous ne configurez pas de suivi, vous pouvez toujours consulter les événements les plus récents dans la CloudTrail console dans **Historique des événements**. À l'aide des informations collectées par CloudTrail, vous pouvez déterminer la demande qui a été faite à MemoryDB, l'adresse IP à partir de laquelle la demande a été faite, qui a fait la demande, quand elle a été faite et des détails supplémentaires.
Pour en savoir plus CloudTrail, consultez le [guide de AWS CloudTrail l'utilisateur](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## Informations MemoryDB dans CloudTrail
CloudTrail est activé sur votre AWS compte lorsque vous le créez. **Lorsqu'une activité se produit dans MemoryDB, cette activité est enregistrée dans un CloudTrail événement avec d'autres événements de AWS service dans l'historique des événements.** Vous pouvez consulter, rechercher et télécharger les événements récents dans votre AWS compte. Pour plus d'informations, consultez la section [Affichage des événements à l'aide de l'historique des CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Pour un enregistrement continu des événements de votre AWS compte, y compris des événements relatifs à MemoryDB, créez une trace. Un suivi permet CloudTrail de fournir des fichiers journaux à un compartiment Amazon S3. Par défaut, lorsque vous créez un journal d’activité dans la console, il s’applique à toutes les régions. Le journal enregistre les événements de toutes les régions de la AWS partition et transmet les fichiers journaux au compartiment Amazon S3 que vous spécifiez. En outre, vous pouvez configurer d'autres AWS services pour analyser plus en détail les données d'événements collectées dans les CloudTrail journaux et agir en conséquence. Pour plus d’informations, consultez les ressources suivantes :
+ [Vue d’ensemble de la création d’un journal d’activité](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Services et intégrations pris en charge](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuration des notifications Amazon SNS pour CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Réception de fichiers CloudTrail journaux de plusieurs régions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) et [réception de fichiers CloudTrail journaux de plusieurs comptes](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Toutes les actions de MemoryDB sont enregistrées par. CloudTrail Par exemple, les appels au`CreateCluster`, `DescribeClusters` et les `UpdateCluster` actions génèrent des entrées dans les fichiers CloudTrail journaux.
Chaque événement ou entrée de journal contient des informations sur la personne ayant initié la demande. Les informations relatives à l’identité permettent de déterminer les éléments suivants :
+ Si la demande a été effectuée avec des informations d’identification d’utilisateur root ou IAM.
+ Si la demande a été effectuée avec des informations d’identification de sécurité temporaires pour un rôle ou un utilisateur fédéré.
+ Si la demande a été faite par un autre AWS service.
Pour plus d’informations, consultez la section [Élément userIdentity CloudTrail ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Comprendre les entrées du fichier journal MemoryDB
Un suivi est une configuration qui permet de transmettre des événements sous forme de fichiers journaux à un compartiment Amazon S3 que vous spécifiez. CloudTrail les fichiers journaux contiennent une ou plusieurs entrées de journal. Un événement représente une demande unique provenant de n'importe quelle source et inclut des informations sur l'action demandée, la date et l'heure de l'action, les paramètres de la demande, etc. CloudTrail les fichiers journaux ne constituent pas une trace ordonnée des appels d'API publics, ils n'apparaissent donc pas dans un ordre spécifique.
L'exemple suivant montre une entrée de CloudTrail journal illustrant l'`CreateCluster`action.
```
{
"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"
}
```
L'exemple suivant montre une entrée de CloudTrail journal illustrant l'`DescribeClusters`action. Notez que pour tous les appels MemoryDB Describe et List (`Describe*`et`List*`), la `responseElements` section est supprimée et apparaît sous la forme. `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"
}
```
L'exemple suivant montre une entrée de CloudTrail journal qui enregistre une `UpdateCluster` action.
```
{
"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"
}
```
L'exemple suivant montre une entrée de CloudTrail journal illustrant l'`CreateUser`action. Notez que pour les appels MemoryDB contenant des données sensibles, ces données seront supprimées lors de l' CloudTrail événement correspondant, comme indiqué dans la `requestParameters` section ci-dessous.
```
{
"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"
}
```