

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.

# 
<a name="CHAP_Monitor_Logs_Events"></a>

Lorsque vous surveillez vos bases de données Amazon RDS et vos autres AWS solutions, votre objectif est de maintenir les points suivants :
+ Fiabilité
+ Disponibilité
+ Performance
+ Sécurité

[Surveillance des métriques dans une instance Amazon RDS](CHAP_Monitoring.md) explique la surveillance de votre instance à l’aide de métriques. Une solution complète doit également surveiller les événements de base de données, les fichiers journaux et les flux d'activité. AWS met à votre disposition les outils de surveillance suivants :
+ *Amazon EventBridge* est un service de bus d'événements sans serveur qui permet de connecter facilement vos applications à des données provenant de diverses sources. EventBridge fournit un flux de données en temps réel à partir de vos propres applications, applications Software-as-a-Service (SaaS) et AWS services. EventBridge achemine ces données vers des cibles telles que AWS Lambda. Cela vous permet de surveiller les événements qui se produisent dans les services et de créer des architectures basées sur les événements. Pour plus d'informations, consultez le [guide de EventBridge l'utilisateur Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/).
+ *Amazon CloudWatch Logs* fournit un moyen de surveiller, de stocker et d'accéder à vos fichiers journaux à partir d'Amazon RDS AWS CloudTrail, d'instances et d'autres sources. Amazon CloudWatch Logs peut 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 connexes effectués par ou pour votre compte Compte AWS. CloudTrail fournit 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/).
+ *Database Activity Streams* est une fonctionnalité Amazon RDS qui fournit un flux en temps quasi réel de l’activité dans votre instance de base de données. Amazon RDS envoie les activités vers un flux de données Amazon Kinesis. Le flux Kinesis est créé automatiquement. Kinesis vous permet de configurer des AWS services tels qu'Amazon Data Firehose, de consommer le flux et AWS Lambda de stocker les données.

**Topics**
+ [Affichage des journaux, des événements et des flux dans la console Amazon RDS](logs-events-streams-console.md)
+ [Surveillance des événements Amazon RDS](working-with-events.md)
+ [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md)
+ [Surveillance des appels d'API Amazon RDS dansAWS CloudTrail](logging-using-cloudtrail.md)
+ [Surveillance d’Amazon RDS à l’aide des flux d’activité de base de données](DBActivityStreams.md)
+ [Surveillance des menaces avec Amazon GuardDuty RDS Protection](guard-duty-rds-protection.md)

# Affichage des journaux, des événements et des flux dans la console Amazon RDS
<a name="logs-events-streams-console"></a>

Amazon RDS s'intègre Services AWS pour afficher des informations sur les journaux, les événements et les flux d'activité des bases de données dans la console RDS.

L’onglet **Logs & events** (Journaux et événements) de votre instance RDS affiche les informations suivantes :
+ ** CloudWatch Alarmes Amazon** : affiche toutes les alarmes métriques que vous avez configurées pour l'instance de base . Si vous n’avez pas configuré d’alarmes, vous pouvez les créer dans la console RDS. Pour plus d’informations, consultez [Surveillance des métriques Amazon RDS () avec Amazon CloudWatch](monitoring-cloudwatch.md). 
+ **Événements récents** : affiche un récapitulatif des événements (changements d’environnement) pour votre instance RDS. Pour plus d’informations, consultez [Affichage d’événements Amazon RDS](USER_ListEvents.md).
+ **Journaux** : affiche les fichiers journaux de base de données générés par une instance de base de données . Pour plus d’informations, consultez [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md).

L’onglet **Configuration** (Configuration) affiche des informations sur les flux d’activité de base de données.

**Pour afficher les journaux, les événements et les flux de votre d'instances de base de données dans la console RDS**

1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.

1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**.

1. Sélectionnez le nom du d’instances de base de données que vous souhaitez surveiller.

   La page Bases de données s’affiche. L’exemple suivant illustre une base de données Oracle nommée `orclb`.  
![\[Page de la base de données avec l’onglet de surveillance affiché\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/oracle-with-monitoring-tab.png)

1. Choisissez **Logs & events** (Journaux et événements).

   La section Logs & events (Journaux et événements) et événements s’affiche.  
![\[Page de la base de données avec l’onglet Logs & events (Journaux et événements) affiché\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/oracle-logs-and-events-subpage.png)

1. Choisissez **Configuration**.

   L’exemple suivant montre l’état des flux d’activité de base de données pour votre instance de base de données.  
![\[Surveillance améliorée\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/oracle-das.png)

# Surveillance des événements Amazon RDS
<a name="working-with-events"></a>

Un *événement* indique un changement dans un environnement. Il peut s’agir d’un environnement AWS, d’un service partenaire ou d’une application SaaS, ou d’une application ou d’un service personnalisé. Pour obtenir la description des événements RDS, consultez [Catégories d'événements Amazon RDS et messages d'événements ](USER_Events.Messages.md).

**Topics**
+ [Présentation des événements pour Amazon RDS](#rds-cloudwatch-events.sample)
+ [Affichage d’événements Amazon RDS](USER_ListEvents.md)
+ [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md)
+ [Création d’une règle qui se déclenche sur un événement Amazon RDS](rds-cloud-watch-events.md)
+ [Catégories d'événements Amazon RDS et messages d'événements](USER_Events.Messages.md)

## Présentation des événements pour Amazon RDS
<a name="rds-cloudwatch-events.sample"></a>

Un *événement RDS* indique un changement dans l’environnement Amazon RDS. Par exemple, Amazon RDS génère un événement quand une instance de base de données passe de l'état d'attente à l'état en cours d'exécution. Amazon RDS fournit des événements à EventBridge en quasi-temps réel.

**Note**  
Amazon RDS émet les événements dans la mesure du possible. Nous vous recommandons d’éviter d’écrire des programmes en fonction de la présence d’événements de notification ou de leur ordre, car il peut ne pas y en avoir ou ils peuvent ne pas être dans l’ordre défini.

Amazon RDS enregistre les événements qui concernent les ressources suivantes :
+ Instances DB

  Pour obtenir une liste des événements d'instance de base de données, consultez [Événements d’instance de base de données](USER_Events.Messages.md#USER_Events.Messages.instance).
+ Groupes de paramètres de base de données

  Pour obtenir une liste des événements de groupe de paramètres de base de données, consultez [Événements de groupe de paramètres de base de données](USER_Events.Messages.md#USER_Events.Messages.parameter-group).
+ Groupes de sécurité DB

  Pour obtenir la liste des événements relatifs aux groupes de sécurité de la base de données, consultez [Événements de groupe de sécurité de base de données](USER_Events.Messages.md#USER_Events.Messages.security-group).
+ Instantanés de la base de données

  Pour obtenir la liste des événements liés aux instantanés de la base de données, consultez [Événements d’instantané de bases de données](USER_Events.Messages.md#USER_Events.Messages.snapshot).
+ Événements RDS Proxy

  Pour obtenir une liste des événements RDS Proxy, consultez [Événements RDS Proxy](USER_Events.Messages.md#USER_Events.Messages.rds-proxy).
+ Événements de déploiement bleu/vert

  Pour obtenir la liste des événements de déploiement bleu/vert, consultez [Événements de déploiement bleu/vert](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments).

Les informations collectées sont les suivantes : 
+ Date et heure de l’événement.
+ Nom de la source et type de source de l’événement
+ Message associé à l'événement
+ Les notifications d'événements incluent des balises datant du moment où le message a été envoyé et peuvent ne pas refléter les balises au moment où l'événement s'est produit.

# Affichage d’événements Amazon RDS
<a name="USER_ListEvents"></a>

Vous pouvez récupérer les informations suivantes sur les événements pour vos ressources Amazon RDS :
+ Nom de la ressource
+ Type de ressource
+ Heure de l'événement
+ Résumé du message de l'événement

Vous pouvez accéder aux événements dans les sections suivantes de la AWS Management Console :
+ L’onglet **Événements**, qui affiche les événements des 24 dernières heures.
+ Le tableau **Événements récents** de la section **Journaux et événements** de l’onglet **Bases de données**, qui peut afficher les événements survenus au cours des deux dernières semaines.

Vous pouvez également récupérer les événements en utilisant la commande AWS CLI [describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html), ou l'opération [DescribeEvents](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEvents.html) de l'API RDS. Si vous utilisez l'AWS CLI ou l'API RDS pour afficher les événements, vous pouvez récupérer les événements datant de 14 jours maximum. 

**Note**  
Si vous devez stocker des événements pendant des périodes plus longues, vous pouvez envoyer des événements Amazon RDS à EventBridge. Pour plus d’informations, consultez [Création d’une règle qui se déclenche sur un événement Amazon RDS](rds-cloud-watch-events.md).

Pour la description des événements Amazon RDS, consultez [Catégories d'événements Amazon RDS et messages d'événements ](USER_Events.Messages.md).

Pour accéder à des informations détaillées sur les événements utilisant AWS CloudTrail, y compris les paramètres de requête, consultez [Événements CloudTrail](logging-using-cloudtrail.md#service-name-info-in-cloudtrail.events).

## Console
<a name="USER_ListEvents.CON"></a>

**Pour voir tous les événements Amazon RDS des dernières 24 heures**

1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, sélectionnez **Events**. 

   Les événements disponibles s’affichent sous forme de liste.

1. (Facultatif) Entrez un terme de recherche pour filtrer vos résultats. 

   L'exemple suivant montre une liste d'événements filtrés par les caractères **stopped**.  
![\[Répertorier les événements de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/ListEvents.png)

## AWS CLI
<a name="USER_ListEvents.CLI"></a>

Pour afficher tous les événements générés au cours de la dernière heure, appelez la commande [describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html) sans paramètres.

```
aws rds describe-events
```

L'exemple de sortie suivant montre qu'une instance de base de données a été arrêtée.

```
{
    "Events": [
        {
            "EventCategories": [
                "notification"
            ], 
            "SourceType": "db-instance", 
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:testinst", 
            "Date": "2022-04-22T21:31:00.681Z", 
            "Message": "DB instance stopped", 
            "SourceIdentifier": "testinst"
        }
    ]
}
```

Pour afficher tous les événements Amazon RDS des 10 080 dernières minutes (sept jours), appelez la commande AWS CLI [describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html) et définissez le paramètre `--duration` sur `10080`.

```
1. aws rds describe-events --duration 10080
```

L'exemple suivant montre les événements dans la plage de temps spécifiée pour l'instance de base de données *test-instance*.

```
aws rds describe-events \
    --source-identifier test-instance \
    --source-type db-instance \
    --start-time 2022-03-13T22:00Z \
    --end-time 2022-03-13T23:59Z
```

L'exemple de sortie suivant montre l'état d'une sauvegarde.

```
{
    "Events": [
        {
            "SourceType": "db-instance",
            "SourceIdentifier": "test-instance",
            "EventCategories": [
                "backup"
            ],
            "Message": "Backing up DB instance",
            "Date": "2022-03-13T23:09:23.983Z",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:test-instance"
        },
        {
            "SourceType": "db-instance",
            "SourceIdentifier": "test-instance",
            "EventCategories": [
                "backup"
            ],
            "Message": "Finished DB Instance backup",
            "Date": "2022-03-13T23:15:13.049Z",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:test-instance"
        }
    ]
}
```

## « Hello, World\$1 »
<a name="USER_ListEvents.API"></a>

Vous pouvez afficher tous les événements des instances Amazon RDS des 14 derniers jours en appelant l’opération d’API RDS [DescribeEvents](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEvents.html) et en définissant le paramètre `Duration` sur `20160`.

# Utiliser la notification d'événements d'Amazon RDS
<a name="USER_Events"></a>

Amazon RDS utilise Amazon Simple Notification Service (Amazon SNS) pour adresser une notification lorsqu’un événement Amazon RDS se produit. Ces notifications peuvent être faites sous n’importe quelle forme prise en charge par Amazon SNS pour une région AWS, telle qu’un e-mail, un SMS ou un appel à un point de terminaison HTTP. 

**Topics**
+ [Présentation des notifications d’événements Amazon RDS.](USER_Events.overview.md)
+ [Octroi d’autorisations de publication de notifications dans une rubrique Amazon SNS](USER_Events.GrantingPermissions.md)
+ [Abonnement à la notification d’événement Amazon RDS](USER_Events.Subscribing.md)
+ [Balises et attributs de notifications d’événements Amazon RDS](USER_Events.TagsAttributesForFiltering.md)
+ [Liste des abonnements aux notifications d’événements Amazon RDS](USER_Events.ListSubscription.md)
+ [Modification d’un abonnement aux notifications d’événements Amazon RDS](USER_Events.Modifying.md)
+ [Ajout d’un identifiant source à un abonnement aux notifications d’événements Amazon RDS](USER_Events.AddingSource.md)
+ [Suppression d’un identifiant source d’un abonnement aux notifications d’événements Amazon RDS](USER_Events.RemovingSource.md)
+ [Affichage des catégories aux notifications d’événements Amazon RDS](USER_Events.ListingCategories.md)
+ [Suppression d’un abonnement aux notifications d’événements Amazon RDS](USER_Events.Deleting.md)

# Présentation des notifications d’événements Amazon RDS.
<a name="USER_Events.overview"></a>

Amazon RDS regroupe les événements en catégories auxquelles vous pouvez vous abonner afin d’être informé lorsqu’un événement de cette catégorie se produit.

**Topics**
+ [Ressources RDS éligibles à l’abonnement à un événement](#USER_Events.overview.resources)
+ [Procédure de base pour s’abonner aux notifications d’événement Amazon RDS](#USER_Events.overview.process)
+ [Livraison des notifications d’événements RDS](#USER_Events.overview.subscriptions)
+ [Facturation des notifications d’événement Amazon RDS](#USER_Events.overview.billing)
+ [Exemples d'événements Amazon RDS à l'aide d'Amazon EventBridge](#events-examples)

## Ressources RDS éligibles à l’abonnement à un événement
<a name="USER_Events.overview.resources"></a>

Vous pouvez vous abonner à une catégorie d’événement pour les ressources suivantes :
+ instance de base de données
+ Snapshot DB
+ Groupe de paramètres de base de données
+ Groupe de sécurité de base de données
+ RDS Proxy (Proxy RDS)
+ Versions de moteur personnalisées

Par exemple, si vous vous abonnez à la catégorie de sauvegarde d’une instance de base de données donnée, vous recevez une notification chaque fois que survient un événement lié à la sauvegarde et qui affecte l’instance de base de données. Si vous vous abonnez à la catégorie de modification de configuration pour une instance de base de données, vous recevez une notification en cas de modification de l’instance de base de données. Vous recevez également une notification en cas de modification d’un abonnement à une notification d’événements.

Vous pouvez créer plusieurs abonnements différents. Par exemple, vous pouvez vouloir créer un abonnement qui reçoit toutes les notifications d’événements pour l’ensemble des instances de base de données, et un autre incluant uniquement les événements critiques pour un sous-ensemble des instances de base de données. Pour le deuxième abonnement, spécifiez une ou plusieurs instances de base de données dans le filtre.

## Procédure de base pour s’abonner aux notifications d’événement Amazon RDS
<a name="USER_Events.overview.process"></a>

La procédure d’abonnement à une notification d’événement Amazon RDS est la suivante :

1. Vous créez un abonnement aux notifications d'événements Amazon RDS à l'aide de la console Amazon RDS AWS CLI, ou API.

   Amazon RDS utilise l’ARN d’une rubrique Amazon SNS pour identifier chaque abonnement. La console Amazon RDS crée l’ARN lorsque vous créez l’abonnement. Créez l'ARN à l'aide de la console Amazon SNS, de ou de l' AWS CLI API Amazon SNS.

1. Amazon RDS envoie un e-mail d’approbation ou un SMS aux adresses que vous avez fournies avec votre abonnement.

1. Pour confirmer votre abonnement, cliquez sur le lien dans la notification que vous avez reçue.

1. La console Amazon RDS met à jour la section **My Event Subscriptions** (Mes abonnements aux événements) avec le statut de votre abonnement.

1. Amazon RDS commence à envoyer les notifications aux adresses que vous avez fournies lors de la création de l’abonnement.

Pour en savoir plus sur la gestion des identités et des accès lors de l’utilisation d’Amazon SNS, consultez [Gestion des identités et des accès dans Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-authentication-and-access-control.html) dans le *Guide du développeur Amazon Simple Notification Service*.

Vous pouvez l'utiliser AWS Lambda pour traiter les notifications d'événements provenant d'une instance de base de données. Pour plus d'informations, consultez la section [Utilisation AWS Lambda avec Amazon RDS](https://docs.aws.amazon.com/lambda/latest/dg/services-rds.html) dans le *manuel du AWS Lambda développeur*.

## Livraison des notifications d’événements RDS
<a name="USER_Events.overview.subscriptions"></a>

Amazon RDS envoie les notifications d’événements aux adresses que vous fournissez lorsque vous créez l’abonnement. La notification peut inclure des attributs de message fournissant des métadonnées structurées relatives au message. Pour plus d’informations sur les attributs de message, consultez [Catégories d'événements Amazon RDS et messages d'événements ](USER_Events.Messages.md).

Les notifications d’événement peuvent prendre jusqu’à cinq minutes pour être livrées.

**Important**  
Amazon RDS ne garantie pas l’ordre des événements envoyés dans un flux d’événements. L’ordre des événements est susceptible de changer.

Lorsqu’Amazon SNS envoie une notification à un point de terminaison HTTP ou HTTPS abonné, le corps du message POST envoyé au point de terminaison contient un document JSON. Pour plus d’informations, consultez [Formats de message et JSON Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-message-and-json-formats.html) dans le *Manuel du développeur Amazon Simple Notification Service*.

Vous pouvez configurer SNS pour vous avertir avec des messages texte. Pour plus d’informations, consultez [SMS](https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-phone-number-as-subscriber.html) dans le *Guide du développeur Amazon Simple Notification Service*.

Pour désactiver les notifications sans supprimer un abonnement, sélectionnez **Non** pour **Activé** dans la console Amazon RDS. Vous pouvez également définir le `Enabled` paramètre à `false` l'aide de l'API AWS CLI ou Amazon RDS.

## Facturation des notifications d’événement Amazon RDS
<a name="USER_Events.overview.billing"></a>

La facturation de la notification d’événement Amazon RDS s’effectue via Amazon SNS. Des frais Amazon SNS s’appliquent en cas d’utilisation de la notification d’événement. Pour plus d’informations sur la tarification Amazon SNS, consultez [Tarification Amazon Simple Notification Service](https://aws.amazon.com/sns/#pricing).

## Exemples d'événements Amazon RDS à l'aide d'Amazon EventBridge
<a name="events-examples"></a>

Les exemples suivants illustrent différents types d’événements Amazon RDS au format JSON. Pour accéder à un tutoriel qui vous montre comment capturer et afficher les événements au format JSON, consultez [Tutoriel : Consigner les modifications de l'état d'une instance de base de données à l'aide EventBridge](rds-cloud-watch-events.md#log-rds-instance-state).

**Topics**
+ [Exemple d’événement d’instance de base de données](#rds-cloudwatch-events.db-instances)
+ [Exemple d’événement de groupe de paramètres de base de données](#rds-cloudwatch-events.db-parameter-groups)
+ [Exemple d’événement d’instantané de base de données](#rds-cloudwatch-events.db-snapshots)

### Exemple d’événement d’instance de base de données
<a name="rds-cloudwatch-events.db-instances"></a>

Voici un exemple d’événement d’instance de base de données au format JSON. L’événement montre que RDS a effectué un basculement multi-AZ pour l’instance nommée `my-db-instance`. L’ID de l’événement est RDS-EVENT-0049.

```
{
  "version": "0",
  "id": "68f6e973-1a0c-d37b-f2f2-94a7f62ffd4e",
  "detail-type": "RDS DB Instance Event",
  "source": "aws.rds",
  "account": "123456789012",
  "time": "2018-09-27T22:36:43Z",
  "region": "us-east-1",
  "resources": [
    "arn:aws:rds:us-east-1:123456789012:db:my-db-instance"
  ],
  "detail": {
    "EventCategories": [
      "failover"
    ],
    "SourceType": "DB_INSTANCE",
    "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:my-db-instance",
    "Date": "2018-09-27T22:36:43.292Z",
    "Message": "A Multi-AZ failover has completed.",
    "SourceIdentifier": "my-db-instance",
    "EventID": "RDS-EVENT-0049"
  }
}
```

### Exemple d’événement de groupe de paramètres de base de données
<a name="rds-cloudwatch-events.db-parameter-groups"></a>

Voici un exemple d’événement de groupe de paramètres de base de données au format JSON. L’événement indique que le paramètre `time_zone` a été mis à jour dans le groupe de paramètres `my-db-param-group`. L’ID de l’événement est RDS-EVENT-0037.

```
{
  "version": "0",
  "id": "844e2571-85d4-695f-b930-0153b71dcb42",
  "detail-type": "RDS DB Parameter Group Event",
  "source": "aws.rds",
  "account": "123456789012",
  "time": "2018-10-06T12:26:13Z",
  "region": "us-east-1",
  "resources": [
    "arn:aws:rds:us-east-1:123456789012:pg:my-db-param-group"
  ],
  "detail": {
    "EventCategories": [
      "configuration change"
    ],
    "SourceType": "DB_PARAM",
    "SourceArn": "arn:aws:rds:us-east-1:123456789012:pg:my-db-param-group",
    "Date": "2018-10-06T12:26:13.882Z",
    "Message": "Updated parameter time_zone to UTC with apply method immediate",
    "SourceIdentifier": "my-db-param-group",
    "EventID": "RDS-EVENT-0037"
  }
}
```

### Exemple d’événement d’instantané de base de données
<a name="rds-cloudwatch-events.db-snapshots"></a>

Voici un exemple d’événement d’instantané de bases de données au format JSON. L’événement montre la suppression de l’instantané nommé `my-db-snapshot`. L’ID de l’événement est RDS-EVENT-0041.

```
{
  "version": "0",
  "id": "844e2571-85d4-695f-b930-0153b71dcb42",
  "detail-type": "RDS DB Snapshot Event",
  "source": "aws.rds",
  "account": "123456789012",
  "time": "2018-10-06T12:26:13Z",
  "region": "us-east-1",
  "resources": [
    "arn:aws:rds:us-east-1:123456789012:snapshot:rds:my-db-snapshot"
  ],
  "detail": {
    "EventCategories": [
      "deletion"
    ],
    "SourceType": "SNAPSHOT",
    "SourceArn": "arn:aws:rds:us-east-1:123456789012:snapshot:rds:my-db-snapshot",
    "Date": "2018-10-06T12:26:13.882Z",
    "Message": "Deleted manual snapshot",
    "SourceIdentifier": "my-db-snapshot",
    "EventID": "RDS-EVENT-0041"
  }
}
```

# Octroi d’autorisations de publication de notifications dans une rubrique Amazon SNS
<a name="USER_Events.GrantingPermissions"></a>

Pour autoriser Amazon RDS à publier des notifications sur une rubrique Amazon Simple Notification Service (Amazon SNS), associez une politique Gestion des identités et des accès AWS (IAM) à la rubrique de destination. Pour plus d’informations sur les autorisations, consultez [Exemples de cas pour le contrôle d’accès Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/sns-access-policy-use-cases.html) dans le *Guide du développeur Amazon Simple Notification Service*.

Par défaut, une rubrique Amazon SNS dispose d’une politique permettant à toutes les ressources Amazon RDS d’un même compte d’y publier des notifications. Vous pouvez attacher une politique personnalisée pour autoriser les notifications entre comptes ou pour restreindre l’accès à certaines ressources.

Voici un exemple de politique IAM que vous attachez à la rubrique Amazon SNS de destination. Il limite la rubrique aux instances de base de données dont les noms correspondent au préfixe spécifié. Pour utiliser cette politique, spécifiez les valeurs suivantes :
+ `Resource` : Amazon Resource Name (ARN) de votre rubrique Amazon SNS
+ `SourceARN` : ARN de votre ressource RDS
+ `SourceAccount`— Votre Compte AWS identifiant

Pour consulter la liste des types de ressources et leurs caractéristiques ARNs, consultez la section [Ressources définies par Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-resources-for-iam-policies) dans le *Service Authorization Reference*.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.rds.amazonaws.com"
      },
      "Action": [
        "sns:Publish"
      ],
      "Resource": "arn:aws:sns:us-east-1:123456789012:topic_name",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:rds:us-east-1:123456789012:db:prefix-*"
        },
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        }
      }
    }
  ]
}
```

------

# Abonnement à la notification d’événement Amazon RDS
<a name="USER_Events.Subscribing"></a>

La solution la plus simple pour créer un abonnement consiste à utiliser la console RDS. Si vous choisissez de créer un abonnement à une notification d’événement à l’aide de la CLI ou de l’API, vous devez créer une rubrique Amazon Simple Notification Service et vous abonner à cette rubrique avec la console Amazon SNS ou l’API Amazon SNS. Vous devrez également conserver l'Amazon Resource Name (ARN) de la rubrique, car il est utilisé lors de la soumission de commandes de la CLI ou d'opérations d'API. Pour plus d’informations sur la création d’une rubrique SNS et sur l’abonnement à cette rubrique, consultez [Mise en route d’Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.html) dans le *Manuel du développeur d’Amazon Simple Notification Service*.

Vous pouvez spécifier le type de source dont vous voulez être informé et la source Amazon RDS qui déclenche l’événement :

**Source type** (Type de source)  
Type de source. Par exemple, **Source Type** (Type de source) pourrait être **Instances**. Vous devez choisir un type de source.

***Ressources* à inclure**  
Les ressources Amazon RDS qui génèrent les événements. Par exemple, vous pouvez choisir **Select specific instances** (Sélectionner des instances spécifiques), puis **myDBInstance1**. 

Le tableau suivant montre le résultat lorsque vous spécifiez ou ne spécifiez pas les ***ressources* à inclure**.


|  Ressources à inclure  |  Description  |  exemple  | 
| --- | --- | --- | 
|  Spécifié  |  RDS vous notifie de tous les événements pour la ressource spécifiée uniquement.  | Si votre Source type (Type de source) est Instances et que votre ressource est myDBInstance1, RDS vous notifie tous les événements pour myDBInstance1 uniquement. | 
|  Non spécifiée  |  RDS vous notifie les événements pour le type de source spécifié pour toutes vos ressources Amazon RDS.   |  Si votre **Source type** (Type de source) est **Instances**, RDS vous notifie tous les événements liés aux instances dans votre compte.  | 

Par défaut, un abonné d'une rubrique Amazon SNS reçoit chaque message publié dans la rubrique. Pour recevoir uniquement un sous-ensemble des messages, l'abonné doit attribuer une politique de filtre à l'abonnement à la rubrique. Pour plus d'informations sur le filtrage des messages SNS, consultez [Filtrage des messages Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-message-filtering.html) dans le *Guide du développeur Amazon Simple Notification Service*.

## Console
<a name="USER_Events.Subscribing.Console"></a>

**Pour s’abonner à la notification d’événement RDS**

1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Abonnements aux événements**. 

1. Dans le volet **Abonnements aux événements**, choisissez **Créer un abonnement aux événements**. 

1. Entrez les détails de votre abonnement comme suit :

   1. Dans le champ **Nom**, entrez un nom pour l'abonnement à la notification d'événements.

   1. Pour **Send notification to:** (Envoyer les notifications à), effectuez l'une des opérations suivantes :
      + Choisissez **New email topic** (Nouvelle rubrique d'e-mail). Saisissez un nom pour votre rubrique d'e-mail et une liste de bénéficiaires. Nous vous recommandons de configurer les abonnements aux événements sur la même adresse e-mail que celle du contact principal de votre compte. Les recommandations, les événements de service et les messages de santé personnels sont envoyés via différents canaux. Les abonnements sur la même adresse e-mail garantissent que tous les messages sont regroupés en un seul endroit.
      + Choisissez **Amazon Resource Name (ARN)**. Choisissez ensuite l'ARN Amazon SNS existant pour une rubrique Amazon SNS.

        Si vous souhaitez utiliser une rubrique pour laquelle le chiffrement côté serveur (SSE) a été activé, accordez à Amazon RDS les autorisations nécessaires pour accéder à la AWS KMS key. Pour en savoir plus, consultez [Activer la compatibilité entre des sources d'événements à partir de services AWS et de rubriques chiffrées](https://docs.aws.amazon.com/sns/latest/dg/sns-key-management.html#compatibility-with-aws-services) dans le *Guide du développeur Amazon Simple Notification Service*.

   1. Pour **Type de source**, choisissez un type de source. Par exemple, choisissez **Instances** ou **Parameter groups** (Groupes de paramètres) (Instantanés de clusters).

   1. Choisissez les catégories d'événements et les ressources pour lesquelles vous souhaitez recevoir des notifications d'événements.

      L'exemple suivant configure les notifications d'événements pour l'instance de base de données nommée `testinst`.  
![\[Entrer le type de source\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/event-source.png)

   1. Choisissez **Créer**.

La console Amazon RDS indique que l'abonnement est en cours de création.

![\[Répertorier les abonnements aux notifications d’événements de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/EventNotification-Create2.png)


## AWS CLI
<a name="USER_Events.Subscribing.CLI"></a>

Pour vous abonner à la notification d'événement RDS, utilisez la commande [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/create-event-subscription.html) de l'`create-event-subscription`. Incluez les paramètres requis suivants :
+ `--subscription-name`
+ `--sns-topic-arn`

**Example**  
Pour Linux, macOS ou Unix :  

```
aws rds create-event-subscription \
    --subscription-name myeventsubscription \
    --sns-topic-arn arn:aws:sns:us-east-1:123456789012:myawsuser-RDS \
    --enabled
```
Pour Windows :  

```
aws rds create-event-subscription ^
    --subscription-name myeventsubscription ^
    --sns-topic-arn arn:aws:sns:us-east-1:123456789012:myawsuser-RDS ^
    --enabled
```

## « Hello, World\$1 »
<a name="USER_Events.Subscribing.API"></a>

Pour vous abonner à la notification d'événement Amazon RDS, appelez la fonction d'API Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateEventSubscription.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateEventSubscription.html). Incluez les paramètres requis suivants : 
+ `SubscriptionName`
+ `SnsTopicArn`

# Balises et attributs de notifications d’événements Amazon RDS
<a name="USER_Events.TagsAttributesForFiltering"></a>

Lorsqu'Amazon RDS envoie une notification d'événement à Amazon Simple Notification Service (SNS) ou à EventBridge Amazon, la notification contient des attributs de message et des balises d'événement. RDS envoie les attributs du message séparément avec le message, tandis que les balises d’événement se trouvent dans le corps du message. Utilisez les attributs des messages et les balises Amazon RDS pour ajouter des métadonnées à vos ressources. Vous pouvez modifier ces balises avec vos propres notations sur les instances de base de données Pour plus d’informations sur le balisage des ressources Amazon RDS, consultez [Marquage des Amazon RDS](USER_Tagging.md). 

Par défaut, Amazon SNS et Amazon EventBridge reçoivent tous les messages qui leur sont envoyés. SNS et EventBridge peut filtrer le message et envoyer les notifications vers le mode de communication préféré, tel qu'un e-mail, un message texte ou un appel vers un point de terminaison HTTP.

**Note**  
La notification envoyée par e-mail ou SMS ne comportera pas de balises d’événement.

La table suivante montre les attributs de message pour les événements RDS envoyés à l’abonné à la rubrique.


| Attribut d’événement Amazon RDS |  Description  | 
| --- | --- | 
| EventID |  Identifiant pour le message de l’événement RDS, par exemple, RDS-EVENT-0006.  | 
| Ressource |  L’identifiant ARN de la ressource émettant l’événement, par exemple `arn:aws:rds:ap-southeast-2:123456789012:db:database-1`.  | 

Les balises RDS fournissent des données sur la ressource affectée par l’événement de service. RDS ajoute l'état actuel des balises dans le corps du message lorsque la notification est envoyée à SNS ou. EventBridge

Pour plus d’informations sur le filtrage des attributs de message pour SNS, consultez [Filtrage des messages Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-message-filtering.html) dans le *Guide du développeur Amazon Simple Notification Service*.

Pour plus d'informations sur le filtrage des balises d'événements pour EventBridge, consultez la section [Opérateurs de comparaison à utiliser dans les modèles d'événements sur Amazon EventBridge dans](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns-content-based-filtering.html) le *guide de EventBridge l'utilisateur Amazon*.

Pour plus d’informations sur le filtrage des balises basées sur les données utiles pour SNS, consultez. [Présentation du filtrage des messages basé sur les données utiles pour Amazon SNS](https://aws.amazon.com/blogs/compute/introducing-payload-based-message-filtering-for-amazon-sns/)

# Liste des abonnements aux notifications d’événements Amazon RDS
<a name="USER_Events.ListSubscription"></a>

Vous pouvez afficher vos abonnements aux notifications d’événement Amazon RDS.

## Console
<a name="USER_Events.ListSubscription.Console"></a>

**Pour afficher vos abonnements aux notifications d’événements Amazon RDS**

1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1.  Dans le panneau de navigation, choisissez **Abonnements aux événements**. Le volet **Abonnements aux événements** affiche tous les abonnements aux notifications d'événements.  
![\[Répertorier les abonnements aux notifications d’événements de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/EventNotification-ListSubs.png)

   

## AWS CLI
<a name="USER_Events.ListSubscription.CLI"></a>

Pour afficher vos abonnements aux notifications d’événements Amazon RDS, utilisez la commande de l’AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-event-subscriptions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-event-subscriptions.html). 

**Example**  
L’exemple suivant décrit tous les abonnements aux événements.  

```
aws rds describe-event-subscriptions
```
L'exemple suivant décrit l'abonnement `myfirsteventsubscription`.  

```
aws rds describe-event-subscriptions --subscription-name myfirsteventsubscription
```

## « Hello, World\$1 »
<a name="USER_Events.ListSubscription.API"></a>

Pour afficher vos abonnements aux notifications d'événements Amazon RDS, appelez l'action d'API Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEventSubscriptions.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEventSubscriptions.html).

# Modification d’un abonnement aux notifications d’événements Amazon RDS
<a name="USER_Events.Modifying"></a>

Une fois que vous avez créé un abonnement, vous pouvez en changer le nom, l'identifiant de la source, les catégories ou l'ARN de la rubrique.

## Console
<a name="USER_Events.Modifying.Console"></a>

**Pour modifier un abonnement aux notifications d’événements Amazon RDS**

1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1.  Dans le panneau de navigation, choisissez **Abonnements aux événements**. 

1.  Dans le volet **Abonnements aux événements**, choisissez l'abonnement que vous voulez modifier, puis choisissez **Modifier**. 

1.  Apportez les modifications requises à l'abonnement dans la section **Cible** ou **Source**.

1. Choisissez **Edit**. La console Amazon RDS indique que l'abonnement est en cours de modification.  
![\[Répertorier les abonnements aux notifications d’événements de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/EventNotification-Modify2.png)

   

## AWS CLI
<a name="USER_Events.Modifying.CLI"></a>

Pour modifier un abonnement aux notifications d’événements Amazon RDS, utilisez la commande de l’AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-event-subscription.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-event-subscription.html). Incluez le paramètre requis suivant :
+ `--subscription-name`

**Example**  
Le code suivant active `myeventsubscription`.  
Pour Linux, macOS ou Unix :  

```
aws rds modify-event-subscription \
    --subscription-name myeventsubscription \
    --enabled
```
Pour Windows :  

```
aws rds modify-event-subscription ^
    --subscription-name myeventsubscription ^
    --enabled
```

## « Hello, World\$1 »
<a name="USER_Events.Modifying.API"></a>

Pour modifier un événement Amazon RDS, appelez l'opération d'API Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyEventSubscription.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyEventSubscription.html). Incluez le paramètre requis suivant :
+ `SubscriptionName`

# Ajout d’un identifiant source à un abonnement aux notifications d’événements Amazon RDS
<a name="USER_Events.AddingSource"></a>

Vous pouvez ajouter un identifiant source (la source Amazon RDS générant l’événement) à l’abonnement existant.

## Console
<a name="USER_Events.AddingSource.Console"></a>

Vous pouvez facilement ajouter ou supprimer des identifiants source à l’aide de la console Amazon RDS en les sélectionnant ou en annulant leur sélection lors de la modification d’un abonnement. Pour plus d’informations, consultez [Modification d’un abonnement aux notifications d’événements Amazon RDS](USER_Events.Modifying.md).

## AWS CLI
<a name="USER_Events.AddingSource.CLI"></a>

Pour ajouter un identifiant de source à un abonnement aux notifications d'événements Amazon RDS, utilisez la AWS CLI [https://docs.aws.amazon.com/](https://docs.aws.amazon.com/)commande. Incluez les paramètres requis suivants :
+ `--subscription-name`
+ `--source-identifier`

**Example**  
L’exemple suivant ajoute l’identifiant source `mysqldb` à l’abonnement `myrdseventsubscription`  
Pour Linux, macOS ou Unix :  

```
aws rds add-source-identifier-to-subscription \
    --subscription-name myrdseventsubscription \
    --source-identifier mysqldb
```
Pour Windows :  

```
aws rds add-source-identifier-to-subscription ^
    --subscription-name myrdseventsubscription ^
    --source-identifier mysqldb
```

## API
<a name="USER_Events.AddingSource.API"></a>

Pour ajouter un identifiant source à un abonnement aux notifications d’événements Amazon RDS, appelez l’API Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_AddSourceIdentifierToSubscription.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_AddSourceIdentifierToSubscription.html). Incluez les paramètres requis suivants :
+ `SubscriptionName`
+ `SourceIdentifier`

# Suppression d’un identifiant source d’un abonnement aux notifications d’événements Amazon RDS
<a name="USER_Events.RemovingSource"></a>

Vous pouvez supprimer un identifiant source (la source Amazon RDS générant l’événement) d’un abonnement si vous ne souhaitez plus être informé des événements de cette source. 

## Console
<a name="USER_Events.RemovingSource.Console"></a>

Vous pouvez facilement ajouter ou supprimer des identifiants source à l’aide de la console Amazon RDS en les sélectionnant ou en annulant leur sélection lors de la modification d’un abonnement. Pour plus d’informations, consultez [Modification d’un abonnement aux notifications d’événements Amazon RDS](USER_Events.Modifying.md).

## AWS CLI
<a name="USER_Events.RemovingSource.CLI"></a>

Pour supprimer un identifiant de source d'un abonnement aux notifications d'événements Amazon RDS, utilisez la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/remove-source-identifier-from-subscription.html](https://docs.aws.amazon.com/cli/latest/reference/rds/remove-source-identifier-from-subscription.html)commande. Incluez les paramètres requis suivants :
+ `--subscription-name`
+ `--source-identifier`

**Example**  
L’exemple suivant supprime l’identifiant source `mysqldb` de l’abonnement `myrdseventsubscription`.  
Pour Linux, macOS ou Unix :  

```
aws rds remove-source-identifier-from-subscription \
    --subscription-name myrdseventsubscription \
    --source-identifier mysqldb
```
Pour Windows :  

```
aws rds remove-source-identifier-from-subscription ^
    --subscription-name myrdseventsubscription ^
    --source-identifier mysqldb
```

## API
<a name="USER_Events.RemovingSource.API"></a>

Pour supprimer un identifiant source d’un abonnement aux notifications d’événements Amazon RDS, utilisez la commande d’API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RemoveSourceIdentifierFromSubscription.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RemoveSourceIdentifierFromSubscription.html) de l’Amazon RDS. Incluez les paramètres requis suivants :
+ `SubscriptionName`
+ `SourceIdentifier`

# Affichage des catégories aux notifications d’événements Amazon RDS
<a name="USER_Events.ListingCategories"></a>

Tous les événements d’un type de ressource sont regroupés en catégories. Pour afficher la liste des catégories disponibles, utilisez les procédures suivantes.

## Console
<a name="USER_Events.ListingCategories.Console"></a>

Lorsque vous créez ou modifiez un abonnement aux notifications d’événements, les catégories d’événements sont affichées dans la console Amazon RDS. Pour plus d'informations, consultez [Modification d’un abonnement aux notifications d’événements Amazon RDS](USER_Events.Modifying.md). 

![\[Afficher les catégories de notifications d’événements de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/EventNotification-Categories.png)




## AWS CLI
<a name="USER_Events.ListingCategories.CLI"></a>

Pour lister les catégories de notifications d’événements Amazon RDS, utilisez la commande de l’AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-event-categories.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-event-categories.html). Cette commande n'a aucun paramètre requis.

**Example**  

```
aws rds describe-event-categories
```

## « Hello, World\$1 »
<a name="USER_Events.ListingCategories.API"></a>

Pour lister les catégories de notifications d’événements Amazon RDS, utilisez la commande d’API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEventCategories.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEventCategories.html) de l’Amazon RDS. Cette commande n'a aucun paramètre requis.

# Suppression d’un abonnement aux notifications d’événements Amazon RDS
<a name="USER_Events.Deleting"></a>

Vous pouvez supprimer un abonnement lorsque vous n'en avez plus besoin. Tous les abonnés à la rubrique ne reçoivent plus les notifications d’événements spécifiées par l’abonnement.

## Console
<a name="USER_Events.Deleting.Console"></a>

**Pour supprimer un abonnement aux notifications d’événements Amazon RDS**

1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1.  Dans le panneau de navigation, choisissez **DB Event Subscriptions** (Abonnements aux événements de base de données). 

1.  Dans le volet **My DB Event Subscriptions** (Mes abonnements aux événements de base de données), cliquez sur l’abonnement que vous souhaitez supprimer. 

1. Sélectionnez **Delete**.

1. La console Amazon RDS indique que l'abonnement est en cours de suppression.  
![\[Supprimer un abonnement aux notifications d’événements\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/EventNotification-Delete.png)

   

## AWS CLI
<a name="USER_Events.Deleting.CLI"></a>

Pour supprimer un abonnement aux notifications d’événements Amazon RDS, utilisez la commande de l’AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/delete-event-subscription.html](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-event-subscription.html). Incluez le paramètre requis suivant :
+ `--subscription-name`

**Example**  
L'exemple suivant supprime l'abonnement `myrdssubscription`.  

```
aws rds delete-event-subscription --subscription-name myrdssubscription
```

## « Hello, World\$1 »
<a name="USER_Events.Deleting.API"></a>

Pour supprimer un abonnement aux notifications d’événements Amazon RDS, utilisez la commande [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteEventSubscription.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteEventSubscription.html) de l’API. Incluez le paramètre requis suivant :
+ `SubscriptionName`

# Création d’une règle qui se déclenche sur un événement Amazon RDS
<a name="rds-cloud-watch-events"></a>

Amazon vous permet EventBridge d'automatiser les AWS services et de répondre aux événements du système tels que les problèmes de disponibilité des applications ou les modifications des ressources. 

**Topics**
+ [Création de règles pour envoyer des événements Amazon RDS à Amazon EventBridge](#rds-cloudwatch-events.sending-to-cloudwatch-events)
+ [Tutoriel : Consigner les modifications de l'état d'une instance de base de données à l'aide EventBridge](#log-rds-instance-state)

## Création de règles pour envoyer des événements Amazon RDS à Amazon EventBridge
<a name="rds-cloudwatch-events.sending-to-cloudwatch-events"></a>

Vous pouvez écrire des règles simples pour préciser les événements Amazon RDS qui vous intéressent et les actions automatisées à effectuer quand un événement correspond à une règle. Vous pouvez définir diverses cibles, telles qu'une AWS Lambda fonction ou une rubrique Amazon SNS, qui reçoivent des événements au format JSON. Par exemple, vous pouvez configurer Amazon RDS Amazon pour envoyer des événements à Amazon EventBridge chaque fois qu'une instance de base de données est créée ou supprimée. Pour plus d'informations, consultez le guide de l'[utilisateur Amazon CloudWatch Events et le guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/) de [ EventBridge l'utilisateur Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/).

**Pour créer une règle qui se déclenche sur un événement RDS :**

1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. Sous **Événements** dans le panneau de navigation, choisissez **Règles**.

1. Choisissez **Create rule**.

1. Dans **Event source**, effectuez l’une des opérations suivantes :

   1. Choisissez **Modèle d’événement**.

   1. Pour **Service Name** (Nom du service), choisissez **Relational Database Service (RDS)** (Service de base de données relationnelle).

   1. Pour **Event Type** (Type d’événement), choisissez le type de ressource Amazon RDS qui déclenche l’événement. Par exemple, si une instance de base de données déclenche l’événement, choisissez **RDS DB Instance Event** (Événement relatif à l’instance de base de données RDS).

1. Pour **les cibles**, choisissez **Ajouter une cible** et choisissez le AWS service qui doit agir lorsqu'un événement du type sélectionné est détecté. 

1. Dans les autres champs de cette section, entrez des informations spécifiques à ce type de cible, le cas échéant. 

1. Pour de nombreux types de cibles, EventBridge nécessite des autorisations pour envoyer des événements à la cible. Dans ces cas, EventBridge vous pouvez créer le rôle IAM nécessaire au déroulement de votre événement : 
   + Pour créer un rôle IAM automatiquement, choisissez **Create a new role for this specific resource**.
   + Pour utiliser un rôle IAM que vous avez créé auparavant, choisissez **Utiliser le rôle existant**.

1. Le cas échéant, répétez les étapes 5 à 7 afin d’ajouter une autre cible pour cette règle.

1. Sélectionnez **Configure details**. Dans **Rule definition**, saisissez un nom et une description pour la règle.

   Le nom de la règle doit être unique au sein de cette région.

1. Choisissez **Create rule**.

Pour plus d'informations, consultez [la section Création d'une EventBridge règle déclenchant un événement](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) dans le *guide de CloudWatch l'utilisateur Amazon*.

## Tutoriel : Consigner les modifications de l'état d'une instance de base de données à l'aide EventBridge
<a name="log-rds-instance-state"></a>

Dans ce didacticiel, vous allez créer une AWS Lambda fonction qui enregistre les changements d'état d'une instance Amazon RDS. Vous créez ensuite une règle qui exécute la fonction chaque fois qu’il y a un changement d’état d’une instance de base de données RDS existante. Le didacticiel suppose que vous avez d’une petite instance de test en cours d’exécution, que vous pouvez arrêter momentanément.

**Important**  
N’appliquez pas ce tutoriel à une instance de base de données de production en cours d’exécution.

**Topics**
+ [Étape 1 : Création d'une AWS Lambda fonction](#rds-create-lambda-function)
+ [Étape 2 : création d’une règle](#rds-create-rule)
+ [Étape 3 : test de la règle](#rds-test-rule)

### Étape 1 : Création d'une AWS Lambda fonction
<a name="rds-create-lambda-function"></a>

Créez une fonction Lambda pour enregistrer les événements de changement d’état. Vous spécifiez cette fonction lors de la création de votre règle.

**Pour créer une fonction Lambda**

1. Ouvrez la AWS Lambda console à l'adresse [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

1. Si vous utilisez Lambda pour la première fois, une page de bienvenue s’affiche. Sélectionnez **Pour commencer**. Sinon, choisissez **Créer la fonction**.

1. Choisissez **Créer à partir de scratch**.

1. Sur la page **Create function** (Créer une fonction), procédez de la façon suivante :

   1. Saisissez un nom et une description pour la fonction Lambda. Par exemple, nommez la fonction **RDSInstanceStateChange**. 

   1. Dans **Runtime**, sélectionnez **Node.js 16x**. 

   1. Pour **Architecture**, choisissez **x86\$164**.

   1. Pour **Execution role** (Rôle d’exécution), effectuez l’une des opérations suivantes :
      + Choisissez **Create a new role with basic Lambda permissions (Créer un rôle avec les autorisations Lambda standard)**.
      + Pour **Existing role** (Rôle existant), sélectionnez **Use an existing role** (Utiliser un rôle existant). Choisissez le rôle que vous voulez utiliser. 

   1. Choisissez **Créer une fonction**.

1. Sur la page **RDSInstanceStateChange**, procédez de la façon suivante :

   1. Dans **Code source** (Source de code), sélectionnez **index.js**. 

   1. Dans le panneau **index.js**, supprimez le code existant.

   1. Saisissez le code suivant :

      ```
      console.log('Loading function');
      
      exports.handler = async (event, context) => {
          console.log('Received event:', JSON.stringify(event));
      };
      ```

   1. Choisissez **Deploy** (Déployer).

### Étape 2 : création d’une règle
<a name="rds-create-rule"></a>

Créez une règle pour exécuter votre fonction Lambda chaque fois que vous lancez une instance Amazon RDS.

**Pour créer la EventBridge règle**

1. Ouvrez la EventBridge console Amazon à l'adresse [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. Dans le panneau de navigation, choisissez **Rules**.

1. Choisissez **Créer une règle**.

1. Saisissez un nom et une description pour la règle. Par exemple, entrez **RDSInstanceStateChangeRule**.

1. Sélectionnez **Rule with an event pattern** (Règle avec un modèle d’événement), puis sélectionnez **Next** (Suivant).

1. Dans **Source de l'événement**, sélectionnez **AWS événements ou événements EventBridge partenaires**.

1. Faites défiler la page vers le bas jusqu’à la section **Event pattern** (Modèle d’événement).

1. Pour **Event source (Source d’événement)**, choisissez **Services AWS**.

1. Pour **Service AWS **, choisissez **Relational Database Service (RDS)**.

1. Pour **Event type** (Type d’événement), sélectionnez **RDS DB Instance Event** (événement d’instance de base de données RDS).

1. Laissez le modèle d’événement par défaut. Ensuite, sélectionnez **Suivant**.

1. Pour **Types de cibles**, choisissez **service AWS **.

1. Pour **Select a target** (Sélectionner une cible), choisissez **Lambda Function** (Fonction Lambda).

1. Dans **Function** (Fonction), choisissez la fonction Lambda que vous avez créée. Ensuite, sélectionnez **Suivant**.

1. Dans la rubrique **Configure tags** (Configurer les balises), sélectionnez **Next** (Suivant).

1. Passez en revue les étapes de votre règle. Puis, choisissez **Create rule** (Créer une règle).

### Étape 3 : test de la règle
<a name="rds-test-rule"></a>

Pour tester votre règle, arrêtez une instance de base de données RDS. Après avoir attendu quelques minutes que l’instance s’arrête, vous pouvez vérifier que votre fonction Lambda a été appelée.

**Pour tester votre règle en arrêtant une instance de base de données**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Arrêter une instance de base de données RDS.

1. Ouvrez la EventBridge console Amazon à l'adresse [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. Dans le panneau de navigation, cliquez sur **Rules** (Règles), puis sur le nom de la règle que vous avez créée.

1. Dans **Détails des règles**, choisissez **Surveillance**.

   Vous êtes redirigé vers la CloudWatch console Amazon. Si vous n'êtes pas redirigé, cliquez sur **Afficher les statistiques dans CloudWatch**.

1. Dans **All metrics** (Toutes les métriques), cliquez sur le nom de la règle que vous avez créée.

   Le graphique doit indiquer que la règle a été appelée.

1. Dans le panneau de navigation, sélectionnez **Groupes de journaux**.

1. Choisissez le nom du groupe de journaux pour votre fonction Lambda (**/aws/lambda/ *function-name***).

1. Choisissez le nom du flux de journaux pour afficher les données fournies par la fonction concernant l’instance que vous avez lancée. Vous devez voir un événement reçu semblable à ce qui suit :

   ```
   {
       "version": "0",
       "id": "12a345b6-78c9-01d2-34e5-123f4ghi5j6k",
       "detail-type": "RDS DB Instance Event",
       "source": "aws.rds",
       "account": "111111111111",
       "time": "2021-03-19T19:34:09Z",
       "region": "us-east-1",
       "resources": [
           "arn:aws:rds:us-east-1:111111111111:db:testdb"
       ],
       "detail": {
           "EventCategories": [
               "notification"
           ],
           "SourceType": "DB_INSTANCE",
           "SourceArn": "arn:aws:rds:us-east-1:111111111111:db:testdb",
           "Date": "2021-03-19T19:34:09.293Z",
           "Message": "DB instance stopped",
           "SourceIdentifier": "testdb",
           "EventID": "RDS-EVENT-0087"
       }
   }
   ```

   Pour voir plus d’exemples d’événements RDS au format JSON, consultez [Présentation des événements pour Amazon RDS](working-with-events.md#rds-cloudwatch-events.sample).

1. (Facultatif) Lorsque vous avez terminé, vous pouvez ouvrir la console Amazon RDS et lancer l’instance que vous avez arrêtée.

# Catégories d'événements Amazon RDS et messages d'événements
<a name="USER_Events.Messages"></a>

Amazon RDS génère un nombre important d'événements dans des catégories auxquelles vous pouvez vous abonner à l'aide de la console Amazon RDS ou de l'API. AWS CLI

**Topics**
+ [Événements de cluster de bases de données](#USER_Events.Messages.cluster)
+ [Événements d’instantané de cluster de bases de données](#USER_Events.Messages.cluster-snapshot)
+ [Événements d’instance de base de données](#USER_Events.Messages.instance)
+ [Événements de groupe de paramètres de base de données](#USER_Events.Messages.parameter-group)
+ [Événements de groupe de sécurité de base de données](#USER_Events.Messages.security-group)
+ [Événements d’instantané de bases de données](#USER_Events.Messages.snapshot)
+ [Événements RDS Proxy](#USER_Events.Messages.rds-proxy)
+ [Événements de déploiement bleu/vert](#USER_Events.Messages.BlueGreenDeployments)
+ [Événements de version du moteur personnalisés](#USER_Events.Messages.CEV)

## Événements de cluster de bases de données
<a name="USER_Events.Messages.cluster"></a>

Le tableau suivant affiche la catégorie d’événement et la liste des événements lorsqu’un cluster de bases de données est le type source.

Pour plus d’informations sur les déploiements de clusters de bases de données multi-AZ, consultez [Déploiements de cluster de bases de données multi-AZ pour Amazon RDS](multi-az-db-clusters-concepts.md).


|  Catégorie  | ID d’événement RDS |  Message  |  Remarques  | 
| --- | --- | --- | --- | 
|  modification de configuration  | RDS-EVENT-0016 |  Réinitialisation des informations d’identification principales.  | Aucune | 
| création | RDS-EVENT-0170 |  cluster de bases de données créé.  |  Aucune  | 
|  basculement  | RDS-EVENT-0069 |  Le basculement du cluster a échoué. Vérifiez l’état de santé de vos instances de cluster et réessayez.  |  Aucune  | 
|  basculement  | RDS-EVENT-0070 |  Promouvoir à nouveau la primaire précédente :*name*.  |  Aucune  | 
|  basculement  | RDS-EVENT-0071 |  Basculement terminé vers l'instance de base de données :*name*.  |  Aucune  | 
|  basculement  | RDS-EVENT-0072 |  Démarrage du même basculement AZ vers l'instance de base de données :*name*.  |  Aucune  | 
|  basculement  | RDS-EVENT-0073 |  Basculement cross-AZ lancé vers une instance de base de données :*name*.  |  Aucune  | 
| échec | RDS-EVENT-0354 |  Vous ne pouvez pas créer le cluster de base de données en raison de ressources incompatibles. *message*.  |  *message*Cela inclut des détails sur la panne.  | 
| échec | RDS-EVENT-0355 |  Le cluster de base de données ne peut pas être créé en raison de limites de ressources insuffisantes. *message*.  |  *message*Cela inclut des détails sur la panne.  | 
|  maintenance  | RDS-EVENT-0156 |  Une mise à niveau de version mineure du moteur de base de données est disponible pour le cluster de bases de données.  |  Aucune  | 
|  maintenance  | RDS-EVENT-0173 |  La version du moteur de cluster de bases de données a été mise à niveau.  | Les correctifs ont été appliqués au cluster de bases de données. | 
|  maintenance  | RDS-EVENT-0174 |  Le cluster de bases de données est dans un état qui ne peut pas être mis à niveau.  | Aucune | 
|  maintenance  | RDS-EVENT-0176 |  La version majeure du moteur de cluster de bases de données a été mise à niveau.  | Aucune | 
|  maintenance  | RDS-EVENT-0177 |  La mise à niveau du cluster de bases de données est en cours.  | Aucune | 
|  maintenance  | RDS-EVENT-0286 |  La mise à niveau de *version\$1number* la version du moteur du cluster de base de données Le cluster reste en ligne.  | Aucune | 
|  maintenance  | RDS-EVENT-0287 |  Une mise à niveau nécessaire du système d’exploitation a été détectée.  | Aucune | 
|  maintenance  | RDS-EVENT-0288 |  La mise à niveau du système d’exploitation du cluster est en cours de démarrage.  | Aucune | 
|  maintenance  | RDS-EVENT-0289 |  La mise à niveau du système d’exploitation du cluster est terminée.  | Aucune | 
|  maintenance  | RDS-EVENT-0290 |  Le cluster de base de données a été corrigé : version source *version\$1number* =>*new\$1version\$1number*.  | Aucune | 
|  maintenance  | RDS-EVENT-0410 |  La vérification préalable a commencé pour la mise à niveau de la version du moteur de cluster de bases de données.  | Aucune | 
|  maintenance  | RDS-EVENT-0412 |  La vérification préalable de la mise à niveau de la version du moteur de cluster de bases de données a échoué ou a expiré.  | Aucune | 
|  maintenance  | RDS-EVENT-0413 |  Les tâches de mise à niveau préalable au cluster de bases de données sont en cours.  | Aucune | 
|  maintenance  | RDS-EVENT-0414 |  Les tâches postérieures à la mise à niveau du cluster de bases de données sont en cours.  | Aucune | 
|  maintenance  | RDS-EVENT-0417 |  La mise à niveau de la version du moteur de cluster de bases de données a démarré.  | Aucune | 
|  notification  | RDS-EVENT-0172 |  Cluster renommé de *name* à*name*.  |  Aucune  | 
|  réplica en lecture  | RDS-EVENT-0411 |  La vérification préalable est terminée pour la mise à niveau de la version du moteur de cluster de bases de données.  | Aucune | 

## Événements d’instantané de cluster de bases de données
<a name="USER_Events.Messages.cluster-snapshot"></a>

Le tableau suivant affiche la catégorie d’événement et la liste des événements lorsqu’un instantané de cluster de bases de données est le type source.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_Events.Messages.html)

## Événements d’instance de base de données
<a name="USER_Events.Messages.instance"></a>

Le tableau suivant recense la catégorie d’événement et la liste des événements lorsqu’une instance de base de données est le type source.


|  Catégorie  | ID d’événement RDS |  Message  |  Remarques  | 
| --- | --- | --- | --- | 
|  disponibilité  | RDS-EVENT-0004 |  L’instance de base de données s’est arrêtée.  | Aucune | 
|  disponibilité  | RDS-EVENT-0006 |  Instance de base de données redémarrée.  | Aucune | 
|  disponibilité  | RDS-EVENT-0022 |  Erreur lors du redémarrage de MySQL :*message*.  | Une erreur s’est produite lors du redémarrage MySQL. | 
|  disponibilité  | RDS-EVENT-0221 |  L’instance de base de données a atteint le seuil de stockage complet et la base de données a été arrêtée. Vous pouvez augmenter le stockage alloué pour résoudre ce problème.  | Aucune | 
|  disponibilité  | RDS-EVENT-0222 |  La capacité de stockage disponible pour l'instance de base *percentage* de données *name* est faible par rapport au stockage alloué [Stockage alloué :*amount*, Stockage gratuit :*amount*]. La base de données sera fermée pour éviter toute corruption si le stockage disponible est inférieur à*amount*. Vous pouvez augmenter le stockage alloué pour résoudre ce problème.  | S’applique uniquement à RDS for MySQL lorsqu’une instance de base de données consomme plus de 90 % du stockage alloué. Surveillez l’espace de stockage pour une instance de base de données à l’aide de la métrique Free Storage Space (Espace de stockage libre). Pour de plus amples informations, veuillez consulter [Stockage d'instance de base de données Amazon RDS](CHAP_Storage.md). | 
|  disponibilité  | RDS-EVENT-0330 |  La capacité de stockage disponible du volume de journal des transactions dédié est trop faible pour une instance de base de données*name*. Le volume de stockage gratuit du journal correspond à *percentage* l'espace de stockage alloué. [Stockage alloué :*amount*, Stockage libre :*amount*] La base de données sera fermée pour éviter toute corruption si le stockage disponible est inférieur à*amount*. Vous pouvez désactiver le volume dédié au journal des transactions pour résoudre ce problème.  |  Pour de plus amples informations, veuillez consulter [Volume dédié aux journaux (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).  | 
|  disponibilité  | RDS-EVENT-0331 |  La capacité de stockage disponible du volume de journal des transactions dédié est trop faible pour une instance de base de données*name*. Le stockage gratuit du volume de log *percentage* correspond au stockage provisionné. [Stockage provisionné :*amount*, Stockage gratuit :*amount*] Vous pouvez désactiver le volume dédié au journal des transactions pour résoudre ce problème.  |  Pour de plus amples informations, veuillez consulter [Volume dédié aux journaux (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).  | 
|  disponibilité  | RDS-EVENT-0396 |  Amazon RDS a prévu un redémarrage de cette réplique de lecture lors de la prochaine fenêtre de maintenance de cette instance, après la rotation du mot de passe utilisateur interne.  |  Aucune  | 
| disponibilité | RDS-EVENT-0419 | Amazon RDS n'a pas pu accéder à la clé de KMS chiffrement de l'instance *name* de base de données. Cette base de données sera placée dans un état inaccessible. Reportez-vous à la section sur la résolution des problèmes dans la documentation Amazon RDS pour plus de détails. | Aucune | 
|  sauvegarde  | RDS-EVENT-0001 |  Sauvegarde de l’instance de base de données.  | Aucune | 
|  sauvegarde  | RDS-EVENT-0002 |  Sauvegarde de l’instance de base de données terminée.  | Aucune | 
|  sauvegarde  | RDS-EVENT-0086 |  Nous ne sommes pas en mesure d'associer le groupe d'options *name* à l'instance de base de données*name*. Vérifiez que le groupe d'options *name* est pris en charge dans votre classe d'instance de base de données et dans votre configuration. Si c’est le cas, vérifiez tous les paramètres du groupe d’options et réessayez.  |  Pour plus d’informations, consultez [Utilisation de groupes d’options](USER_WorkingWithOptionGroups.md). | 
|  modification de configuration  | RDS-EVENT-0011 |  Mis à jour pour utiliser DBParameter le groupe*name*.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0012 |  Application de la modification à la classe d’instance de base de données.   | Aucune | 
|  modification de configuration  | RDS-EVENT-0014 |  Fin de l’application de la modification à la classe d’instance de base de données.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0016 |  Réinitialisation des informations d’identification principales.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0017 |  Fin de l’application de la modification au stockage alloué.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0018 |  Application de la modification au stockage alloué.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0024 |  Application de la modification pour effectuer une conversion vers une instance de base de données multi-AZ.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0025 |  Fin de l’application de la modification pour effectuer une conversion vers une instance de base de données multi-AZ.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0028 |  Désactivation des sauvegardes automatiques.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0029 |  Fin de l’application de la modification pour effectuer une conversion vers une instance de base de données standard (mono-AZ).  | Aucune | 
|  modification de configuration  | RDS-EVENT-0030 |  Application de la modification pour effectuer une conversion vers une instance de base de données standard (mono-AZ).  | Aucune | 
|  modification de configuration  | RDS-EVENT-0032 |  Sauvegardes automatiques activées.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0033 |  Certains *number* utilisateurs correspondent au nom d'utilisateur principal ; seuls ceux qui ne sont pas liés à un hôte spécifique sont réinitialisés.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0067 |  Réinitialisation de votre mot de passe impossible. Informations sur les erreurs :*message*.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0078 |  L'intervalle de surveillance est passé à*number*.  |  La configuration Supervision améliorée a été modifiée. | 
|  modification de configuration  | RDS-EVENT-0092 |  Fin de la mise à jour du groupe de paramètres de la base de données.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0217 |  Application de la modification initiée par scalabilité automatique au stockage alloué.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0218 |  Vous avez fini d’appliquer la modification initiée par scalabilité automatique au stockage alloué.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0295 |  La mise à niveau de la configuration du stockage a commencé.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0296 |  La mise à niveau de la configuration du stockage est terminée.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0332 |  Le volume de journal dédié est désactivé.  |  Pour de plus amples informations, veuillez consulter [Volume dédié aux journaux (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).  | 
|  modification de configuration  | RDS-EVENT-0333 |  La désactivation du volume de journal dédié a commencé.  |  Pour de plus amples informations, veuillez consulter [Volume dédié aux journaux (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).  | 
|  modification de configuration  | RDS-EVENT-0334 |  L’activation du volume de journal dédié a commencé.  |  Pour de plus amples informations, veuillez consulter [Volume dédié aux journaux (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).  | 
|  modification de configuration  | RDS-EVENT-0335 |  Le volume de journal dédié est activé.  |  Pour de plus amples informations, veuillez consulter [Volume dédié aux journaux (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).  | 
|  modification de configuration  | RDS-EVENT-0383 |  *engine version*ne supporte pas le plugin memcached. RDS continuera à mettre à niveau votre instance de base de données et supprimera ce plugin.  |  À partir de MySQL 8.3.0, le plugin memcached n’est plus pris en charge. Pour plus d’informations, consultez les [modifications apportées à MySQL 8.3.0 (16/01/2024, Innovation Release](https://dev.mysql.com/doc/relnotes/mysql/8.3/en/news-8-3-0.html)).  | 
|  création  | RDS-EVENT-0005 |  Instance de base de données créée.  | Aucune | 
|  suppression  | RDS-EVENT-0003 |  Instance de base de données supprimée.  | Aucune | 
|  basculement  | RDS-EVENT-0013 |  Basculement d’instance multi-AZ démarré.  | Un basculement multi-AZ ayant entraîné la promotion d’une instance de base de données de secours a démarré. | 
|  basculement  | RDS-EVENT-0015 |  Basculement multi-AZ vers le mode veille terminé : la propagation DNS peut prendre quelques minutes.  | Un basculement multi-AZ ayant entraîné la promotion d’une instance de base de données de secours est terminé. Le transfert du DNS vers la nouvelle instance de base de données principale peut prendre plusieurs minutes. | 
|  basculement  | RDS-EVENT-0034 |  Abandon du basculement demandé par l’utilisateur, car un basculement s’est récemment produit sur l’instance de base de données.  | Amazon RDS ne tente pas d’effectuer le basculement demandé, car un basculement s’est récemment produit sur l’instance de base de données. | 
|  basculement  | RDS-EVENT-0049 | Basculement de l’instance multi-AZ terminé. | Aucune | 
|  basculement  | RDS-EVENT-0050 |  Démarrage de l’activation de l’instance multi-AZ.  | Une activation multi-AZ a commencé après une récupération réussie de l’instance de base de données. Cet événement se produit si Amazon RDS promeut l’instance de base de données principale vers le même AZ que l’instance de base de données principale précédente. | 
|  basculement  | RDS-EVENT-0051 |  Activation de l’instance multi-AZ terminée.  | Une activation Multi-AZ est terminée. Votre base de données doit être accessible maintenant.  | 
|  basculement  | RDS-EVENT-0065 |  Récupéré après un basculement partiel.  | Aucune | 
|  échec  | RDS-EVENT-0031 |  Instance de base de données mise en *name* état. RDS vous recommande de lancer un point-in-time-restore.  | L’instance de base de données a échoué en raison d’une configuration incompatible ou d’un problème de stockage sous-jacent. Commencez un point-in-time-restore pour l'instance de base de données. | 
|  échec  | RDS-EVENT-0035 |  Instance de base de données insérée dans*state*. *message*.  | L’instance de base de données a des paramètres non valides. Par exemple, si l’instance de base de données n’a pas pu démarrer, un paramètre lié à la mémoire étant défini avec une valeur trop élevée pour cette classe d’instance, votre action consiste à modifier le paramètre et à redémarrer l’instance de base de données. | 
|  échec  | RDS-EVENT-0036 |  Instance de base de données dans*state*. *message*.  | L’instance de base de données se trouve sur un réseau non compatible. Certains sous-réseaux spécifiés ne IDs sont pas valides ou n'existent pas. | 
|  échec  | RDS-EVENT-0058 |  L'installation de Statspack a échoué. *message*.  | Erreur lors de la création du compte d’utilisateur Oracle Statspack `PERFSTAT`. Supprimez le compte avant d’ajouter l’option `STATSPACK`. | 
|  échec  | RDS-EVENT-0079 |  Amazon RDS n’a pas été en mesure de créer des informations d’identification pour une surveillance améliorée. Cette fonction a été désactivée. Cela est probablement dû au fait que votre compte rds-monitoring-role n'est pas présent et qu'il n'est pas configuré correctement. Reportez-vous à la section sur la résolution des problèmes dans la documentation Amazon RDS pour plus de détails.  |  La supervision améliorée ne peut pas être activée sans le rôle IAM de surveillance améliorée. Pour obtenir des informations sur la création du rôle IAM, consultez [Pour créer un rôle IAM pour la surveillance améliorée Amazon RDS](USER_Monitoring.OS.Enabling.md#USER_Monitoring.OS.IAMRole).  | 
|  échec  | RDS-EVENT-0080 |  Amazon RDS n'a pas pu configurer la surveillance améliorée sur votre instance : *name* cette fonctionnalité a été désactivée. Cela est probablement dû au fait que votre compte rds-monitoring-role n'est pas présent et qu'il n'est pas configuré correctement. Reportez-vous à la section sur la résolution des problèmes dans la documentation Amazon RDS pour plus de détails.  |  La surveillance améliorée a été désactivée en raison d’une erreur lors de la modification de la configuration. Il est probable que le rôle IAM de surveillance améliorée ne soit pas configuré correctement. Pour obtenir des informations sur la création du rôle IAM de surveillance améliorée, consultez [Pour créer un rôle IAM pour la surveillance améliorée Amazon RDS](USER_Monitoring.OS.Enabling.md#USER_Monitoring.OS.IAMRole).  | 
|  échec  | RDS-EVENT-0081 |  Amazon RDS n'a pas pu créer d'informations d'identification pour l'*name*option. Cela est dû au fait que le rôle *name* IAM n'est pas correctement configuré dans votre compte. Reportez-vous à la section sur la résolution des problèmes dans la documentation Amazon RDS pour plus de détails.  |  Le rôle IAM que vous utilisez pour accéder à votre compartiment Amazon S3 pour la sauvegarde et la restauration natives SQL Server est mal configuré. Pour plus d’informations, consultez [Configuration pour les sauvegarde et restauration natives](SQLServer.Procedural.Importing.Native.Enabling.md).  | 
|  échec  | RDS-EVENT-0165 |  L’instance de base de données RDS Custom se trouve en dehors du périmètre de prise en charge.  |  Il est de votre responsabilité de corriger les problèmes de configuration qui font passer votre instance de base de données RDS Custom à l’état `unsupported-configuration`. Si le problème est lié à l' AWS infrastructure, vous pouvez utiliser la console ou le AWS CLI pour le résoudre. Si le problème concerne le système d’exploitation ou la configuration de la base de données, vous pouvez vous connecter à l’hôte pour le résoudre.Pour de plus amples informations, veuillez consulter [Périmètre de prise en charge RDS Custom](custom-concept.md#custom-troubleshooting.support-perimeter). | 
|  échec  | RDS-EVENT-0188 |  L'état de l'instance de base de données ne peut pas être mis à niveau. *message*  |  Amazon RDS n’a pas pu mettre à niveau une instance de base de données MySQL en raison d’incompatibilités liées au dictionnaire de données. L’instance de base de données a été rétablie vers la version 5.7 en raison de l’échec d’une tentative de mise à niveau vers la version 8.0, ou rétablie vers la version 8.0 de MySQL en raison de l’échec d’une tentative de mise à niveau vers la version 8.4. Pour de plus amples informations, veuillez consulter [Annulation après échec de la mise à niveau](USER_UpgradeDBInstance.MySQL.Major.md#USER_UpgradeDBInstance.MySQL.Major.RollbackAfterFailure).  | 
|  échec  | RDS-EVENT-0219 |  L’instance de base de données est dans un état non valide. Aucune action n’est nécessaire. La scalabilité automatique retentera plus tard.  | Aucune | 
|  échec  | RDS-EVENT-0220 |  L’instance de base de données est dans la période de refroidissement après une opération précédente de mise à l’échelle du stockage. Nous optimisons votre instance de base de données. Cette opération prend au moins six heures. Aucune action n’est nécessaire. La scalabilité automatique retentera après la période de refroidissement.  | Aucune | 
|  échec  | RDS-EVENT-0223 |  Le dimensionnement automatique du stockage n'est pas en mesure de redimensionner le stockage pour la raison :*reason*.  | Aucune | 
|  échec  | RDS-EVENT-0224 |  La mise à l’échelle automatique du stockage a déclenché une tâche de mise à l’échelle du stockage en attente qui atteindrait ou dépasserait le seuil de stockage maximal. Augmentez le seuil de stockage maximal.  | Aucune | 
|  échec  | RDS-EVENT-0237 |  L’instance de base de données comporte un type de stockage qui est actuellement indisponible dans la zone de disponibilité. La scalabilité automatique retentera plus tard.  | Aucune | 
| échec | RDS-EVENT-0254 |  Le quota de stockage sous-jacent pour ce compte client a dépassé la limite. Augmentez le quota de stockage autorisé pour permettre la mise à l’échelle sur l’instance.  | Aucune | 
|  échec  |  RDS-EVENT-0278  |  La création de l'instance de base de données a échoué. *message*  |  *message*Cela inclut des détails sur la panne.  | 
|  échec  |  RDS-EVENT-0279  |  La promotion de la réplique de lecture personnalisée RDS a échoué. *message*  |  *message*Cela inclut des détails sur la panne.  | 
|  échec  |  RDS-EVENT-0280  |  RDS Custom n'a pas pu mettre à niveau l'instance de base de données car la pré-vérification a échoué. *message*  |  *message*Cela inclut des détails sur la panne.  | 
|  échec  |  RDS-EVENT-0281  |  RDS Custom n'a pas pu modifier l'instance de base de données car la pré-vérification a échoué. *message*  |  *message*Cela inclut des détails sur la panne.  | 
|  échec  |  RDS-EVENT-0282  |  RDS Custom n’a pas pu modifier l’instance de base de données, car les autorisations d’adresses IP Elastic ne sont pas correctes. Veuillez confirmer que l’adresse IP Elastic est marquée avec `AWSRDSCustom`.  |  Aucune  | 
|  échec  |  RDS-EVENT-0283  |  RDS Custom n’a pas pu modifier l’instance de base de données, car la limite d’adresses IP Elastic a été atteinte dans votre compte. Libérez Elastic non utilisé IPs ou demandez une augmentation du quota de votre limite d'adresses IP Elastic.  |  Aucune  | 
|  échec  |  RDS-EVENT-0284  |  RDS Custom n'a pas pu convertir l'instance en haute disponibilité car le pré-contrôle a échoué. *message*  |  *message*Cela inclut des détails sur la panne.  | 
|  échec  |  RDS-EVENT-0285  |  RDS Custom n'a pas pu créer un instantané final pour l'instance de base de données car*message*.  |  *message*Cela inclut des détails sur la panne.  | 
|  échec  |  RDS-EVENT-0421  |  RDS Custom n'a pas pu convertir l'instance de base de données en un déploiement multi-AZ :. *message* L’instance restera un déploiement mono-AZ. Consultez le Guide de l’utilisateur RDS pour plus d’informations sur les déploiements multi-AZ pour RDS Custom for Oracle.  |  *message*Cela inclut des détails sur la panne.  | 
|  échec  | RDS-EVENT-0306 |  La mise à niveau de la configuration du stockage a échoué. Veuillez réessayer.  | Aucune | 
|  échec  | RDS-EVENT-0315 |  Impossible de déplacer la base de données réseau incompatible vers *name* l'état disponible : *message*  |  La configuration réseau de la base de données n’est pas valide. La base de données n’a pas pu être déplacée du réseau incompatible vers un réseau disponible.  | 
| échec | RDS-EVENT-0328 |  Impossible de joindre un hôte vers un domaine. Le statut d'adhésion au domaine, par exemple, *instancename* a été défini sur Échec.  | Aucune | 
| échec | RDS-EVENT-0329 |  Impossible de joindre un hôte à votre domaine. Au cours du processus de jonction de domaine, Microsoft Windows a renvoyé le code d'erreur*message*. Vérifiez les configurations de votre réseau et de vos autorisations et émettez une demande `modify-db-instance` pour tenter à nouveau de rejoindre le domaine.  | Lorsque vous utilisez un annuaire Active Directory autogéré, consultez [Résolution des problèmes liés à Active Directory autogéré](USER_SQLServer_SelfManagedActiveDirectory.TroubleshootingSelfManagedActiveDirectory.md). | 
| échec | RDS-EVENT-0353 |  L'instance de base de données ne peut pas être créée en raison de limites de ressources insuffisantes. *message*.  |  *message*Cela inclut des détails sur la panne.  | 
| échec | RDS-EVENT-0356 |  RDS n’a pas pu configurer le point de terminaison Kerberos dans votre domaine. Cela peut empêcher l’authentification Kerberos pour votre instance de base de données. Vérifiez la configuration réseau entre votre instance de base de données et les contrôleurs de domaine.  | Aucune | 
| échec | RDS-EVENT-0418 | Amazon RDS ne parvient pas à accéder à la clé de KMS chiffrement de l'instance *name* de base de données. Cela est probablement dû à la désactivation de la clé ou à l’impossibilité pour Amazon RDS d’y accéder. Si cela continue, la base de données sera placée dans un état inaccessible. Reportez-vous à la section sur la résolution des problèmes dans la documentation Amazon RDS pour plus de détails. | Aucune | 
| échec | RDS-EVENT-0420 | Amazon RDS peut désormais accéder avec succès à la clé de KMS chiffrement de l'instance *name* de base de données. | Aucune | 
|  stockage faible  | RDS-EVENT-0007 |  L’espace de stockage alloué est épuisé. Allouez du stockage supplémentaire pour résoudre le problème.  |  L’espace de stockage alloué pour l’instance de base de données a été consommé. Pour résoudre ce problème, allouez de l’espace de stockage supplémentaire à l’instance de base de données. Pour plus d’informations, consultez la [FAQ RDS](https://aws.amazon.com/rds/faqs). Vous pouvez surveiller l’espace de stockage pour une instance de base de données à l’aide de la métrique **Free Storage Space (Espace de stockage libre)**.  | 
|  stockage faible  | RDS-EVENT-0089 |  La capacité de stockage gratuite pour l'instance de base *percentage* de données : *name* est faible par rapport au stockage provisionné [Stockage provisionné :*size*, Stockage gratuit :*size*]. Vous pouvez augmenter le stockage provisionné pour résoudre ce problème.  |  L’instance de base de données a consommé plus de 90 % de son stockage alloué. Vous pouvez surveiller l’espace de stockage pour une instance de base de données à l’aide de la métrique **Free Storage Space (Espace de stockage libre)**.  | 
|  stockage faible  | RDS-EVENT-0227 |  L'espace de stockage de votre cluster Aurora est dangereusement bas, il ne reste que des *amount* téraoctets. Veuillez prendre des mesures pour réduire la charge de stockage de votre cluster.  |  Le sous-système de stockage Aurora manque d’espace.  | 
|  maintenance  | RDS-EVENT-0026 |  Application de correctifs hors ligne à l’instance de base de données.  |  La maintenance hors connexion de l’instance de base de données est en cours. L’instance de base de données n’est pas disponible actuellement.  | 
|  maintenance  | RDS-EVENT-0027 |  Application de correctifs hors ligne à l’instance de base de données terminée.  |  La maintenance hors connexion de l’instance de base de données est terminée. L’instance de base de données est désormais disponible.  | 
|  maintenance  | RDS-EVENT-0047 |  Instance de base de données corrigée.  | Aucune | 
|  maintenance  | RDS-EVENT-0155 |  Une mise à niveau de version mineure du moteur de base de données est disponible pour l’instance de base de données.  | Aucune | 
|  maintenance  | RDS-EVENT-0178 |  La mise à niveau de l’instance de base de données est en cours.  | Aucune | 
|  maintenance  | RDS-EVENT-0264 |  La vérification préalable a commencé pour la mise à niveau de la version du moteur de base de données.  | Aucune | 
|  maintenance  | RDS-EVENT-0265 |  La vérification préalable est terminée pour la mise à niveau de la version du moteur de base de données.  | Aucune | 
|  maintenance  | RDS-EVENT-0266 |  La durée d’indisponibilité a commencé pour l’instance de base de données.  | Aucune | 
|  maintenance  | RDS-EVENT-0267 |  La mise à niveau de la version du moteur a commencé.  | Aucune | 
|  maintenance  | RDS-EVENT-0268 |  La mise à niveau de la version du moteur est terminée. | Aucune | 
|  maintenance  | RDS-EVENT-0269 |  Les tâches postérieures à la mise à niveau sont en cours. | Aucune | 
|  maintenance  | RDS-EVENT-0270 |  La mise à niveau de version du moteur de base de données a échoué. La restauration de la mise à niveau de la version du moteur a réussi. | Aucune | 
|  maintenance  | RDS-EVENT-0398 |  En attente de la fin de la mise à niveau de la version du moteur de base de données sur l’instance de base de données primaire. | Émis sur une réplique en lecture lors d’une mise à niveau majeure d’une version du moteur. | 
|  maintenance  | RDS-EVENT-0399 |  En attente de la fin de la mise à niveau de la version du moteur de base de données sur les répliques de lecture. | Émis sur le moteur de base de données source lors d’une mise à niveau majeure d’une version du moteur. | 
|  maintenance  | RDS-EVENT-0422 |  RDS remplacera l'hôte de l'instance de base de données *name* en raison d'une action de maintenance en attente. | Aucune | 
|  maintenance, échec  | RDS-EVENT-0195 |  *message*  |  La mise à jour du fichier sur le fuseau horaire Oracle a échoué. Pour de plus amples informations, veuillez consulter [Mise à niveau automatique du fichier sur le fuseau horaire Oracle](Appendix.Oracle.Options.Timezone-file-autoupgrade.md).  | 
|  maintenance, notification  | RDS-EVENT-0191 |  La mise à jour d’une nouvelle version du fichier sur le fuseau horaire est disponible.  |  Si vous mettez à jour votre moteur de base de données RDS for Oracle, Amazon RDS génère cet événement si vous n’avez pas choisi de mise à niveau du fichier sur le fuseau horaire et que la base de données n’utilise pas le dernier fichier sur le fuseau horaire de l’heure d’été disponible sur l’instance. Pour de plus amples informations, veuillez consulter [Mise à niveau automatique du fichier sur le fuseau horaire Oracle](Appendix.Oracle.Options.Timezone-file-autoupgrade.md).  | 
|  maintenance, notification  | RDS-EVENT-0192 |  La mise à jour de votre fichier sur le fuseau horaire a démarré.  |  La mise à niveau de votre fichier sur le fuseau horaire Oracle a commencé. Pour plus d’informations, consultez [Mise à niveau automatique du fichier sur le fuseau horaire Oracle](Appendix.Oracle.Options.Timezone-file-autoupgrade.md).  | 
|  maintenance, notification  | RDS-EVENT-0193 |  Aucune mise à jour n’est disponible pour la version actuelle du fichier sur le fuseau horaire.  |  Votre instance de base de données Oracle utilise la dernière version du fichier sur le fuseau horaire, et l’une des conditions suivantes est vraie : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_Events.Messages.html) Pour plus d’informations, consultez [Mise à niveau automatique du fichier sur le fuseau horaire Oracle](Appendix.Oracle.Options.Timezone-file-autoupgrade.md).  | 
|  maintenance, notification  | RDS-EVENT-0194 |  La mise à jour de votre fichier sur le fuseau horaire est terminée.  |  La mise à jour de votre fichier sur le fuseau horaire Oracle est terminée. Pour de plus amples informations, veuillez consulter [Mise à niveau automatique du fichier sur le fuseau horaire Oracle](Appendix.Oracle.Options.Timezone-file-autoupgrade.md).  | 
|  notification  | RDS-EVENT-0044 |  *message*  | Il s’agit d’une notification émise par l’opérateur. Pour plus d’informations, consultez le message de l’événement. | 
|  notification  | RDS-EVENT-0048 |  La mise à niveau du moteur de base de données est retardée, car cette instance comporte des réplicas en lecture qui doivent d’abord être mis à niveau.  | L’application des correctifs de l’instance de base de données a été retardée. | 
|  notification  | RDS-EVENT-0054 |  *message*  | Le moteur de stockage MySQL que vous utilisez n’est pas InnoDB, lequel est le moteur de stockage MySQL recommandé pour Amazon RDS. Pour obtenir des informations sur les moteurs de stockage MySQL, consultez [Moteurs de stockage pris en charge pour RDS for MySQL](MySQL.Concepts.FeatureSupport.md#MySQL.Concepts.Storage). | 
|  notification  | RDS-EVENT-0055 |  *message*  |  Le nombre de tables de votre instance de base de données dépasse les bonnes pratiques recommandées pour Amazon RDS. Réduisez le nombre de tables de votre instance de base de données. Pour plus d’informations sur les bonnes pratiques recommandées, consultez [Directives opérationnelles de base Amazon RDS](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).  | 
|  notification  | RDS-EVENT-0056 |  *message*  |  Le nombre de bases de données de votre instance de base de données dépasse les bonnes pratiques recommandées pour Amazon RDS. Réduisez le nombre de bases de données de votre instance de base de données. Pour plus d’informations sur les bonnes pratiques recommandées, consultez [Directives opérationnelles de base Amazon RDS](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).  | 
|  notification  | RDS-EVENT-0064 |  La rotation de la clé de chiffrement TDE a réussi.  | Pour plus d’informations sur les bonnes pratiques recommandées, consultez [Directives opérationnelles de base Amazon RDS](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).  | 
|  notification  | RDS-EVENT-0084 |  Impossible de convertir l'instance de base de données en instance multi-AZ :*message*.  |  Vous avez essayé de convertir une instance de base de données en environnement Multi-AZ, mais elle contient des groupes de fichiers en mémoire qui ne sont pas pris en charge pour plusieurs environnements Multi-AZ. Pour plus d’informations, consultez [Déploiements multi-AZ pour Amazon RDS for Microsoft SQL Server](USER_SQLServerMultiAZ.md).   | 
|  notification  | RDS-EVENT-0087 |  Instance de base de données arrêtée.   | Aucune | 
|  notification  | RDS-EVENT-0088 |  Instance de base de données démarrée.  | Aucune | 
|  notification  | RDS-EVENT-0154 |  L’instance de base de données est en cours de démarrage dans la mesure où elle a dépassé le temps maximum autorisé pour son arrêt.  | Aucune | 
|  notification  | RDS-EVENT-0157 |  Impossible de modifier la classe d'instance de base de données. *message*.  |  RDS ne peut pas modifier la classe d’instance de base de données, car la classe d’instance cible ne peut pas prendre en charge le nombre de bases de données figurant dans l’instance de base de données source. Le message d’erreur suivant apparaît : "The instance has *N* databases, but after conversion it would only support *N*" (L’instance comporte N bases de données, mais après la conversion, elle n’en prendrait en charge que N). Pour plus d’informations, consultez [Limites propres aux instances de bases de données Microsoft SQL Server](CHAP_SQLServer.md#SQLServer.Concepts.General.FeatureSupport.Limits).  | 
|  notification  | RDS-EVENT-0158 |  L'instance de base de données est dans un état qui ne peut pas être mise à niveau :*message*.  | Aucune | 
|  notification  | RDS-EVENT-0167 |  *message*  |  La configuration du périmètre de prise en charge de RDS Custom a été modifiée.  | 
|  notification  | RDS-EVENT-0189 |  Les crédits de solde de la rafale gp2 pour l’instance de base de données RDS sont faibles. Pour résoudre ce problème, réduisez l’utilisation IOPS ou modifiez vos paramètres de stockage pour augmenter les performances.  |  Les crédits de solde de la rafale gp2 pour l’instance de base de données RDS sont faibles. Pour résoudre ce problème, réduisez l’utilisation IOPS ou modifiez vos paramètres de stockage pour augmenter les performances. Pour plus d’informations, consultez [Crédits I/O et performances en rafale](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html#EBSVolumeTypes_gp2) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.  | 
|  notification  | RDS-EVENT-0225 |  La taille de stockage allouée en *amount* Go approche le seuil de stockage maximal en *amount* Go. Augmentez le seuil de stockage maximal.  |  Cet événement est invoqué lorsque le stockage alloué atteint 80 % du seuil de stockage maximal. Pour éviter cet événement, augmentez le seuil de stockage maximum.  | 
|  notification  | RDS-EVENT-0231 |  La modification du stockage de votre instance de base de données a rencontré une erreur interne. La requête de modification est en attente et sera réitérée ultérieurement.  |  Une erreur s’est produite lors du processus de réplication en lecture. Pour plus d’informations, consultez le message de l’événement. En outre, consultez la section de dépannage pour les réplicas en lecture de votre moteur de base de données. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_Events.Messages.html)  | 
|  notification  | RDS-EVENT-0253 |  La base de données utilise le tampon doublewrite. *message*. Pour plus d'informations, consultez la *name* documentation relative aux écritures optimisées RDS.  | La fonctionnalité RDS Optimized Writes n’est pas compatible avec la configuration de stockage de l’instance. Pour plus d’informations, consultez [Amélioration des performances d'écriture avec Écritures optimisées pour RDS for MySQL](rds-optimized-writes.md) et [Amélioration des performances d'écriture avec Écritures optimisées pour Amazon RDS for MariaDB](rds-optimized-writes-mariadb.md). Vous pouvez effectuer une mise à niveau de la configuration du stockage pour activer les écritures optimisées en [créant un blue/green déploiement](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-creating.html). | 
|  notification  | RDS-EVENT-0297 |  La configuration de stockage pour l'instance de base de données *name* prend en charge une taille maximale de 16384 GiB. Effectuez une mise à niveau de la configuration du stockage pour prendre en charge des volumes de stockage supérieurs à 16 384 Gio.  | Vous ne pouvez pas augmenter le volume de stockage alloué à l’instance de base de données au-delà de 16 384 Gio. Pour remédier à cette limitation, mettez à niveau la configuration du stockage. Pour plus d’informations, consultez [Mise à niveau du système de fichiers de stockage d’une instance de base de données](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.UpgradeFileSystem).  | 
|  notification  | RDS-EVENT-0298 |  La configuration de stockage pour l'instance de base de données *name* prend en charge une taille de table maximale de 2 048 GiB. Mettez à niveau la configuration de stockage pour que les tables supérieures à 2 048 Gio soient prises en charge.  | Les instances RDS MySQL et MariaDB soumises à cette limitation ne peuvent pas avoir une taille de table supérieure à 2 048 Gio. Pour remédier à cette limitation, mettez à niveau la configuration du stockage. Pour plus d’informations, consultez [Mise à niveau du système de fichiers de stockage d’une instance de base de données](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.UpgradeFileSystem).  | 
|  notification  | RDS-EVENT-0327 |  Amazon RDS n'a pas pu trouver le secret*SECRET ARN*. *message.*  | Aucune | 
|  notification  | RDS-EVENT-0365 |  Les fichiers de fuseau horaire ont été mis à jour. Redémarrez votre instance RDS pour que les modifications prennent effet.  | Aucune | 
|  notification  | RDS-EVENT-0385 |  La topologie du cluster est mise à jour.  |  Des modifications de DNS ont été apportées au cluster de bases de données pour l’instance de base de données. Cela inclut lorsque de nouvelles instances de base de données sont ajoutées ou supprimées, ou en cas de basculement.  | 
|  notification  | RDS-EVENT-0403 |  Une charge de travail de base de données fait que le système manque cruellement de mémoire. Pour atténuer le problème, RDS a automatiquement défini la valeur de innodb\$1buffer\$1pool\$1size sur. *amount*  |  S’applique uniquement aux instances de bases de données RDS for MySQL et RDS for MariaDB.  | 
|  notification  | RDS-EVENT-0404  |  Une charge de travail de base de données fait que le système manque cruellement de mémoire. Pour atténuer le problème, RDS a automatiquement défini la valeur de shared\$1buffers sur. *amount*  |  S’applique uniquement aux instances de base de données RDS pour PostgreSQL.  | 
|  réplica en lecture  | RDS-EVENT-0045 |  La réplication s’est arrêtée.  |  Ce message s’affiche lorsqu’il y a une erreur lors de la réplication. Pour déterminer le type d’erreur, consultez [ Troubleshooting a MySQL read replica problem](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.Troubleshooting.html).  | 
|  réplica en lecture  | RDS-EVENT-0046 |  Reprise de la réplication pour le réplica en lecture.  | Ce message s’affiche lorsque vous créez un réplica en lecture, ou comme message de surveillance lorsque vous confirmez que la réplication fonctionne correctement. Si ce message fait suite à une notification `RDS-EVENT-0045`, la réplication a repris suite à une erreur ou à un arrêt de la réplication. | 
|  réplica en lecture  | RDS-EVENT-0057 |  Le streaming de réplication a été suspendu.  | Aucune | 
|  réplica en lecture  | RDS-EVENT-0062 |  La réplication pour le réplica en lecture a été arrêtée manuellement.  | Aucune | 
|  réplica en lecture  | RDS-EVENT-0063 |  La réplication depuis une instance autre que RDS a été réinitialisée.  | Aucune | 
|  réplica en lecture  | RDS-EVENT-0202 |  La création d’un réplica en lecture a échoué.  | Aucune | 
|  réplica en lecture  | RDS-EVENT-0233  |  La bascule vers le réplica en lecture a commencé.  | Aucune | 
|  réplica en lecture  | RDS-EVENT-0357  |  Le canal de réplication *name* a démarré.  | Pour plus d’informations sur les canaux de réplication, consultez [Configuration multi-source-replication pour Amazon RDS for MySQL](mysql-multi-source-replication.md). | 
|  réplica en lecture  | RDS-EVENT-0358  |  Le canal de réplication *name* s'est arrêté.  | Pour plus d’informations sur les canaux de réplication, consultez [Configuration multi-source-replication pour Amazon RDS for MySQL](mysql-multi-source-replication.md). | 
|  réplica en lecture  | RDS-EVENT-0359  |  Le canal de réplication *name* a été arrêté manuellement.  | Pour plus d’informations sur les canaux de réplication, consultez [Configuration multi-source-replication pour Amazon RDS for MySQL](mysql-multi-source-replication.md). | 
|  réplica en lecture  | RDS-EVENT-0360  |  Le canal de réplication *name* a été réinitialisé.  | Pour plus d’informations sur les canaux de réplication, consultez [Configuration multi-source-replication pour Amazon RDS for MySQL](mysql-multi-source-replication.md). | 
|  réplica en lecture  | RDS-EVENT-0415  |  Le processus de mise à niveau a repris la réplication sur la réplique en lecture.  | Aucune | 
|  réplica en lecture  | RDS-EVENT-0416  |  Le processus de mise à niveau a arrêté la réplication sur la réplique en lecture.  | Aucune | 
|  récupération  | RDS-EVENT-0020 |  La récupération de l’instance de base de données a démarré. Le temps de récupération varie selon la quantité de données à restaurer.  | Aucune | 
|  ponctuelle  | RDS-EVENT-0021 |  La récupération de l’instance de base de données est terminée.  | Aucune | 
|  ponctuelle  | RDS-EVENT-0023 |  Demande de capture instantanée urgente :*message*.  |  Une sauvegarde manuelle a été demandée, mais Amazon RDS est actuellement en cours de création d’un instantané de base de données. Soumettez à nouveau la demande après qu’Amazon RDS a terminé l’instantané de base de données.  | 
|  récupération  | RDS-EVENT-0052 |  La récupération de l’instance multi-AZ a démarré.  | Le temps de récupération varie selon la quantité de données à restaurer. | 
|  récupération  | RDS-EVENT-0053 |  La récupération de l’instance multi-AZ est terminée. En attente de basculement ou d’activation.  | Ce message indique qu’Amazon RDS a préparé votre instance de base de données pour lancer un basculement vers l’instance secondaire si nécessaire. | 
|  ponctuelle  | RDS-EVENT-0066 |  L'instance sera dégradée lors du rétablissement de la mise en miroir :. *message*  |  L’instance de base de données SQL Server est en train de rétablir son miroir. Les performances seront dégradées tant que le miroir n’est pas restauré. Il a été trouvé une base de données avec un modèle de récupération autre que FULL. Le modèle de récupération a été remodifié en FULL et la récupération de la mise en miroir a démarré. (<dbname>: <recovery model found>[,...])”  | 
|  ponctuelle  | RDS-EVENT-0166 |  *message*  |  L’instance de base de données RDS Custom se trouve dans le périmètre de prise en charge.  | 
|  ponctuelle  | RDS-EVENT-0361  |  La récupération de l’instance de base de données de secours a démarré.  |  L’instance de base de données de secours est régénérée pendant le processus de régénération. Les performances de la base de données sont affectées pendant le processus de régénération.  | 
|  ponctuelle  | RDS-EVENT-0362  |  La régénération de l’instance de base de données de secours est terminée.  |  L’instance de base de données de secours est régénérée pendant le processus de régénération. Les performances de la base de données sont affectées pendant le processus de régénération.  | 
|  restauration  | RDS-EVENT-0019 |  Restauré depuis une instance de base de données *name* vers*name*.  |  L'instance de base de données a été restaurée à partir d'une point-in-time sauvegarde.  | 
|  sécurité  | RDS-EVENT-0068 |  Déchiffrement du mot de passe de la partition hsm pour mettre à jour l’instance.  |  RDS déchiffre le mot de passe de AWS CloudHSM partition pour mettre à jour l'instance de base de données. Pour plus d’informations, consultez [Chiffrement transparent des données (TDE) des bases de données Oracle avec AWS CloudHSM](https://docs.aws.amazon.com/cloudhsm/latest/userguide/oracle-tde.html) dans le *Guide de l’utilisateur AWS CloudHSM *.  | 
|  application de correctifs de sécurité  | RDS-EVENT-0230 |  La mise à jour du système est disponible pour votre instance de base de données. Pour obtenir des informations sur l’application des mises à niveau, consultez « Entretien d’une instance de base de données » dans le Guide de l’utilisateur RDS.  |  Une nouvelle mise à jour du système d’exploitation est disponible. Une nouvelle mise à jour mineure du système d’exploitation est disponible pour votre instance de base de données. Pour obtenir des informations sur l’application de mises à jour, consultez [Mises à jour du système d’exploitation pour les instances de base de données RDS](USER_UpgradeDBInstance.Maintenance.md#OS_Updates).  | 
|  maintenance  | RDS-EVENT-0425  |  Amazon RDS ne peut pas effectuer de mise à niveau du système d’exploitation, car aucune adresse IP n’est disponible dans les sous-réseaux spécifiés. Choisissez des sous-réseaux avec des adresses IP disponibles et réessayez.  |  Aucune  | 
|  maintenance  | RDS-EVENT-0429  |  Amazon RDS ne peut pas effectuer la mise à niveau du système d'exploitation en raison d'une capacité insuffisante disponible pour le type d'*type*instance dans la zone de *zone* disponibilité  |  Aucune  | 
|  maintenance  | RDS-EVENT-0501  |  Le certificat de serveur de l'instance de base de données Amazon RDS nécessite une rotation dans le cadre d'une action de maintenance en attente.  |  Le certificat de serveur de l'instance de base de données nécessite une rotation dans le cadre d'une action de maintenance en attente. Amazon RDS redémarre votre base de données pendant cette maintenance pour terminer la rotation des certificats. Pour planifier cette maintenance, allez dans l'onglet **Maintenance et sauvegardes** et choisissez **Appliquer maintenant** ou **Planifier pour la fenêtre de maintenance suivante**. Si la modification n'est pas planifiée, Amazon RDS l'applique automatiquement dans votre fenêtre de maintenance à la date d'application automatique indiquée dans votre action de maintenance.  | 
|  maintenance  | RDS-EVENT-0502  |  Amazon RDS a planifié une rotation des certificats de serveur pour l'instance de base de données lors de la prochaine fenêtre de maintenance. Cette maintenance nécessitera le redémarrage de la base de données.  |  Aucune  | 

## Événements de groupe de paramètres de base de données
<a name="USER_Events.Messages.parameter-group"></a>

Le tableau suivant affiche la catégorie d’événement et la liste des événements lorsqu’un groupe de paramètres de base de données est le type source.


|  Catégorie  | ID d’événement RDS |  Message  |  Remarques  | 
| --- | --- | --- | --- | 
|  modification de configuration  | RDS-EVENT-0037 |  Paramètre mis *name* à jour *value* avec méthode d'application*method*.   |  Aucune  | 

## Événements de groupe de sécurité de base de données
<a name="USER_Events.Messages.security-group"></a>

Le tableau suivant affiche la catégorie d’événement et la liste des événements lorsqu’un groupe de sécurité de base de données est le type source.

**Note**  
Les groupes de sécurité de base de données sont des ressources pour EC2-Classic. EC2-Classic a été retiré le 15 août 2022. Si vous n’avez pas migré d’EC2-Classic vers un VPC, nous vous recommandons de le faire dès que possible. Pour plus d’informations, consultez [Migrer d’EC2-Classic vers un VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html) dans le *Guide de l’utilisateur Amazon EC2* et le blog [EC2-Classic Networking is Retiring – Here’s How to Prepare](https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/) (Se préparer au retrait de la mise en réseau EC2-Classic).


|  Catégorie  | ID d’événement RDS |  Message  |  Remarques  | 
| --- | --- | --- | --- | 
|  modification de configuration  | RDS-EVENT-0038 |  Modification appliquée au groupe de sécurité.  |  Aucune  | 
|  échec  | RDS-EVENT-0039 |  Révocation de l'autorisation en tant que*user*.  |  Le groupe de sécurité détenu par *user* n'existe pas. L’autorisation pour le groupe de sécurité a été révoquée, car elle n’est pas valide.  | 

## Événements d’instantané de bases de données
<a name="USER_Events.Messages.snapshot"></a>

Le tableau suivant affiche la catégorie d’événement et la liste des événements lorsqu’un instantané de base de données est le type source.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_Events.Messages.html)

## Événements RDS Proxy
<a name="USER_Events.Messages.rds-proxy"></a>

Le tableau suivant recense la catégorie d’événement et la liste des événements lorsqu’un proxy RDS Proxy est le type source.


|  Catégorie  | ID d’événement RDS |  Message  |  Remarques  | 
| --- | --- | --- | --- | 
| modification de configuration | RDS-EVENT-0204 |  Proxy *name* de base de données modifié par RDS.  | Aucune | 
| modification de configuration | RDS-EVENT-0207 |  RDS a modifié le point final du proxy *name* de base de données.  | Aucune | 
| modification de configuration | RDS-EVENT-0213 |  RDS a détecté l'ajout de l'instance de base de données et l'a automatiquement ajoutée au groupe cible du proxy *name* de base de données.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0214 |  RDS a détecté la suppression de l'instance de base de données *name* et l'a automatiquement supprimée du groupe cible du proxy *name* *name* de base de données.  | Aucune | 
|  modification de configuration  | RDS-EVENT-0215 |  RDS a détecté la suppression du cluster de base de données *name* et l'a automatiquement supprimé du groupe cible du proxy *name* *name* de base de données.  | Aucune | 
|  création  | RDS-EVENT-0203 |  RDS a créé un proxy *name* de base de données.  | Aucune | 
|  création  | RDS-EVENT-0206 |  RDS a créé un point de terminaison *name* pour le proxy *name* de base de données.  | Aucune | 
| suppression | RDS-EVENT-0205 |  RDS a supprimé le proxy *name* de base de données.  | Aucune | 
|  suppression  | RDS-EVENT-0208 |  RDS a supprimé le point de terminaison *name* pour le proxy *name* de base de données.  | Aucune | 
|  échec  | RDS-EVENT-0243 |  RDS n'a pas pu fournir de capacité pour le proxy *name* car il n'y a pas assez d'adresses IP disponibles dans vos sous-réseaux :. *name* Pour résoudre ce problème, veillez à ce que vos sous-réseaux aient le nombre minimum d’adresses IP inutilisées, comme recommandé dans la documentation Proxy RDS.  |  Pour déterminer le nombre recommandé pour votre classe d’instances, consultez [Planification de la capacité des adresses IP](rds-proxy-network-prereqs.md#rds-proxy-network-prereqs.plan-ip-address).  | 
|  échec | RDS-EVENT-0275 |  RDS a limité certaines connexions au proxy de base de données. *name* Le nombre de demandes de connexion simultanée du client au proxy a dépassé la limite.  | Aucune | 

## Événements de déploiement bleu/vert
<a name="USER_Events.Messages.BlueGreenDeployments"></a>

Le tableau suivant indique la catégorie d'événements et la liste des événements dont le type source est un blue/green déploiement.

Pour plus d'informations sur les blue/green déploiements, consultez[Utilisation d'Amazon RDS ( Blue/Green Deployments) pour les mises à jour de bases de données](blue-green-deployments.md).


|  Catégorie  | ID d’événement Amazon RDS |  Message  |  Remarques  | 
| --- | --- | --- | --- | 
|  création  | RDS-EVENT-0244 |  Les tâches de déploiement bleu/vert sont terminées. Vous pouvez apporter plus de modifications aux bases de données de l’environnement vert ou effectuer un basculement du déploiement.  | Aucune | 
|  échec  | RDS-EVENT-0245 |  La création du blue/green déploiement a échoué car*reason*.  | Aucune | 
|  suppression  | RDS-EVENT-0246 |  Le déploiement bleu/vert a été supprimé.  | Aucune | 
|  notification  | RDS-EVENT-0247 |  Basculer entre le mode de démarrage et le mode *blue* de démarrage. *green*  | Aucune | 
|  notification  | RDS-EVENT-0248 |  Le passage au numérique a été effectué lors blue/green du déploiement.  | Aucune | 
|  échec  | RDS-EVENT-0249 |  Le passage au numérique a été annulé lors blue/green du déploiement.  | Aucune | 
|  notification  | RDS-EVENT-0250  |  Basculement du cluster de de données de réplication principal/en lecture au cluster démarré. *blue* *green*  | Aucune | 
|  notification  | RDS-EVENT-0251  |  Passage du cluster de base de principal/de réplication en lecture au cluster terminé. *blue* *green* Renommé *blue* *blue-old* en et *green* en*blue*.  | Aucune | 
|  échec  | RDS-EVENT-0252  |  Le passage du cluster de base de données de réplication principal/de lecture au *blue* en raison de. *reason*  | Aucune | 
|  notification  | RDS-EVENT-0307  |  La synchronisation de séquence pour le passage du *blue* à *green* a été initiée. La bascule lors de l’utilisation de séquences peut entraîner une durée d’indisponibilité prolongée.  | Aucune | 
|  notification  | RDS-EVENT-0308  |  La synchronisation de séquence pour le passage du *blue* à *green* est terminée.  | Aucune | 
|  échec  | RDS-EVENT-0310  |  La synchronisation des séquences pour le passage du *blue* à *green* a été annulée car les séquences n'ont pas pu être synchronisées.  | Aucune | 
| notification | RDS-EVENT-0405  |  Vos volumes de stockage sont en cours d’initialisation.  |  Aucune  | 
| notification | RDS-EVENT-0406  |  Vos volumes de stockage ont été initialisés.  |  Aucune  | 
|  notification  | RDS-EVENT-0409   |  *message*  | Aucune | 

## Événements de version du moteur personnalisés
<a name="USER_Events.Messages.CEV"></a>

Le tableau suivant présente la catégorie d’événement et une liste d’événements lorsqu’une version personnalisée du moteur est le type de source.


|  Catégorie  | ID d’événement Amazon RDS |  Message  |  Remarques  | 
| --- | --- | --- | --- | 
|  création  | RDS-EVENT-0316 |  Préparation à la création d'une version personnalisée du moteur*name*. L’ensemble du processus de création peut prendre jusqu’à quatre heures.  | Aucune | 
|  création  | RDS-EVENT-0317 |  Création d'une version personnalisée du moteur*name*.  | Aucune | 
|  création  | RDS-EVENT-0318 |  Validation de la version *name* personnalisée du moteur.  | Aucune | 
|  création  | RDS-EVENT-0319 |  La version personnalisée du moteur *name* a été créée avec succès.  | Aucune | 
|  création  | RDS-EVENT-0320 |  RDS ne peut pas créer de version de moteur personnalisée en *name* raison d'un problème interne. Nous sommes en train de résoudre le problème et nous vous contacterons si nécessaire. Pour obtenir de l’aide supplémentaire, contactez [l’assistance Premium AWS](https://console.aws.amazon.com/support/).  | Aucune | 
|  échec  | RDS-EVENT-0198 |  La création de la version personnalisée du moteur a échoué*name*. *message*  | *message*Cela inclut des détails sur l'échec, tels que les fichiers manquants. | 
|  échec  | RDS-EVENT-0277 |  Échec lors de la suppression de la version personnalisée du moteur*name*. *message*  | *message*Cela inclut des détails sur la panne. | 
|  restauration  | RDS-EVENT-0352  |  Le nombre maximal de bases de données prises en charge pour point-in-time la restauration a changé.  | *message*Il inclut des détails sur l'événement. | 

# Surveillance des fichiers journaux Amazon RDS
<a name="USER_LogAccess"></a>

Chaque moteur de base de données RDS génère des journaux auxquels vous pouvez accéder pour l'audit et le dépannage. Le type de journaux dépend de votre moteur de base de données.

Vous pouvez accéder aux journaux de base de données pour les instances de base de données à l’aide de la AWS Management Console, de l’AWS Command Line Interface (AWS CLI) ou de l’API Amazon RDS. Vous ne pouvez pas afficher, visualiser ou télécharger les journaux des transactions.

**Topics**
+ [Liste et affichage des fichiers journaux de base de données](USER_LogAccess.Procedural.Viewing.md)
+ [Téléchargement d'un fichier journal de base de données](USER_LogAccess.Procedural.Downloading.md)
+ [Consultation d’un fichier journal de base de données](USER_LogAccess.Procedural.Watching.md)
+ [Publication des journaux de base de données dans Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md)
+ [Lecture du contenu des fichiers journaux avec REST](DownloadCompleteDBLogFile.md)
+ [Fichiers journaux de base de données Amazon RDS for Db2](USER_LogAccess.Concepts.Db2.md)
+ [Fichiers journaux de base de données MariaDB](USER_LogAccess.Concepts.MariaDB.md)
+ [Fichiers journaux de base de données Amazon RDS for Microsoft SQL Server](USER_LogAccess.Concepts.SQLServer.md)
+ [Fichiers journaux de base de données MySQL](USER_LogAccess.Concepts.MySQL.md)
+ [Fichiers journaux de base de données Amazon RDS for Oracle](USER_LogAccess.Concepts.Oracle.md)
+ [Fichiers journaux de base de données RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md)

# Liste et affichage des fichiers journaux de base de données
<a name="USER_LogAccess.Procedural.Viewing"></a>

Vous pouvez afficher les fichiers journaux de la base de données de votre moteur de base de données Amazon RDS à l'aide de la commande AWS Management Console. Vous pouvez répertorier les fichiers journaux disponibles pour téléchargement ou surveillance à l'aide de l'AWS CLI ou de l'API Amazon RDS. 

**Note**  
Si vous ne parvenez pas à afficher la liste des fichiers journaux pour une instance de base de données RDS for Oracle existante, redémarrez l'instance. 

## Console
<a name="USER_LogAccess.CON"></a>

**Pour afficher un fichier journal de base de données**

1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans la panneau de navigation, choisissez **Bases de données**.

1. Choisissez le nom de l’instance de base de données qui contient le fichier journal que vous voulez consulter.

1. Choisissez l’onglet **Logs & events** (Journaux et événements).

1. Faites défiler jusqu’à la section **Journaux**.

1. (Facultatif) Entrez un terme de recherche pour filtrer vos résultats.

1. Sélectionnez le journal que vous souhaitez afficher, puis cliquez sur **View** (Afficher).

## AWS CLI
<a name="USER_LogAccess.CLI"></a>

Pour répertorier les fichiers journaux de base de données disponibles pour une instance de base de données, utilisez la commande [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html) de l'`describe-db-log-files`.

L'exemple suivant renvoie une liste des fichiers journaux pour une instance DB nommée `my-db-instance`.

**Example**  

```
1. aws rds describe-db-log-files --db-instance-identifier my-db-instance
```

## API RDS
<a name="USER_LogAccess.API"></a>

Pour répertorier les fichiers journaux de base de données disponibles pour une instance de base de données, utilisez l'action [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html) de l'API Amazon RDS.

# Téléchargement d'un fichier journal de base de données
<a name="USER_LogAccess.Procedural.Downloading"></a>

Vous pouvez utiliser la AWS Management Console, AWS CLI ou l'API pour télécharger un fichier journal de base de données. 

## Console
<a name="USER_LogAccess.Procedural.Downloading.CON"></a>

**Pour télécharger un fichier journal de base de données**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**.

1. Choisissez le nom de l'instance de base de données qui contient le fichier journal que vous voulez consulter.

1. Choisissez l’onglet **Logs & events** (Journaux et événements).

1. Faites défiler jusqu'à la section **Journaux**. 

1. Dans la section **Journaux**, sélectionnez le bouton en regard du journal que vous voulez télécharger, puis choisissez **Télécharger**.

1. Ouvrez le menu contextuel (clic droit) pour le lien fourni, puis choisissez **Enregistrer le lien sous**. Saisissez l'emplacement souhaité pour l'enregistrement du fichier journal, puis cliquez sur **Enregistrer**.  
![\[affichage du fichier journal\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/log_download2.png)

## AWS CLI
<a name="USER_LogAccess.Procedural.Downloading.CLI"></a>

Pour télécharger un fichier journal de base de données, utilisez la commande [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html) de l'`download-db-log-file-portion`. Par défaut, cette commande télécharge uniquement la portion la plus récente d'un fichier journal. Vous pouvez toutefois télécharger un fichier complet en spécifiant le paramètre `--starting-token 0`.

L'exemple suivant montre comment télécharger le contenu d'un fichier journal appelé *log/ERROR.4* et le stocker dans un fichier local appelé *errorlog.txt*.

**Example**  
Pour Linux, macOS ou Unix :  

```
1. aws rds download-db-log-file-portion \
2.     --db-instance-identifier myexampledb \
3.     --starting-token 0 --output text \
4.     --log-file-name log/ERROR.4 > errorlog.txt
```
Pour Windows :  

```
1. aws rds download-db-log-file-portion ^
2.     --db-instance-identifier myexampledb ^
3.     --starting-token 0 --output text ^
4.     --log-file-name log/ERROR.4 > errorlog.txt
```

## API RDS
<a name="USER_LogAccess.Procedural.Downloading.API"></a>

Pour télécharger un fichier journal de base de données, utilisez l'action [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html) de l'API Amazon RDS.

# Consultation d’un fichier journal de base de données
<a name="USER_LogAccess.Procedural.Watching"></a>

Surveiller un fichier journal de base de données revient à suivre le fichier sur un système UNIX ou Linux. Vous pouvez afficher un fichier journal en utilisant la AWS Management Console. RDS rafraîchit la queue du journal toutes les cinq secondes.

**Pour consulter un fichier journal de base de données**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**.

1. Choisissez le nom de l’instance de base de données qui contient le fichier journal que vous voulez consulter.

1. Choisissez l’onglet **Logs & events** (Journaux et événements).  
![\[Choisissez l’onglet Logs & events (Journaux et événements)\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/Monitoring_logsEvents.png)

1. Dans la section **Journaux**, choisissez un fichier journal, puis **Consulter**.  
![\[Choisissez un journal\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/Monitoring_LogsEvents_watch.png)

   RDS affiche la queue du journal, comme dans l’exemple MySQL suivant.  
![\[Queue d’un fichier journal\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/Monitoring_LogsEvents_watch_content.png)

# Publication des journaux de base de données dans Amazon CloudWatch Logs
<a name="USER_LogAccess.Procedural.UploadtoCloudWatch"></a>

Dans une base de données sur site, les journaux de la base de données résident sur le système de fichiers. Amazon RDS ne fournit pas d'accès hôte aux journaux de la base de données sur le système de fichiers de votre instance de base de données. Pour cette raison, Amazon RDS vous permet d'exporter les journaux de la base de données vers [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). CloudWatch Logs vous permet d'effectuer une analyse en temps réel des données de journaux. Vous pouvez également stocker les données dans un stockage hautement durable et gérer les données grâce à l'agent CloudWatch Logs. 

**Topics**
+ [Présentation de l'intégration de RDS avec CloudWatch Logs](#rds-integration-cw-logs)
+ [Décider des journaux à publier dans CloudWatch Logs](#engine-specific-logs)
+ [Spécification des journaux à publier dans CloudWatch Logs](#integrating_cloudwatchlogs.configure)
+ [Recherche et filtrage de vos journaux dans CloudWatch Logs](#accessing-logs-in-cloudwatch)

## Présentation de l'intégration de RDS avec CloudWatch Logs
<a name="rds-integration-cw-logs"></a>

Dans CloudWatch Logs, un *flux de journaux* est une séquence d'événements de journaux qui partagent la même source. Chaque source distincte de journaux dans CloudWatch Logs constitue un flux de journaux distinct. Un *groupe de journaux* est un groupe de flux de journaux qui partagent les mêmes paramètres de conservation, de surveillance et de contrôle d'accès.

Amazon RDS diffuse en continu les enregistrements des journaux de votre instance de base de données vers un groupe de journaux. Par exemple, vous possédez un groupe de journaux `/aws/rds/instance/instance_name/log_type` pour chaque type de journaux que vous publiez. Ce groupe de journaux se trouve dans la même région AWS que l'instance de base de données qui génère le journal.

AWS conserve les données de journaux publiées dans CloudWatch Logs pendant une période indéterminée, sauf si vous précisez une durée de conservation. Pour plus d’informations, consultez [Modification de la conservation des données de journaux dans CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention). 

## Décider des journaux à publier dans CloudWatch Logs
<a name="engine-specific-logs"></a>

Chaque moteur de base de données RDS prend en charge son propre ensemble de journaux. Pour en savoir plus sur les options de votre moteur de base de données, consultez les rubriques suivantes :
+ [Publication de journaux DB2 sur Amazon CloudWatch Logs](USER_LogAccess.Concepts.Db2.md#USER_LogAccess.Db2.PublishtoCloudWatchLogs)
+ [Publier des logs MariaDB sur Amazon Logs CloudWatch](USER_LogAccess.MariaDB.PublishtoCloudWatchLogs.md)
+ [Publication des journaux MySQL dans Amazon CloudWatch Logs](USER_LogAccess.MySQLDB.PublishtoCloudWatchLogs.md)
+ [Publication de journaux Oracle sur Amazon CloudWatch Logs](USER_LogAccess.Concepts.Oracle.md#USER_LogAccess.Oracle.PublishtoCloudWatchLogs)
+ [Publication de journaux PostgreSQL sur Amazon Logs CloudWatch](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs)
+ [Publication des journaux SQL Server sur Amazon CloudWatch Logs](USER_LogAccess.Concepts.SQLServer.md#USER_LogAccess.SQLServer.PublishtoCloudWatchLogs)

## Spécification des journaux à publier dans CloudWatch Logs
<a name="integrating_cloudwatchlogs.configure"></a>

Vous spécifiez les journaux à publier dans la console. Assurez-vous que vous avez un rôle lié au service dans Gestion des identités et des accès AWS (IAM). Pour plus d’informations sur les rôles liés à un service, consultez [Utilisation des rôles liés à un service pour Amazon RDS](UsingWithRDS.IAM.ServiceLinkedRoles.md).

**Pour spécifier les journaux à publier**

1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans la panneau de navigation, choisissez **Bases de données**.

1. Effectuez l’une des actions suivantes :
   + Choisissez **Create database (Créer une base de données)**.
   + Choisissez une base de données dans la liste, puis sélectionnez **Modify** (Modifier).

1. Dans **Logs exports** (Exportations de journaux), choisissez les journaux à publier.

   L’exemple suivant spécifie le journal d’audit, les journaux d’erreurs, le journal général, et le journal des requêtes lentes pour une instance de base de données RDS for MySQL.  
![\[Choix des journaux à publier dans CloudWatch Logs\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/AddCWLogs.png)

## Recherche et filtrage de vos journaux dans CloudWatch Logs
<a name="accessing-logs-in-cloudwatch"></a>

Vous pouvez rechercher des entrées de journal qui correspondent à des critères spécifiés à partir de la console CloudWatch Logs. Vous pouvez accéder aux journaux soit par la console RDS, qui vous conduit à la console CloudWatch Logs, soit directement à partir de la console CloudWatch Logs.

**Pour rechercher les journaux de votre RDS à l'aide de la console RDS**

1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans la panneau de navigation, choisissez **Bases de données**.

1. Choisissez un instance de base de données.

1. Choisissez **Configuration**.

1. Sous **Published logs** (Journaux publiés), choisissez le journal de la base de données que vous souhaitez afficher.

**Pour effectuer une recherche dans vos journaux RDS à l'aide de la console CloudWatch Logs**

1. Ouvrez la console CloudWatch à l’adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. Dans le panneau de navigation, choisissez **Groupes de journaux**.

1. Dans la zone de filtre, entrez **/aws/rds**.

1. Pour **Log Groups**, choisissez le nom du groupe de journaux contenant le flux de journal devant faire l'objet de la recherche.

1. Pour **Log Streams**, choisissez le nom du flux de journal devant faire l'objet de la recherche.

1. Sous **Journal des événements**, saisissez la syntaxe du filtre à utiliser.

Pour obtenir plus d'informations, consultez la section [Searching and filtering log data](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) (Recherche et filtrage des données de journal) dans le *Guide de l'utilisateur d'Amazon CloudWatch Logs* Pour obtenir un tutoriel de blog expliquant comment surveiller les journaux RDS, consultez [Création d'une surveillance proactive des bases de données pour Amazon RDS avec Amazon CloudWatch Logs, AWS Lambda et Amazon SNS](https://aws.amazon.com/blogs/database/build-proactive-database-monitoring-for-amazon-rds-with-amazon-cloudwatch-logs-aws-lambda-and-amazon-sns/).

# Lecture du contenu des fichiers journaux avec REST
<a name="DownloadCompleteDBLogFile"></a>

Amazon RDS fournit un point de terminaison REST qui permet d’accéder aux fichiers journaux des instances de base de données. Ceci est utile si vous devez écrire une application pour diffuser en continu le contenu de fichiers journaux Amazon RDS.

La syntaxe est la suivante :

```
GET /v13/downloadCompleteLogFile/DBInstanceIdentifier/LogFileName HTTP/1.1
Content-type: application/json
host: rds.region.amazonaws.com
```

Les paramètres suivants sont obligatoires :
+ `DBInstanceIdentifier`—le nom assigné par le client de l'instance de base de données qui contient le fichier journal que vous souhaitez télécharger.
+ `LogFileName`—le nom du fichier journal à télécharger.

La réponse contient les contenus du fichier journal demandé, en tant que flux.

L'exemple suivant télécharge le fichier journal appelé *log/ERROR.6* pour l'instance de base de données appelée *sample-sql* dans la région *us-west-2*.

```
GET /v13/downloadCompleteLogFile/sample-sql/log/ERROR.6 HTTP/1.1
host: rds.us-west-2.amazonaws.com
X-Amz-Security-Token: AQoDYXdzEIH//////////wEa0AIXLhngC5zp9CyB1R6abwKrXHVR5efnAVN3XvR7IwqKYalFSn6UyJuEFTft9nObglx4QJ+GXV9cpACkETq=
X-Amz-Date: 20140903T233749Z
X-Amz-Algorithm: AWS4-HMAC-SHA256
X-Amz-Credential: AKIADQKE4SARGYLE/20140903/us-west-2/rds/aws4_request
X-Amz-SignedHeaders: host
X-Amz-Content-SHA256: e3b0c44298fc1c229afbf4c8996fb92427ae41e4649b934de495991b7852b855
X-Amz-Expires: 86400
X-Amz-Signature: 353a4f14b3f250142d9afc34f9f9948154d46ce7d4ec091d0cdabbcf8b40c558
```

Si vous spécifiez une instance de base de données qui n'existe pas, la réponse se compose de l'erreur suivante :
+ `DBInstanceNotFound`—`DBInstanceIdentifier` ne fait pas référence à une instance de base de données existante. (HTTP status code: 404)

# Fichiers journaux de base de données Amazon RDS for Db2
<a name="USER_LogAccess.Concepts.Db2"></a>

Vous pouvez accéder aux journaux de diagnostic de RDS pour DB2 et aux journaux de notifications à l'aide de la console Amazon RDS ou de l'API AWS CLI RDS. Pour plus d’informations sur l’affichage, le téléchargement ou la consultation des journaux de base de données basés sur des fichiers, consultez [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md).

**Topics**
+ [Programme de rétention](#USER_LogAccess.Concepts.Db2.Retention)
+ [Publication de journaux DB2 sur Amazon CloudWatch Logs](#USER_LogAccess.Db2.PublishtoCloudWatchLogs)

## Programme de rétention
<a name="USER_LogAccess.Concepts.Db2.Retention"></a>

Les fichiers journaux font l’objet d’une rotation chaque jour et chaque fois que votre instance de base de données est redémarrée. Voici le programme de rétention des journaux pour RDS for Db2 sur Amazon RDS. 


****  

| Log type (Type de journal) | Programme de rétention | 
| --- | --- | 
|  journaux de diagnostic  |  Db2 supprime les journaux en dehors des paramètres de rétention dans la configuration au niveau de l’instance. Amazon RDS définit le paramètre `diagsize` sur 1000.  | 
|  Journaux de notification  |  Db2 supprime les journaux en dehors des paramètres de rétention dans la configuration au niveau de l’instance. Amazon RDS définit le paramètre `diagsize` sur 1000.  | 

## Publication de journaux DB2 sur Amazon CloudWatch Logs
<a name="USER_LogAccess.Db2.PublishtoCloudWatchLogs"></a>

Avec RDS pour Db2, vous pouvez publier des diagnostics et notifier les événements du journal directement sur Amazon CloudWatch Logs. Analysez les données du journal avec CloudWatch Logs, puis utilisez-les CloudWatch pour créer des alarmes et afficher les métriques.

Avec CloudWatch Logs, vous pouvez effectuer les opérations suivantes :
+ Stocker des journaux dans un espace de stockage hautement durable pour lequel vous définissez la période de rétention.
+ Chercher et filtrer les données de journaux.
+ Partager des données de journaux entre les comptes.
+ Exporter des journaux vers Amazon S3.
+ Diffusez des données vers Amazon OpenSearch Service.
+ Traiter des données de journaux en temps réel avec Amazon Kinesis Data Streams. Pour plus d'informations, consultez le *guide du développeur d'applications Working with Amazon Managed Service for Apache Flink for SQL CloudWatch * [Logs](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/cloudwatch-logs.html).

 Amazon RDS publie chaque journal de base de données RDS for Db2 sous la forme d’un flux de base de données distinct dans le groupe de journaux. Par exemple, si vous publiez les journaux de diagnostic et les journaux de notification, les données de diagnostic sont stockées dans des flux de journaux de diagnostic du groupe de journaux `/aws/rds/instance/my_instance/diagnostic`, et les données des journaux de notification sont stockées dans le groupe de journaux `/aws/rds/instance/my_instance/notify`.

**Note**  
La publication des journaux RDS pour DB2 dans CloudWatch Logs n'est pas activée par défaut. La publication des journaux de statistique du gestionnaire de mémoire à autoréglage (STMM) et de l’optimiseur n’est pas prise en charge. La publication de journaux RDS pour DB2 dans CloudWatch Logs est prise en charge dans toutes les régions, à l'exception de l'Asie-Pacifique (Hong Kong).

### Console
<a name="USER_LogAccess.Db2.PublishtoCloudWatchLogs.console"></a>

**Pour publier les journaux RDS pour DB2 dans Logs à partir CloudWatch du AWS Management Console**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Bases de données**, puis l’instance de base de données que vous souhaitez modifier.

1. Sélectionnez **Modify (Modifier)**.

1. Dans la section **Exportations de journaux**, choisissez les journaux que vous souhaitez commencer à publier dans CloudWatch Logs.

   Vous pouvez choisir **diag.log**, **notify.log** ou les deux.

1. Choisissez **Continuer**, puis **Modifier l’instance de base de données** sur la page récapitulative.

### AWS CLI
<a name="USER_LogAccess.Db2.PublishtoCloudWatchLogs.CLI"></a>

Pour publier les journaux RDS for Db2 vous pouvez utiliser la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) avec les paramètres suivants : 
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`

**Note**  
Une modification apportée à l’option `--cloudwatch-logs-export-configuration` est toujours appliquée immédiatement à l’instance de base de données. Par conséquent, les options `--apply-immediately` et `--no-apply-immediately` sont sans effet.

Vous pouvez également publier des journaux RDS for Db2 en utilisant les commandes suivantes : 
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)

**Example**  
L'exemple suivant crée une instance de base de données RDS pour DB2 avec la publication des CloudWatch journaux activée. La valeur `--enable-cloudwatch-logs-exports` est un tableau de chaînes JSON qui peut inclure `diag.log`, `notify.log` ou les deux.  
Pour Linux, macOS ou Unix :  

```
aws rds create-db-instance \
    --db-instance-identifier mydbinstance \
    --enable-cloudwatch-logs-exports '["diag.log","notify.log"]' \
    --db-instance-class db.m4.large \
    --engine db2-se
```
Pour Windows :  

```
aws rds create-db-instance ^
    --db-instance-identifier mydbinstance ^
    --enable-cloudwatch-logs-exports "[\"diag.log\",\"notify.log\"]" ^
    --db-instance-class db.m4.large ^
    --engine db2-se
```
Lorsque vous utilisez l’invite de commandes Windows, vous devez utiliser des guillemets doubles (") d’échappement dans le code JSON en les préfixant d’une barre oblique inverse (\$1).

**Example**  
L'exemple suivant modifie une instance de base de données RDS pour DB2 existante afin de publier des fichiers journaux dans Logs. CloudWatch La valeur `--cloudwatch-logs-export-configuration` n’est pas un objet JSON. La clé pour cet objet est `EnableLogTypes` et sa valeur est un tableau de chaînes qui peut inclure `diag.log`, `notify.log` ou les deux.  
Pour Linux, macOS ou Unix :  

```
aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --cloudwatch-logs-export-configuration '{"EnableLogTypes":["diag.log","notify.log"]}'
```
Pour Windows :  

```
aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --cloudwatch-logs-export-configuration "{\"EnableLogTypes\":[\"diag.log\",\"notify.log\"]}"
```
Lorsque vous utilisez l’invite de commandes Windows, vous devez utiliser des guillemets doubles (") d’échappement dans le code JSON en les préfixant d’une barre oblique inverse (\$1).

**Example**  
L'exemple suivant modifie une instance de base de données RDS pour DB2 existante afin de désactiver la publication de fichiers journaux de diagnostic dans Logs. CloudWatch La valeur `--cloudwatch-logs-export-configuration` n’est pas un objet JSON. La clé pour cet objet est `DisableLogTypes` et sa valeur est un tableau de chaînes qui peut inclure `diag.log`, `notify.log` ou les deux.  
Pour Linux, macOS ou Unix :  

```
aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --cloudwatch-logs-export-configuration '{"DisableLogTypes":["diag.log"]}'
```
Pour Windows :  

```
aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --cloudwatch-logs-export-configuration "{\"DisableLogTypes\":[\"diag.log\"]}"
```
Lorsque vous utilisez l’invite de commandes Windows, vous devez utiliser des guillemets doubles (") d’échappement dans le code JSON en les préfixant d’une barre oblique inverse (\$1).

# Fichiers journaux de base de données MariaDB
<a name="USER_LogAccess.Concepts.MariaDB"></a>

Vous pouvez surveiller le journal des erreurs, le journal des requêtes lentes, le journal des erreurs d’authentification de base de données IAM et le journal général MariaDB. Le journal des erreurs MySQL est généré par défaut. Vous pouvez générer le journal des requêtes lentes et le journal général en définissant les paramètres nécessaires dans votre groupe de paramètres DB. Amazon RDS assura la rotation de tous les fichiers journaux MariaDB. Les intervalles pour chaque type sont donnés ci-dessous. 

Vous pouvez contrôler les journaux MariaDB directement via la console Amazon RDS, l'API Amazon RDS, la CLI Amazon RDS ou les kits SDK AWS. Vous pouvez également accéder aux journaux MariaDB en dirigeant les journaux vers une table de base de données de la base de données principale et interroger cette table. Vous pouvez utiliser l'utilitaire mysqlbinlog pour télécharger un journal binaire. 

Pour plus d'informations sur l'affichage, le téléchargement ou la consultation des journaux de base de données basés sur des fichiers, consultez [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md).

**Topics**
+ [Accès aux journaux des erreurs MariaDB](USER_LogAccess.MariaDB.Errorlog.md)
+ [Accès au journal des requêtes lentes et au journal général MariaDB](USER_LogAccess.MariaDB.Generallog.md)
+ [Publier des logs MariaDB sur Amazon Logs CloudWatch](USER_LogAccess.MariaDB.PublishtoCloudWatchLogs.md)
+ [Rotation et conservation des journaux pour MariaDB](USER_LogAccess.MariaDB.LogFileSize.md)
+ [Gestion des journaux MariaDB sous forme de table](Appendix.MariaDB.CommonDBATasks.Logs.md)
+ [Configuration de la journalisation binaire MariaDB](USER_LogAccess.MariaDB.BinaryFormat.md)
+ [Accès aux journaux binaires MariaDB](USER_LogAccess.MariaDB.Binarylog.md)
+ [Activation de l’annotation du journal binaire MariaDB](USER_LogAccess.MariaDB.BinarylogAnnotation.md)

# Accès aux journaux des erreurs MariaDB
<a name="USER_LogAccess.MariaDB.Errorlog"></a>

Le journal des erreurs MariaDB est écrit dans le fichier `<host-name>.err`. Vous pouvez afficher ce fichier à l'aide de la console Amazon RDS ou en récupérant le journal à l'aide de l'API Amazon RDS, de la CLI Amazon RDS ou des kits SDK AWS. Le fichier `<host-name>.err` est vidé toutes les 5 minutes, et son contenu est ajouté à `mysql-error-running.log`. Le fichier `mysql-error-running.log` fait ensuite l'objet d'une rotation toutes les heures et les fichiers générés toutes les heures au cours des 24 dernières heures sont conservés. Le nom du fichier journal comporte l'heure à laquelle le fichier a été généré (au format UTC). Les fichiers journaux comportent également un horodatage permettant de déterminer le moment où les entrées du journal ont été écrites.

MariaDB écrit des informations dans le journal des erreurs uniquement au moment du démarrage, de l’arrêt et lorsqu’une erreur survient. Une instance de base de données peut fonctionner pendant des heures ou des jours sans qu'aucune nouvelle entrée soit écrite dans le journal des erreurs. Si aucune entrée récente ne figure, cela signifie que le serveur n'a pas rencontré d'erreur justifiant une entrée de journal.

# Accès au journal des requêtes lentes et au journal général MariaDB
<a name="USER_LogAccess.MariaDB.Generallog"></a>

Le journal des requêtes lentes MariaDB et le journal général peuvent être écrits dans un fichier ou dans une table de base de données en définissant les paramètres nécessaires dans votre groupe de paramètres de base de données. Pour plus d’informations sur la création et la modification d’un groupe de paramètres DB, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md). Vous devez définir ces paramètres avant de pouvoir consulter le journal des requêtes lentes ou le journal général dans la console Amazon RDS ou à l'aide de l'API Amazon RDS, de l'AWS CLI ou des kits SDK AWS.

Vous pouvez contrôler la journalisation MariaDB à l'aide des paramètres de cette liste :
+ `slow_query_log` ou `log_slow_query` : Pour créer le journal des requêtes lentes, définir sur 1. La valeur par défaut est 0.
+ `general_log` : Pour créer le journal général, définir sur 1. La valeur par défaut est 0.
+ `long_query_time` ou `log_slow_query_time` : Pour empêcher l’enregistrement des requêtes rapides dans le journal des requêtes lentes, indiquez la valeur de la durée d’exécution de requête la plus courte devant être enregistrée, en secondes. La valeur par défaut est de 10 secondes et la valeur minimum est 0. Si log\$1output = FILE, vous pouvez indiquer une valeur à virgule flottante avec une résolution en microseconde. Si log\$1output = TABLE, vous devez indiquer un nombre entier avec une résolution en seconde. Seules les requêtes dont la durée d’exécution dépasse la valeur `long_query_time` ou `log_slow_query_time` sont enregistrées. Par exemple, si vous définissez `long_query_time` ou `log_slow_query_time` sur 0,1, les requêtes s’exécutant pendant moins de 100 millisecondes ne sont pas enregistrées.
+ `log_queries_not_using_indexes` : Pour enregistrer toutes les requêtes n'utilisant pas d'index dans le journal des requêtes lentes, définir ce paramètre sur 1. La valeur par défaut est 0. Les requêtes n'utilisant pas d'index sont enregistrées même si la durée de leur exécution est inférieure à la valeur du paramètre `long_query_time`.
+ `log_output option` : Vous pouvez spécifier l'une des options suivantes pour le paramètre `log_output` :
  + **TABLEAU** (par défaut) – Écrit les requêtes générales dans le tableau `mysql.general_log` et les requêtes lentes dans le tableau `mysql.slow_log`. 
  + **FICHIER** – Écrit les fichiers des requêtes générales et lentes dans le fichier système. Les fichiers journaux font l'objet d'une rotation horaire. 
  + **AUCUNE** – Désactive la journalisation.

Lorsque la journalisation est activée, Amazon RDS effectue une rotation des journaux des tables ou supprime les fichiers journaux à intervalles réguliers. Cette précaution permet de limiter la possibilité qu’un fichier journal volumineux ne bloque l’utilisation de la base de données ou n’affecte les performances. Rotation et suppression de l’approche de journalisation `FILE` et `TABLE` comme suit :
+ Lorsque la journalisation `FILE` est activée, les fichiers journaux sont examinés toutes les heures et ceux dont l'ancienneté est supérieure à 24 heures sont supprimés. Dans certains cas, la taille des fichiers journaux combinés restant après la suppression peut dépasser le seuil de 2 % de l'espace alloué à une instance de base de données. Dans ces cas, les fichiers journaux les plus volumineux sont supprimés jusqu'à ce que la taille des fichiers journaux ne soit plus supérieure au seuil. 
+ Lorsque la journalisation de `TABLE` est activée, les tables des journaux font dans certains cas l’objet d’une rotation toutes les 24 heures. Cette rotation se produit si l'espace utilisé par les journaux des tables est supérieur à 20 % de l'espace de stockage alloué. Cela se produit également si la taille de tous les journaux combinés est supérieure à 10 Go. Si l'espace utilisé pour une instance de base de données est supérieur à 90 % de l'espace de stockage alloué à l'instance de base de données, alors les seuils correspondant à la rotation des journaux sont réduits. La rotation des journaux des tables se produit ensuite si l'espace utilisé par les journaux des tables est supérieur à 10 % de l'espace de stockage alloué. Elle se produit également si la taille de tous les journaux combinés est supérieure à 5 Go.

  Lors de la rotation des tables de journaux, la table de journal actuelle est copiée vers une table de journal de sauvegarde et les entrées de la table de journal actuelle sont supprimées. Si la table de journal de sauvegarde existe déjà, elle est supprimée avant que la table de journal actuelle ne soit copiée dans la sauvegarde. Si besoin, vous pouvez interroger la table de journal de sauvegarde. La table de journal de sauvegarde de la table `mysql.general_log` est nommée `mysql.general_log_backup`. La table de journal de sauvegarde de la table `mysql.slow_log` est nommée `mysql.slow_log_backup`.

  Vous pouvez effectuer une rotation de la table `mysql.general_log` en appelant la procédure `mysql.rds_rotate_general_log`. Vous pouvez effectuer une rotation de la table `mysql.slow_log` en appelant la procédure `mysql.rds_rotate_slow_log`.

  La rotation des journaux des tables est effectuée pendant la mise à niveau de la version d'une base de données.

Amazon RDS enregistre la rotation des journaux `TABLE` et `FILE` dans un événement Amazon RDS et vous envoie une notification.

Pour utiliser les journaux depuis la console Amazon RDS, l'API Amazon RDS, la CLI Amazon RDS ou les kits SDK AWS, définissez le paramètre `log_output` sur FILE. A l'instar du journal des erreurs MariaDB, ces fichiers journaux font l'objet d'une rotation horaire. Les fichiers journaux qui ont été générés au cours des dernières 24 heures sont conservés.

Pour plus d'informations sur le journal des requêtes lentes et le journal général, accédez aux rubriques suivantes dans la documentation MariaDB :
+ [Journal des requêtes lentes](http://mariadb.com/kb/en/mariadb/slow-query-log/)
+ [Journal des requêtes générales](http://mariadb.com/kb/en/mariadb/general-query-log/)

# Publier des logs MariaDB sur Amazon Logs CloudWatch
<a name="USER_LogAccess.MariaDB.PublishtoCloudWatchLogs"></a>

Vous pouvez configurer votre instance de base de données MariaDB pour publier les données de journal dans un groupe de journaux dans Amazon Logs. CloudWatch Avec CloudWatch Logs, vous pouvez effectuer une analyse en temps réel des données du journal, puis les utiliser CloudWatch pour créer des alarmes et afficher des métriques. Vous pouvez utiliser CloudWatch les journaux pour stocker vos enregistrements de journal dans un espace de stockage hautement durable. 

Amazon RDS publie chaque journal de base de données MariaDB sous la forme d’un flux de base de données distinct dans le groupe de journaux. Par exemple, supposons que vous configuriez la fonction d’exportation de manière à inclure le journal de requêtes lentes. Les données de requêtes lentes sont ensuite stockées dans un flux de journaux de requêtes lentes dans le groupe de journaux `/aws/rds/instance/my_instance/slowquery`.

Le journal d’erreurs est activé par défaut. Le tableau ci-dessous récapitule les conditions requises pour les autres journaux MariaDB.


| Log | Exigence | 
| --- | --- | 
|  Journal d’audit  |  L’instance de base de données doit disposer d’un groupe d’options personnalisées avec l’option `MARIADB_AUDIT_PLUGIN`.  | 
|  Journal général  |  L’instance de base de données doit disposer d’un groupe de paramètres personnalisés avec le paramètre `general_log = 1` pour autoriser la journalisation générale.  | 
|  Journal des requêtes lentes  |  L’instance de base de données doit disposer d’un groupe de paramètres personnalisés avec le paramètre `slow_query_log = 1` ou `log_slow_query = 1` pour autoriser la journalisation de requête lente.  | 
|  Journal des erreurs d’authentification de base de données IAM  |  Vous devez activer le type de journal `iam-db-auth-error` pour une instance de base de données en créant ou en modifiant une instance de base de données.  | 
|  Sortie de journal  |  L'instance de base de données doit utiliser un groupe de paramètres personnalisé avec le paramètre défini `log_output = FILE` pour écrire des journaux dans le système de fichiers et les publier dans CloudWatch Logs.  | 

## Console
<a name="USER_LogAccess.MariaDB.PublishtoCloudWatchLogs.CON"></a>

**Pour publier les journaux MariaDB dans Logs depuis CloudWatch la console**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Bases de données**, puis l’instance de base de données que vous souhaitez modifier.

1. Sélectionnez **Modify (Modifier)**.

1. Dans la section **Exportations de journaux**, choisissez les journaux que vous souhaitez commencer à publier dans CloudWatch Logs.

1. Choisissez **Continuer**, puis **Modifier l’instance de base de données** sur la page récapitulative.

## AWS CLI
<a name="USER_LogAccess.MariaDB.PublishtoCloudWatchLogs.CLI"></a>

Vous pouvez publier un journal MariaDB avec le. AWS CLI Vous pouvez appeler la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) avec les paramètres suivants : 
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`

**Note**  
Une modification apportée à l’option `--cloudwatch-logs-export-configuration` est toujours appliquée immédiatement à l’instance de base de données. Par conséquent, les options `--apply-immediately` et `--no-apply-immediately` sont sans effet.

Vous pouvez également publier des journaux MariaDB en appelant les commandes suivantes : AWS CLI 
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)

Exécutez l'une de ces AWS CLI commandes avec les options suivantes : 
+ `--db-instance-identifier`
+ `--enable-cloudwatch-logs-exports`
+ `--db-instance-class`
+ `--engine`

D'autres options peuvent être nécessaires en fonction de la AWS CLI commande que vous exécutez.

**Example**  
L'exemple suivant modifie une instance de base de données MariaDB existante pour publier des fichiers journaux dans Logs. CloudWatch La valeur `--cloudwatch-logs-export-configuration` n’est pas un objet JSON. La clé pour cet objet est `EnableLogTypes` et sa valeur est un tableau de chaînes avec une combinaison quelconque de `audit`, `error`, `general` et `slowquery`.  
Pour Linux, macOS ou Unix :  

```
1. aws rds modify-db-instance \
2.     --db-instance-identifier mydbinstance \
3.     --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'
```
Pour Windows :  

```
1. aws rds modify-db-instance ^
2.     --db-instance-identifier mydbinstance ^
3.     --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'
```

**Example**  
La commande suivante crée une instance de base de données MariaDB et publie les fichiers journaux dans Logs. CloudWatch La valeur `--enable-cloudwatch-logs-exports` est un tableau de chaînes JSON. Les chaînes peuvent être une combinaison de `audit`, `error`, `general` et `slowquery`.  
Pour Linux, macOS ou Unix :  

```
1. aws rds create-db-instance \
2.     --db-instance-identifier mydbinstance \
3.     --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]' \
4.     --db-instance-class db.m4.large \
5.     --engine mariadb
```
Pour Windows :  

```
1. aws rds create-db-instance ^
2.     --db-instance-identifier mydbinstance ^
3.     --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]' ^
4.     --db-instance-class db.m4.large ^
5.     --engine mariadb
```

## API RDS
<a name="USER_LogAccess.MariaDB.PublishtoCloudWatchLogs.API"></a>

Vous pouvez publier des journaux MariaDB avec l’API RDS. Vous pouvez appeler l’opération [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) avec les paramètres suivants : 
+ `DBInstanceIdentifier`
+ `CloudwatchLogsExportConfiguration`

**Note**  
Une modification apportée au paramètre `CloudwatchLogsExportConfiguration` est toujours appliquée immédiatement à l’instance de base de données. Par conséquent, le paramètre `ApplyImmediately` est sans effet.

Vous pouvez également publier des journaux MariaDB en appelant les opérations d’API RDS suivantes : 
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html)

Exécutez l’une de ces opérations d’API RDS avec les paramètres suivants : 
+ `DBInstanceIdentifier`
+ `EnableCloudwatchLogsExports`
+ `Engine`
+ `DBInstanceClass`

D'autres paramètres peuvent être nécessaires en fonction de la AWS CLI commande que vous exécutez.

# Rotation et conservation des journaux pour MariaDB
<a name="USER_LogAccess.MariaDB.LogFileSize"></a>

Lorsque la journalisation est activée, Amazon RDS effectue une rotation des journaux des tables ou supprime les fichiers journaux à intervalles réguliers. Cette précaution permet de limiter la possibilité qu'un fichier journal volumineux ne bloque l'utilisation de la base de données ou n'affecte les performances.

Les tailles du journal des requêtes lentes, du journal des erreurs et du journal général MariaDB sont limitées à 2 %maximum de l’espace de stockage alloué à une instance de base de données. Pour respecter ce seuil, les journaux font l'objet d'une rotation automatique toutes les heures et les fichiers dont l'ancienneté est supérieure à 24 heures sont supprimés. Si la taille de l'ensemble des fichiers journaux après la suppression dépasse le seuil, les fichiers journaux les plus volumineux sont supprimés jusqu'à ce que la taille des fichiers journaux ne soit plus supérieure au seuil.

Amazon RDS fait pivoter les fichiers journaux d’erreurs d’authentification de base de données IAM supérieurs à 10 Mo. Amazon RDS supprime les fichiers journaux d’erreurs d’authentification de base de données IAM datant de plus de cinq jours ou de plus de 100 Mo.

# Gestion des journaux MariaDB sous forme de table
<a name="Appendix.MariaDB.CommonDBATasks.Logs"></a>

Vous pouvez diriger les journaux des requêtes générales et lentes vers des tables sur l'instance de base de données. Pour ce faire, créez un groupe de paramètres de base de données et définissez le paramètre de serveur `log_output` sur `TABLE`. Les requêtes générales sont ensuite enregistrées dans la table `mysql.general_log` et les requêtes lentes dans la table `mysql.slow_log`. Vous pouvez interroger les tables pour accéder aux informations des journaux. L’activation de cette journalisation augmente le volume de données écrites dans la base de données, ce qui peut dégrader les performances.

Par défaut, le journal des requêtes générales et le journal des requêtes lentes sont désactivés. Pour activer la journalisation dans les tables, vous devez également définir les paramètres de serveur suivants sur `1` :
+ `general_log`
+ `slow_query_log` ou `log_slow_query`

Les tables de journaux continuent de grossir jusqu’à ce que les activités de journalisation correspondantes soient désactivées en redéfinissant le paramètre approprié sur `0`. Avec le temps, une grande quantité de données s’accumule et risque d’utiliser une part considérable de l’espace de stockage alloué. Amazon RDS ne vous permet pas de tronquer les tables de journaux, mais vous pouvez déplacer leur contenu. Lorsque vous procédez à la rotation d’une table, son contenu est enregistré dans une table de sauvegarde et une nouvelle table de journal vide est créée. Vous pouvez effectuer une rotation manuelle des tables de journaux avec les procédures de ligne de commande suivantes, dans lesquelles l’invite de commande est indiquée par `PROMPT>` : 

```
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
```

 Pour supprimer totalement les anciennes données et récupérer l’espace de disque, appelez deux fois à la suite la procédure appropriée. 

# Configuration de la journalisation binaire MariaDB
<a name="USER_LogAccess.MariaDB.BinaryFormat"></a>

Le *journal binaire* est un jeu de fichiers journaux contenant des informations sur les modifications de données apportées à une instance de serveur MariaDB. Le journal binaire contient des informations telles que les suivantes :
+ Événements décrivant les modifications apportées à la base de données telles que la création de tables ou les modifications de lignes
+ Informations sur la durée de chaque instruction qui a mis à jour les données
+ Événements pour des instructions pouvant mettre à jour des données mais ne l’ayant pas fait

Le journal binaire enregistre les instructions envoyées pendant la réplication. Il est également requis pour certaines opérations de récupération. Pour plus d’informations, consultez [Journal binaire](https://mariadb.com/kb/en/binary-log/) dans la documentation MariaDB.

La fonction de sauvegarde automatisée détermine si la journalisation binaire est activée ou désactivée pour MariaDB. Vous avez les options suivantes :

Activer la journalisation binaire  
Définissez la période de rétention des sauvegardes sur une valeur positive différente de zéro.

Désactiver la journalisation binaire  
Définissez la période de rétention des sauvegardes sur zéro.

Pour plus d’informations, consultez [Activation des sauvegardes automatiques](USER_WorkingWithAutomatedBackups.Enabling.md).

MariaDB sur Amazon RDS prend en charge les formats de journalisation binaire *basés sur les lignes*, *basés sur les instructions* et *mixtes*. Le format de journalisation binaire par défaut est *mixte*. Pour plus de détails sur les différents formats de journalisation binaire MariaDB, consultez [Formats de journalisation binaire](http://mariadb.com/kb/en/mariadb/binary-log-formats/) dans la documentation MariaDB.

Si vous envisagez d’utiliser la réplication, le format de journalisation binaire est important. Il détermine le dossier de modifications de données qui est enregistré dans la source et envoyés aux cibles de réplication. Pour plus d’informations sur les avantages et les désavantages des différents formats de journalisation binaire pour la réplication, consultez [Advantages and Disadvantages of Statement-Based and Row-Based Replication](https://dev.mysql.com/doc/refman/5.7/en/replication-sbr-rbr.html) dans la documentation MySQL.

**Important**  
Lorsque vous définissez le format de journalisation binaire sur « basé sur les lignes », vous risquez de générer des fichiers journaux binaires très volumineux. Les fichiers de journaux binaires importants réduisent le stockage disponible pour une instance de base de données. Ils peuvent également augmenter le temps nécessaire pour effectuer une opération de restauration d’une instance de base de données.  
La réplication basée sur les instructions peut provoquer des incohérences entre l’instance de base de données source et un réplica en lecture. Pour plus d’informations, consultez [Unsafe Statements for Statement-based Replication](https://mariadb.com/kb/en/library/unsafe-statements-for-statement-based-replication/) dans la documentation MariaDB.  
L'activation de la journalisation binaire augmente le nombre d' I/O opérations d'écriture sur le disque sur l'instance de base de données. Vous pouvez surveiller l'utilisation des IOPS à l'aide de cette `WriteIOPS` CloudWatch métrique.

**Pour définir le format de journalisation binaire MariaDB :**

1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.

1. Dans le panneau de navigation, choisissez **Groupes de paramètres**.

1. Choisissez le groupe de paramètres utilisé par l’instance de base de données que vous souhaitez modifier.

   Vous ne pouvez pas modifier un groupe de paramètres par défaut. Si l’instance de base de données utilise un groupe de paramètres par défaut, créez un nouveau groupe et associez-le à l’instance.

   Pour plus d’informations sur les groupes de paramètres de base de données, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).

1. Sous **Parameter group actions** (Actions de groupe de paramètres), choisissez **Edit** (Modifier).

1. Définissez le paramètre `binlog_format` au format de journalisation binaire de votre choix (**ROW**, **STATEMENT** ou **MIXED**).

   Vous pouvez désactiver la journalisation binaire en définissant la période de conservation des sauvegardes d’une instance de base de données sur zéro, mais cela désactive les sauvegardes automatiques quotidiennes. La désactivation des sauvegardes automatiques désactive ou désactive la variable de session `log_bin`. Cela désactive la journalisation binaire sur l’instance de base de données RDS for MariaDB, qui à son tour réinitialise la variable de session `binlog_format` à la valeur par défaut de `ROW` dans la base de données. Nous vous recommandons de ne pas désactiver les sauvegardes. Pour plus d’informations sur le paramètre **Période de rétention des sauvegardes**, consultez [Paramètres des instances de base de données](USER_ModifyInstance.Settings.md).

1. Choisissez **Enregistrer les modifications** pour enregistrer les mises à jour apportées au groupe de paramètres de base de données.

Le paramètre `binlog_format` étant dynamique dans RDS for MariaDB, vous n’avez pas besoin de redémarrer l’instance de base de données pour que les modifications s’appliquent. 

**Important**  
La modification d’un groupe de paramètres de base de données affecte toutes les instances de base de données qui utilisent ce dernier. Si vous souhaitez spécifier différents formats de journalisation binaire pour différentes instances de base de données MariaDB dans AWS une région, les instances de base de données doivent utiliser différents groupes de paramètres de base de données. Ces groupes de paramètres identifient différents formats de journalisation. Affectez le groupe de paramètres de base de données approprié à chaque instance de base de données.

# Accès aux journaux binaires MariaDB
<a name="USER_LogAccess.MariaDB.Binarylog"></a>

Vous pouvez utiliser l'utilitaire mysqlbinlog pour télécharger les journaux binaires au format texte à partir d'instances de base de données MariaDB. Le journal binaire est téléchargé dans votre ordinateur local. Pour plus d'informations sur l'utilisation de l'utilitaire mysqlbinlog, accédez à [Utilisation de mysqlbinlog](http://mariadb.com/kb/en/mariadb/using-mysqlbinlog/) dans la documentation MariaDB.

 Pour exécuter à nouveau l'utilitaire mysqlbinlog sur une instance Amazon RDS, utilisez les options suivantes : 
+  Spécifiez l'option `--read-from-remote-server`. 
+  `--host` : Spécifiez le nom DNS du point de terminaison de l'instance. 
+  `--port` : Spécifiez le port utilisé par l'instance. 
+  `--user` : Spécifiez un utilisateur MariaDB ayant l'autorisation de réplication esclave. 
+  `--password` : Spécifiez le mot de passe de l'utilisateur ou omettez la valeur de mot de passe pour que l'utilitaire vous invite à saisir un mot de passe. 
+  `--result-file` : Spécifiez le fichier local qui recevra la sortie. 
+ Spécifiez les noms pour un ou plusieurs fichiers journaux binaires. Pour obtenir la liste des journaux disponibles, utilisez la commande SQL SHOW BINARY LOGS. 

Pour plus d'informations sur les options mysqlbinlog, accédez aux [Options mysqlbinlog](http://mariadb.com/kb/en/mariadb/mysqlbinlog-options/) dans la documentation MariaDB. 

 Voici un exemple : 

Pour Linux, macOS ou Unix :

```
mysqlbinlog \
    --read-from-remote-server \
    --host=mariadbinstance1.1234abcd.region.rds.amazonaws.com \
    --port=3306  \
    --user ReplUser \
    --password <password> \
    --result-file=/tmp/binlog.txt
```

Pour Windows :

```
mysqlbinlog ^
    --read-from-remote-server ^
    --host=mariadbinstance1.1234abcd.region.rds.amazonaws.com ^
    --port=3306  ^
    --user ReplUser ^
    --password <password> ^
    --result-file=/tmp/binlog.txt
```

Amazon RDS purge normalement un journal binaire dès que possible. Toutefois, le journal binaire doit toujours être disponible sur l'instance afin que mysqlbinlog puisse y accéder. Pour spécifier le nombre d'heures pendant lequel RDS conserve les journaux binaires, utilisez la procédure stockée `mysql.rds_set_configuration`. Spécifiez une période suffisamment longue pour télécharger les journaux. Après avoir défini la période de rétention, surveillez l'utilisation du stockage de l'instance de base de données afin de garantir que les journaux binaires conservés n'utilisent pas un espace de stockage trop grand.

L'exemple suivant définit la période de conservation sur 1 jour.

```
call mysql.rds_set_configuration('binlog retention hours', 24); 
```

Pour afficher les paramètres actuels, utilisez la procédure stockée `mysql.rds_show_configuration`.

```
call mysql.rds_show_configuration; 
```

# Activation de l’annotation du journal binaire MariaDB
<a name="USER_LogAccess.MariaDB.BinarylogAnnotation"></a>

Dans une instance de base de données MariaDB, vous pouvez utiliser l'événement `Annotate_rows` pour annoter un événement de ligne avec une copie de la requête SQL ayant provoqué cet événement. Cette approche offre une fonctionnalité similaire à l'activation du paramètre `binlog_rows_query_log_events` sur une instance de base de données RDS for MySQL.

Vous pouvez activer globalement les annotations des journaux binaires en créant un groupe de paramètres personnalisé et en définissant le paramètre `binlog_annotate_row_events` sur **1**. Vous pouvez également activer les annotations au niveau de la session, en appelant `SET SESSION binlog_annotate_row_events = 1`. Utilisez `replicate_annotate_row_events` pour répliquer les annotations des journaux binaires dans l'instance de réplica si la journalisation binaire est activée pour cette instance. Aucun privilège spécial n'est nécessaire pour utiliser ces paramètres.

L'exemple suivant illustre une transaction basée sur les lignes dans MariaDB. L'utilisation de la journalisation basée sur les lignes est déclenchée en définissant le niveau d'isolement des transactions sur read-committed.

```
CREATE DATABASE IF NOT EXISTS test;
USE test;
CREATE TABLE square(x INT PRIMARY KEY, y INT NOT NULL) ENGINE = InnoDB;
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN
INSERT INTO square(x, y) VALUES(5, 5 * 5);
COMMIT;
```

Sans les annotations, les entrées du journal binaire pour la transaction ressemblent à :

```
BEGIN
/*!*/;
# at 1163
# at 1209
#150922  7:55:57 server id 1855786460  end_log_pos 1209         Table_map: `test`.`square` mapped to number 76
#150922  7:55:57 server id 1855786460  end_log_pos 1247         Write_rows: table id 76 flags: STMT_END_F
### INSERT INTO `test`.`square`
### SET
###   @1=5
###   @2=25
# at 1247
#150922  7:56:01 server id 1855786460  end_log_pos 1274         Xid = 62
COMMIT/*!*/;
```

L'instruction suivante active les annotations au niveau de la session pour cette même transaction, et les désactive après validation de la transaction :

```
CREATE DATABASE IF NOT EXISTS test;
USE test;
CREATE TABLE square(x INT PRIMARY KEY, y INT NOT NULL) ENGINE = InnoDB;
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET SESSION binlog_annotate_row_events = 1;
BEGIN;
INSERT INTO square(x, y) VALUES(5, 5 * 5);
COMMIT;
SET SESSION binlog_annotate_row_events = 0;
```

Avec les annotations, les entrées du journal binaire pour la transaction ressemblent à :

```
BEGIN
/*!*/;
# at 423
# at 483
# at 529
#150922  8:04:24 server id 1855786460  end_log_pos 483  Annotate_rows:
#Q> INSERT INTO square(x, y) VALUES(5, 5 * 5)
#150922  8:04:24 server id 1855786460  end_log_pos 529  Table_map: `test`.`square` mapped to number 76
#150922  8:04:24 server id 1855786460  end_log_pos 567  Write_rows: table id 76 flags: STMT_END_F
### INSERT INTO `test`.`square`
### SET
###   @1=5
###   @2=25
# at 567
#150922  8:04:26 server id 1855786460  end_log_pos 594  Xid = 88
COMMIT/*!*/;
```

# Fichiers journaux de base de données Amazon RDS for Microsoft SQL Server
<a name="USER_LogAccess.Concepts.SQLServer"></a>

Vous pouvez accéder aux journaux des erreurs Microsoft SQL Server, aux journaux de l’agent, aux fichiers de trace et aux fichiers de vidage à l’aide de la console Amazon RDS, de l’ AWS CLI ou de l’API RDS. Pour plus d’informations sur l’affichage, le téléchargement ou la consultation des journaux de base de données basés sur des fichiers, consultez [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md).

## Programme de rétention
<a name="USER_LogAccess.Concepts.SQLServer.Retention"></a>

Les fichiers journaux font l’objet d’une rotation chaque jour et chaque fois que votre instance de base de données est redémarrée. Voici le programme de rétention des journaux Microsoft SQL Server sur Amazon RDS. 


****  

| Log type (Type de journal) | Programme de rétention | 
| --- | --- | 
|  Journaux des erreurs  |  Au maximum, 30 journaux d’erreurs sont conservés. Amazon RDS forrait supprimer les journaux d’erreurs datant de plus de 7 jours.   | 
|  Journaux de l’agent  |  Au maximum, 10 journaux de l’agent sont conservés. Amazon RDS forrait supprimer les journaux de l’agent datant de plus de 7 jours.   | 
|  Fichiers de trace  |  Les fichiers de trace sont conservés selon la période de rétention des fichiers de trace de votre instance de base de données. La période de rétention par défaut des fichiers de trace est de 7 jours. Pour modifier la période de rétention des fichiers de trace pour votre instance de base de données, consultez [Configuration de la période de rétention pour les fichiers de trace et de vidage](Appendix.SQLServer.CommonDBATasks.TraceFiles.md#Appendix.SQLServer.CommonDBATasks.TraceFiles.PurgeTraceFiles).   | 
|  Fichiers de vidage  |  Les fichiers de vidage sont conservés selon la période de rétention des fichiers de vidage de votre instance de base de données. La période de rétention par défaut des fichiers de vidage est de 7 jours. Pour modifier la période de rétention des fichiers de vidage pour votre instance de base de données, consultez [Configuration de la période de rétention pour les fichiers de trace et de vidage](Appendix.SQLServer.CommonDBATasks.TraceFiles.md#Appendix.SQLServer.CommonDBATasks.TraceFiles.PurgeTraceFiles).   | 

## Affichage du journal des erreurs SQL Server à l’aide de la procédure rds\$1read\$1error\$1log
<a name="USER_LogAccess.Concepts.SQLServer.Proc"></a>

Vous pouvez utiliser la procédure stockée Amazon RDS `rds_read_error_log` pour afficher les journaux des erreurs et les journaux de l’agent. Pour de plus amples informations, veuillez consulter [Affichage des journaux des erreurs et des agents](Appendix.SQLServer.CommonDBATasks.Logs.md#Appendix.SQLServer.CommonDBATasks.Logs.SP). 

## Publication des journaux SQL Server sur Amazon CloudWatch Logs
<a name="USER_LogAccess.SQLServer.PublishtoCloudWatchLogs"></a>

Avec Amazon RDS for SQL Server, vous pouvez publier les erreurs et les événements du journal de l'agent directement sur CloudWatch Amazon Logs. Analysez les données du journal avec CloudWatch Logs, puis utilisez-les CloudWatch pour créer des alarmes et afficher les métriques.

Avec CloudWatch Logs, vous pouvez effectuer les opérations suivantes :
+ Stocker des journaux dans un espace de stockage hautement durable pour lequel vous définissez la période de rétention.
+ Chercher et filtrer les données de journaux.
+ Partager des données de journaux entre les comptes.
+ Exporter des journaux vers Amazon S3.
+ Diffusez des données vers Amazon OpenSearch Service.
+ Traiter des données de journaux en temps réel avec Amazon Kinesis Data Streams. Pour plus d'informations, consultez le *guide du développeur d'applications Working with Amazon Managed Service for Apache Flink for SQL CloudWatch * [Logs](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/cloudwatch-logs.html).

 Amazon RDS publie chaque journal de base de données SQL Server sous la forme d’un flux de base de données distinct dans le groupe de journaux. Par exemple, si vous publiez les journaux des agents et les journaux des erreurs, les données d’erreurs sont stockées dans un flux de journal des erreurs dans le groupe de journaux `/aws/rds/instance/my_instance.node1/error`, et les données de journaux des agents sont stockées dans le groupe de journaux `/aws/rds/instance/my_instance.node1/agent`.

Pour les instances de base de données multi-AZ, Amazon RDS publie le journal de base de données sous la forme de deux flux distincts dans le groupe de journaux. Par exemple, si vous publiez les journaux d’erreurs, les données d’erreurs sont stockées dans les flux de journaux d’erreurs `/aws/rds/instance/my_instance.node1/error` et `/aws/rds/instance/my_instance.node2/error` respectivement. Les flux de journaux ne changent pas lors d’un basculement et le flux de journaux d’erreurs de chaque nœud peut contenir les journaux d’erreurs issus de l’instance principale ou secondaire. Avec Multi-AZ, un flux de journaux est automatiquement créé pour que `/aws/rds/instance/my_instance/rds-events` stocke les données d’événements telles que les basculements d’instances de base de données.

**Note**  
La publication des journaux SQL Server dans CloudWatch Logs n'est pas activée par défaut. La publication de fichiers de trace et de vidage n’est pas prise en charge. La publication des journaux SQL Server dans CloudWatch Logs est prise en charge dans toutes les régions.

### Console
<a name="USER_LogAccess.SQLServer.PublishtoCloudWatchLogs.console"></a>

**Pour publier les journaux de base de données SQL Server dans CloudWatch des journaux à partir du AWS Management Console**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Bases de données**, puis l’instance de base de données que vous souhaitez modifier.

1. Sélectionnez **Modify (Modifier)**.

1. Dans la section **Exportations de journaux**, choisissez les journaux que vous souhaitez commencer à publier dans CloudWatch Logs.

   Vous pouvez choisir **Journal de l’agent**, **Journal des erreurs**ou les deux.

1. Choisissez **Continuer**, puis **Modifier l’instance de base de données** sur la page récapitulative.

### AWS CLI
<a name="USER_LogAccess.SQLServer.PublishtoCloudWatchLogs.CLI"></a>

Pour publier des journaux SQL Server, vous pouvez utiliser la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) avec les paramètres suivants : 
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`

**Note**  
Une modification apportée à l’option `--cloudwatch-logs-export-configuration` est toujours appliquée immédiatement à l’instance de base de données. Par conséquent, les options `--apply-immediately` et `--no-apply-immediately` sont sans effet.

Vous pouvez également publier des journaux SQL Server en utilisant les commandes suivantes : 
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)

**Example**  
L'exemple suivant crée une instance de base de données SQL Server avec la publication CloudWatch des journaux activée. La valeur `--enable-cloudwatch-logs-exports` est un tableau de chaînes JSON qui peut inclure `error`, `agent` ou les deux.  
Pour Linux, macOS ou Unix :  

```
aws rds create-db-instance \
    --db-instance-identifier mydbinstance \
    --enable-cloudwatch-logs-exports '["error","agent"]' \
    --db-instance-class db.m4.large \
    --engine sqlserver-se
```
Pour Windows :  

```
aws rds create-db-instance ^
    --db-instance-identifier mydbinstance ^
    --enable-cloudwatch-logs-exports "[\"error\",\"agent\"]" ^
    --db-instance-class db.m4.large ^
    --engine sqlserver-se
```
Lorsque vous utilisez l’invite de commandes Windows, vous devez utiliser des guillemets doubles (") d’échappement dans le code JSON en les préfixant d’une barre oblique inverse (\$1).

**Example**  
L'exemple suivant modifie une instance de base de données SQL Server existante pour publier des fichiers CloudWatch journaux dans Logs. La valeur `--cloudwatch-logs-export-configuration` n’est pas un objet JSON. La clé pour cet objet est `EnableLogTypes` et sa valeur est un tableau de chaînes qui peut inclure `error`, `agent` ou les deux.  
Pour Linux, macOS ou Unix :  

```
aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --cloudwatch-logs-export-configuration '{"EnableLogTypes":["error","agent"]}'
```
Pour Windows :  

```
aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --cloudwatch-logs-export-configuration "{\"EnableLogTypes\":[\"error\",\"agent\"]}"
```
Lorsque vous utilisez l’invite de commandes Windows, vous devez utiliser des guillemets doubles (") d’échappement dans le code JSON en les préfixant d’une barre oblique inverse (\$1).

**Example**  
L'exemple suivant modifie une instance de base de données SQL Server existante pour désactiver la publication des fichiers journaux de l'agent dans CloudWatch Logs. La valeur `--cloudwatch-logs-export-configuration` n’est pas un objet JSON. La clé pour cet objet est `DisableLogTypes` et sa valeur est un tableau de chaînes qui peut inclure `error`, `agent` ou les deux.  
Pour Linux, macOS ou Unix :  

```
aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --cloudwatch-logs-export-configuration '{"DisableLogTypes":["agent"]}'
```
Pour Windows :  

```
aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --cloudwatch-logs-export-configuration "{\"DisableLogTypes\":[\"agent\"]}"
```
Lorsque vous utilisez l’invite de commandes Windows, vous devez utiliser des guillemets doubles (") d’échappement dans le code JSON en les préfixant d’une barre oblique inverse (\$1).

# Fichiers journaux de base de données MySQL
<a name="USER_LogAccess.Concepts.MySQL"></a>

Vous pouvez surveiller les journaux MySQL directement via la console Amazon RDS, l'API Amazon RDS ou AWS CLI. AWS SDKs Vous pouvez également accéder aux journaux MySQL en dirigeant les journaux vers une table de base de données de la base de données principale et interroger cette table. Vous pouvez utiliser l'utilitaire mysqlbinlog pour télécharger un journal binaire. 

Pour plus d’informations sur l’affichage, le téléchargement ou la consultation des journaux de base de données basés sur des fichiers, consultez [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md).

**Topics**
+ [Présentation des journaux de base de données RDS for MySQL](USER_LogAccess.MySQL.LogFileSize.md)
+ [Publication des journaux MySQL dans Amazon CloudWatch Logs](USER_LogAccess.MySQLDB.PublishtoCloudWatchLogs.md)
+ [Envoi de la sortie du journal MySQL à des tables](Appendix.MySQL.CommonDBATasks.Logs.md)
+ [Configuration d' RDS pour la journalisation binaire MySQL pour les bases de données mono-AZ](USER_LogAccess.MySQL.BinaryFormat.md)
+ [Configuration de la journalisation binaire MySQL pour les clusters de bases de données multi-AZ](USER_Binlog.MultiAZ.md)
+ [Accès aux journaux binaires MySQL](USER_LogAccess.MySQL.Binarylog.md)

# Présentation des journaux de base de données RDS for MySQL
<a name="USER_LogAccess.MySQL.LogFileSize"></a>

Vous pouvez surveiller les types de fichiers journaux RDS for MySQL suivants :
+ Journal des erreurs
+ Journal des requêtes lentes
+ Journal général
+ Journal d’audit
+ Journal d’instance
+ Journal des erreurs d’authentification de base de données IAM

Le journal des erreurs RDS for MySQL est généré par défaut. Vous pouvez générer le journal des requêtes lentes et le journal général en définissant les paramètres nécessaires dans votre groupe de paramètres de base de données.

**Topics**
+ [Journaux des erreurs RDS for MySQL](#USER_LogAccess.MySQL.Errorlog)
+ [Journal des requêtes lentes et journal général RDS for MySQL](#USER_LogAccess.MySQL.Generallog)
+ [Journal d’audit MySQL](#USER_LogAccess.MySQL.Auditlog)
+ [Renouvellement et rétention des journaux pour RDS for MySQL](#USER_LogAccess.MySQL.LogFileSize.retention)
+ [Limites de taille des journaux de reprise](#USER_LogAccess.MySQL.LogFileSize.RedoLogs)

## Journaux des erreurs RDS for MySQL
<a name="USER_LogAccess.MySQL.Errorlog"></a>

RDS for MySQL écrit les erreurs dans le fichier `mysql-error.log`. Le nom du fichier journal comporte l’heure à laquelle le fichier a été généré (au format UTC). Les fichiers journaux comportent également un horodatage permettant de déterminer le moment où les entrées du journal ont été écrites.

RDS for MySQL écrit dans le journal des erreurs uniquement au moment du démarrage, de l’arrêt et lorsqu’une erreur survient. Une instance de base de données peut fonctionner pendant des heures ou des jours sans qu’aucune nouvelle entrée soit écrite dans le journal des erreurs. Si aucune entrée récente ne figure, cela signifie que le serveur n’a pas rencontré d’erreur justifiant une entrée de journal.

Par défaut, les journaux des erreurs sont filtrés de sorte que seuls les événements inattendus tels que les erreurs soient affichés. Toutefois, les journaux des erreurs contiennent également des informations supplémentaires sur la base de données, comme la progression des requêtes, qui ne sont pas affichées. Par conséquent, même en l’absence d’erreurs réelles, la taille des journaux des erreurs peut augmenter en raison des activités en cours sur la base de données. Et même si vous pouvez voir une certaine taille en octets ou en kilo-octets pour les journaux d'erreurs dans le AWS Management Console, ils peuvent contenir 0 octet lorsque vous les téléchargez.

RDS for MySQL écrit `mysql-error.log` sur le disque toutes les 5 minutes. Il ajoute le contenu du journal à `mysql-error-running.log`.

RDS for MySQL assure la rotation du fichier `mysql-error-running.log` toutes les heures. Les journaux générés au cours des deux dernières semaines sont conservés.

**Note**  
La période de conservation des journaux est différente pour Amazon RDS et Aurora.

## Journal des requêtes lentes et journal général RDS for MySQL
<a name="USER_LogAccess.MySQL.Generallog"></a>

Vous pouvez écrire le journal des requêtes lentes et le journal général RDS for MySQL dans un fichier ou dans une table de base de données. Pour ce faire, définissez les paramètres de votre groupe de paramètres de base de données. Pour plus d’informations sur la création et la modification d’un groupe de paramètres DB, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md). Vous devez définir ces paramètres avant de pouvoir consulter le journal des requêtes lentes ou le journal général dans la console Amazon RDS ou à l'aide de l'API Amazon RDS, de la CLI Amazon RDS ou. AWS SDKs

Vous pouvez contrôler la journalisation RDS for MySQL à l’aide des paramètres de cette liste :
+ `slow_query_log` : Pour créer le journal des requêtes lentes, définir sur 1. La valeur par défaut est 0.
+ `general_log` : Pour créer le journal général, définir sur 1. La valeur par défaut est 0.
+ `long_query_time` : Pour empêcher l’enregistrement des requêtes rapides dans le journal des requêtes lentes, indiquez la valeur de la durée d’exécution de requête la plus courte devant être journalisée, en secondes. La valeur par défaut est de 10 secondes et la valeur minimum est 0. Si log\$1output = FILE, vous pouvez indiquer une valeur à virgule flottante avec une résolution en microseconde. Si log\$1output = TABLE, vous devez indiquer un nombre entier avec une résolution en seconde. Seules les requêtes dont la durée d’exécution dépasse la valeur `long_query_time` sont journalisées. Par exemple, si vous définissez `long_query_time` sur 0,1, les requêtes s’exécutant pendant moins de 100 millisecondes ne sont pas enregistrées.
+ `log_queries_not_using_indexes` : Pour enregistrer toutes les requêtes n’utilisant pas d’index dans le journal des requêtes lentes, définir sur 1. Les requêtes n’utilisant pas d’index sont journalisées même si la durée de leur exécution est inférieure à la valeur du paramètre `long_query_time`. La valeur par défaut est 0.
+ `log_output option` : Vous pouvez spécifier l’une des options suivantes pour le paramètre `log_output`. 
  + **TABLEAU** (par défaut) – Écrit les requêtes générales dans le tableau `mysql.general_log` et les requêtes lentes dans le tableau `mysql.slow_log`.
  + **FICHIER** – Écrit les fichiers des requêtes générales et lentes dans le fichier système.
  + **AUCUNE**– Désactive la journalisation.

Pour que les données de requête lentes apparaissent dans Amazon CloudWatch Logs, les conditions suivantes doivent être remplies :
+ CloudWatch Les journaux doivent être configurés pour inclure les journaux des requêtes lentes.
+ `slow_query_log` doit être activé.
+ `log_output` doit être défini sur `FILE`.
+ La durée de la requête doit être plus longue que celle configurée pour `long_query_time`.

Pour plus d’informations sur le journal des requêtes lentes et le journal général, accédez aux rubriques suivantes dans la documentation MySQL :
+ [Journal des requêtes lentes](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html)
+ [Journal des requêtes générales](https://dev.mysql.com/doc/refman/8.0/en/query-log.html)

## Journal d’audit MySQL
<a name="USER_LogAccess.MySQL.Auditlog"></a>

Pour accéder au journal d’audit, l’instance de base de données doit utiliser un groupe d’options personnalisé avec l’option `MARIADB_AUDIT_PLUGIN`. Pour plus d’informations, consultez [Prise en charge du plugin d'audit MariaDB pour MySQL](Appendix.MySQL.Options.AuditPlugin.md).

## Renouvellement et rétention des journaux pour RDS for MySQL
<a name="USER_LogAccess.MySQL.LogFileSize.retention"></a>

Lorsque la journalisation est activée, Amazon RDS effectue une rotation des journaux des tables ou supprime les fichiers journaux à intervalles réguliers. Cette précaution permet de limiter la possibilité qu’un fichier journal volumineux ne bloque l’utilisation de la base de données ou n’affecte les performances. RDS for MySQL gère la rotation et la suppression des journaux comme suit :
+ Les tailles du journal des requêtes lentes, du journal des erreurs et du journal général MySQL sont limitées à 2 %maximum de l’espace de stockage alloué à une instance de base de données. Pour maintenir ce seuil, les journaux sont automatiquement renouvelés toutes les heures. MySQL supprime les fichiers journaux datant de plus de deux semaines. Si la taille de l’ensemble des fichiers journaux après la suppression dépasse le seuil, les fichiers journaux les plus anciens sont supprimés jusqu’à ce que la taille des fichiers journaux ne soit plus supérieure au seuil.
+ Lorsque la journalisation `FILE` est activée, les fichiers journaux sont examinés toutes les heures et ceux datant de plus de deux semaines sont supprimés. Dans certains cas, la taille des fichiers journaux combinés restant après la suppression peut dépasser le seuil de 2 % de l’espace alloué à une instance de base de données. Le cas échéant, les fichiers journaux les plus anciens sont supprimés jusqu’à ce que la taille des fichiers journaux ne soit plus supérieure au seuil.
+ Lorsque la journalisation de `TABLE` est activée, les tables des journaux font dans certains cas l’objet d’une rotation toutes les 24 heures. Cette rotation se produit si l’espace utilisé par les journaux des tables est supérieur à 20 % de l’espace de stockage alloué. Cela se produit également si la taille de tous les journaux combinés est supérieure à 10 Go. Si l’espace utilisé pour une instance de base de données est supérieur à 90 % de l’espace de stockage alloué à l’instance de base de données, alors les seuils correspondant à la rotation des journaux est réduite. La rotation des journaux des tables se produit ensuite si l’espace utilisé par les journaux des tables est supérieur à 10 % de l’espace de stockage alloué. Elle se produit également si la taille de tous les journaux combinés est supérieure à 5 Go. Vous pouvez vous abonner à la catégorie d’événement `low storage` pour être informé lorsque les tables de journal font l’objet d’une rotation pour libérer de l’espace. Pour plus d’informations, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md).

  Lors de la rotation des tables de journaux, la table de journal actuelle est d’abord copiée vers une table de journal de sauvegarde. Les entrées de la table de journal actuelle sont ensuite supprimées. Si la table de journal de sauvegarde existe déjà, elle est supprimée avant que la table de journal actuelle ne soit copiée dans la sauvegarde. Si besoin, vous pouvez interroger la table de journal de sauvegarde. La table de journal de sauvegarde de la table `mysql.general_log` est nommée `mysql.general_log_backup`. La table de journal de sauvegarde de la table `mysql.slow_log` est nommée `mysql.slow_log_backup`.

  Vous pouvez effectuer une rotation de la table `mysql.general_log` en appelant la procédure `mysql.rds_rotate_general_log`. Vous pouvez effectuer une rotation de la table `mysql.slow_log` en appelant la procédure `mysql.rds_rotate_slow_log`.

  La rotation des journaux des tables est effectuée pendant la mise à niveau de la version d’une base de données.

Pour utiliser les journaux de la console Amazon RDS, de l'API Amazon RDS, de l'interface de ligne de commande Amazon RDS, AWS SDKs ou définissez `log_output` le paramètre sur FILE. A l’instar du journal des erreurs MySQL, ces fichiers journaux font l’objet d’une rotation horaire. Les fichiers journaux qui ont été générés au cours des deux dernières semaines sont conservés. Veuillez noter que la période de rétention est différente pour Amazon RDS et pour Aurora.

## Limites de taille des journaux de reprise
<a name="USER_LogAccess.MySQL.LogFileSize.RedoLogs"></a>

Pour RDS for MySQL versions 8.0.32 et antérieures, la valeur par défaut de ce paramètre est de 256 Mo. Ce montant est obtenu en multipliant la valeur par défaut du paramètre `innodb_log_file_size` (128 Mo) par la valeur par défaut du paramètre `innodb_log_files_in_group` (2). Pour plus d’informations, consultez [Best practices for configuring parameters for Amazon RDS for MySQL, part 1: Parameters related to performance](https://aws.amazon.com/blogs/database/best-practices-for-configuring-parameters-for-amazon-rds-for-mysql-part-1-parameters-related-to-performance/). 

Pour RDS for MySQL version 8.0.33 et versions mineures ultérieures, Amazon RDS utilise le paramètre `innodb_redo_log_capacity` au lieu du paramètre `innodb_log_file_size`. La valeur par défaut Amazon RDS du paramètre `innodb_redo_log_capacity` est 2 Go. Pour plus d’informations, consultez [Changements dans MySQL 8.0.30](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-30.html) dans la documentation MySQL.

À partir de MySQL 8.4, Amazon RDS active le paramètre `innodb_dedicated_server` par défaut. Avec le paramètre `innodb_dedicated_server`, le moteur de base de données calcule les paramètres `innodb_buffer_pool_size` et `innodb_redo_log_capacity`. Pour de plus amples informations, veuillez consulter [Configuration de la taille du groupe de mémoires tampons et de la capacité du journal de reprise dans MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md).

# Publication des journaux MySQL dans Amazon CloudWatch Logs
<a name="USER_LogAccess.MySQLDB.PublishtoCloudWatchLogs"></a>

Vous pouvez configurer votre instance de base de données MySQL de sorte à publier des données de journaux dans un groupe de journaux dans Amazon CloudWatch Logs. CloudWatch Logs vous permet d'effectuer une analyse en temps réel des données de journaux et d'utiliser CloudWatch pour créer des alarmes et afficher des métriques. CloudWatch Logs permet de conserver les enregistrements des journaux dans une solution de stockage hautement durable. 

Amazon RDS publie chaque journal de base de données MySQL sous la forme d'un flux de base de données distinct dans le groupe de journaux. Par exemple, si vous configurez la fonction d'exportation de sorte à inclure le journal de requêtes lentes, les données de requêtes lentes sont stockées dans un flux de journal de requêtes lentes dans le groupe de journaux `/aws/rds/instance/my_instance/slowquery`. 

Le journal d'erreurs est activé par défaut. Le tableau ci-dessous récapitule les conditions requises pour les autres journaux MySQL.


| Log | Exigence | 
| --- | --- | 
|  Journal d'audit  |  L'instance de base de données doit disposer d'un groupe d'options personnalisées avec l'option `MARIADB_AUDIT_PLUGIN`.  | 
|  Journal général  |  L'instance de base de données doit disposer d'un groupe de paramètres personnalisés avec le paramètre `general_log = 1` pour autoriser la journalisation générale.  | 
|  Journal des requêtes lentes  |  L'instance de base de données doit disposer d'un groupe de paramètres personnalisés avec le paramètre `slow_query_log = 1` pour autoriser la journalisation de requête lente.  | 
|  Journal des erreurs d’authentification de base de données IAM  |  Vous devez activer le type de journal `iam-db-auth-error` pour une instance de base de données en créant ou en modifiant une instance de base de données.  | 
|  Sortie de journal  |  L'instance de base de données doit disposer d'un groupe de paramètres personnalisés avec le paramètre `log_output = FILE` pour écrire de journaux dans le système de fichier et les publier dans CloudWatch Logs.  | 

## Console
<a name="USER_LogAccess.MySQL.PublishtoCloudWatchLogs.CON"></a>

**Pour publier des journaux MySQL dans CloudWatch Logs à l'aide de la console**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Bases de données**, puis l'instance de base de données que vous souhaitez modifier.

1. Sélectionnez **Modify**.

1. Dans la section **Exportations des journaux**, choisissez les journaux que vous voulez commencer à publier dans CloudWatch Logs.

1. Choisissez **Continuer**, puis **Modifier l'instance de base de données** sur la page récapitulative.

## AWS CLI
<a name="USER_LogAccess.MySQL.PublishtoCloudWatchLogs.CLI"></a>

 Vous pouvez publier des journaux MySQL avec l AWS CLI. Vous pouvez appeler la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) avec les paramètres suivants : 
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`

**Note**  
Une modification apportée à l'option `--cloudwatch-logs-export-configuration` est toujours appliquée immédiatement à l'instance de base de données. Par conséquent, les options `--apply-immediately` et `--no-apply-immediately` sont sans effet.

Vous pouvez également publier des journaux MySQL en appelant les commandes AWS CLI suivantes : 
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)

Exécutez l'une de ces commandes de l'AWS CLI avec les options suivantes : 
+ `--db-instance-identifier`
+ `--enable-cloudwatch-logs-exports`
+ `--db-instance-class`
+ `--engine`

D'autres options peuvent être requises en fonction de la commande de l'AWS CLI que vous exécutez.

**Example**  
L'exemple suivant modifie une instance de base de données MySQL existante pour publier les fichiers journaux dans CloudWatch Logs. La valeur `--cloudwatch-logs-export-configuration` n'est pas un objet JSON. La clé pour cet objet est `EnableLogTypes` et sa valeur est un tableau de chaînes avec une combinaison quelconque de `audit`, `error`, `general` et `slowquery`.  
Pour Linux, macOS ou Unix :  

```
1. aws rds modify-db-instance \
2.     --db-instance-identifier mydbinstance \
3.     --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'
```
Pour Windows :  

```
1. aws rds modify-db-instance ^
2.     --db-instance-identifier mydbinstance ^
3.     --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","error","general","slowquery"]}'
```

**Example**  
L'exemple suivant crée une instance de base de données MySQL et publie les fichiers journaux dans CloudWatch Logs. La valeur `--enable-cloudwatch-logs-exports` est un tableau de chaînes JSON. Les chaînes peuvent être une combinaison de `audit`, `error`, `general` et `slowquery`.  
Pour Linux, macOS ou Unix :  

```
1. aws rds create-db-instance \
2.     --db-instance-identifier mydbinstance \
3.     --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]' \
4.     --db-instance-class db.m4.large \
5.     --engine MySQL
```
Pour Windows :  

```
1. aws rds create-db-instance ^
2.     --db-instance-identifier mydbinstance ^
3.     --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]' ^
4.     --db-instance-class db.m4.large ^
5.     --engine MySQL
```

## API RDS
<a name="USER_LogAccess.MySQL.PublishtoCloudWatchLogs.API"></a>

Vous pouvez publier des journaux MySQL avec l'API RDS. Vous pouvez appeler l'action [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) avec les paramètres suivants : 
+ `DBInstanceIdentifier`
+ `CloudwatchLogsExportConfiguration`

**Note**  
Une modification apportée au paramètre `CloudwatchLogsExportConfiguration` est toujours appliquée immédiatement à l'instance de base de données. Par conséquent, le paramètre `ApplyImmediately` est sans effet.

Vous pouvez également publier des journaux MySQL en appelant les opérations d'API RDS suivantes : 
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html)

Exécutez l'une de ces opérations d'API RDS avec les paramètres suivants : 
+ `DBInstanceIdentifier`
+ `EnableCloudwatchLogsExports`
+ `Engine`
+ `DBInstanceClass`

D'autres paramètres peuvent être requis en fonction de la commande d'AWS CLI que vous exécutez.

# Envoi de la sortie du journal MySQL à des tables
<a name="Appendix.MySQL.CommonDBATasks.Logs"></a>

Vous pouvez diriger le journal des requêtes lentes et le journal général vers des tables sur l’instance de base de données en créant un groupe de paramètres DB et en définissant le paramètre du serveur `log_output` sur `TABLE`. Les requêtes générales sont ensuite enregistrées dans la table `mysql.general_log` et les requêtes lentes dans la table `mysql.slow_log`. Vous pouvez interroger les tables pour accéder aux informations des journaux. L’activation de cette journalisation augmente le volume de données écrites dans la base de données, ce qui peut dégrader les performances.

Par défaut, le journal général et le journal des requêtes lentes sont désactivés. Afin d’activer la journalisation dans les tables, vous devez également définir les paramètres `general_log` et `slow_query_log` sur `1`.

Les tables de journaux continuent de grossir jusqu’à ce que les activités de journalisation correspondantes soient désactivées en redéfinissant le paramètre approprié sur `0`. Avec le temps, une grande quantité de données s’accumule et risque d’utiliser une part considérable de l’espace de stockage alloué. Amazon RDS ne vous permet pas de tronquer les tables de journaux, mais vous pouvez déplacer leurs contenus. Lorsque vous procédez à la rotation d’une table, son contenu est enregistré dans une table de sauvegarde et une nouvelle table de journal vide est créée. Vous pouvez effectuer une rotation manuelle des tables de journaux avec les procédures de ligne de commande suivantes, dans lesquelles l’invite de commande est indiquée par `PROMPT>` : 

```
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
```

Pour supprimer totalement les anciennes données et récupérer l’espace de disque, appelez deux fois à la suite la procédure appropriée. 

# Configuration d' RDS pour la journalisation binaire MySQL pour les bases de données mono-AZ
<a name="USER_LogAccess.MySQL.BinaryFormat"></a>

Le *journal binaire* est un jeu de fichiers journaux contenant des informations sur les modifications de données apportées à une instance de serveur MySQL. Le journal binaire contient des informations telles que les suivantes :
+ Événements décrivant les modifications apportées à la base de données telles que la création de tables ou les modifications de lignes
+ Informations sur la durée de chaque instruction qui a mis à jour les données
+ Événements pour des instructions pouvant mettre à jour des données mais ne l’ayant pas fait

Le journal binaire enregistre les instructions envoyées pendant la réplication. Il est également requis pour certaines opérations de récupération. Pour plus d’informations, consultez [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) dans la documentation MySQL.

La fonction de sauvegarde automatisée détermine si la journalisation binaire est activée ou désactivée pour MySQL. Vous avez les options suivantes :

Activer la journalisation binaire  
Définissez la période de rétention des sauvegardes sur une valeur positive différente de zéro.

Désactiver la journalisation binaire  
Définissez la période de rétention des sauvegardes sur zéro.

Pour plus d’informations, consultez [Activation des sauvegardes automatiques](USER_WorkingWithAutomatedBackups.Enabling.md).

MySQL on Amazon RDS prend en charge les formats de journalisation binaire *basés sur les lignes*, *basés sur les instructions* et *mixtes*. Nous recommandons le format mixte, sauf si vous avez besoin d’un format binlog spécifique. Pour plus de détails sur les différents formats de journalisation binaire MySQL, consultez [Formats de journalisation binaire](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html) dans la documentation MySQL.

Si vous prévoyez d’utiliser la réplication, le format de journalisation binaire est important, car il détermine le dossier de modifications de données qui est enregistré dans la source et envoyés aux cibles de réplication. Pour plus d’informations sur les avantages et les désavantages des différents formats de journalisation binaire pour la réplication, consultez [Advantages and Disadvantages of Statement-Based and Row-Based Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) dans la documentation MySQL.

**Important**  
Avec MySQL 8.0.34, MySQL a rendu le paramètre `binlog_format` obsolète. Dans les versions ultérieures de MySQL, MySQL prévoit de supprimer le paramètre et de ne prendre en charge que la réplication basée sur les lignes. Par conséquent, nous recommandons d’utiliser la journalisation basée sur les lignes pour les nouvelles configurations de réplication MySQL. Pour plus d’informations, consultez [binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format) dans la documentation MySQL.  
Les versions 8.0 et 8.4 de MySQL acceptent le paramètre `binlog_format`. Lors de l’utilisation de ce paramètre, MySQL émet un avertissement d’obsolescence. Dans une future version majeure, MySQL supprimera le paramètre `binlog_format`.  
La réplication basée sur les instructions peut provoquer des incohérences entre l’instance source et un réplica en lecture. Pour plus d’informations, consultez [Determination of Safe and Unsafe Statements in Binary Logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) dans la documentation MySQL.  
L'activation de la journalisation binaire augmente le nombre d' I/O opérations d'écriture sur le disque sur le d'instances de base de données. Vous pouvez surveiller l'utilisation des IOPS à l'aide de cette `WriteIOPS` `` CloudWatch métrique.

**Pour définir le format de journalisation binaire MySQL**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Groupes de paramètres**.

1. Choisissez le groupe de paramètres de bases de données, associé à l’instance de base de données, que vous voulez modifier.

   Vous ne pouvez pas modifier un groupe de paramètres par défaut. Si l’instance utilise un groupe de paramètres par défaut, créez un nouveau groupe et associez-le à l’instance.

   Pour plus d’informations sur les groupes de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).

1. Pour **Actions**, choisissez **Modifier**.

1. Définissez le paramètre `binlog_format` au format de journalisation binaire de votre choix (`ROW`, `STATEMENT` ou `MIXED`).

   Vous pouvez désactiver la journalisation binaire en définissant la période de conservation des sauvegardes d’une instance de base de données sur zéro, mais cela désactive les sauvegardes automatiques quotidiennes. La désactivation des sauvegardes automatiques désactive ou désactive la variable de session `log_bin`. Cela désactive la journalisation binaire sur l’instance de base de données RDS for MySQL, qui à son tour réinitialise la variable de session `binlog_format` à la valeur par défaut de `ROW` dans la base de données. Nous vous recommandons de ne pas désactiver les sauvegardes. Pour plus d’informations sur le paramètre **Période de rétention des sauvegardes**, consultez [Paramètres des instances de base de données](USER_ModifyInstance.Settings.md).

1. Choisissez **Save changes** (Enregistrer les modifications)pour enregistrer les mises à jour apportées au groupe de paramètres .

Le paramètre `binlog_format` étant dynamique dans RDS for MySQL, vous n’avez pas besoin de redémarrer l’instance de base de données pour que les modifications s’appliquent. (Notez que dans Aurora MySQL, ce paramètre est statique. Pour plus d’informations, consultez [Configuration de la journalisation binaire Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html).)

**Important**  
La modification d’un groupe de paramètres de base de données affecte toutes les instances de base de données qui utilisent ce dernier. Si vous souhaitez spécifier différents formats de journalisation binaire pour différentes instances de base de données MySQL dans une AWS région, les instances de base de données doivent utiliser différents groupes de paramètres de base de données. Ces groupes de paramètres identifient différents formats de journalisation. Affectez le groupe de paramètres de base de données approprié à chaque instance de base de données.

# Configuration de la journalisation binaire MySQL pour les clusters de bases de données multi-AZ
<a name="USER_Binlog.MultiAZ"></a>

La journalisation binaire dans les clusters de bases de données multi-AZ Amazon RDS for MySQL enregistre toutes les modifications de base de données afin de prendre en charge la réplication point-in-time, la restauration et l'audit. Dans les clusters de bases de données multi-AZ, les journaux binaires synchronisent les nœuds secondaires avec le nœud primaire, ce qui garantit la cohérence des données entre les zones de disponibilité et permet des basculements fluides. 

Pour optimiser la journalisation binaire, Amazon RDS prend en charge la compression des transactions des journaux binaires, ce qui réduit les exigences de stockage pour les journaux binaires et améliore l’efficacité de la réplication.

**Topics**
+ [Compression des transactions de journaux binaires pour les clusters de bases de données multi-AZ](#USER_Binlog.MultiAZ.compression)
+ [Configuration de la compression des transactions de journaux binaires pour les clusters de bases de données multi-AZ](#USER_Binlog.MultiAZ.configuring)

## Compression des transactions de journaux binaires pour les clusters de bases de données multi-AZ
<a name="USER_Binlog.MultiAZ.compression"></a>

La compression des transactions du journal binaire utilise l’algorithme zstd pour réduire la taille des données de transaction stockées dans les journaux binaires. Lorsqu'il est activé, le moteur de base de données MySQL compresse les charges utiles des transactions en un seul événement, minimisant I/O ainsi les frais de stockage. Cette fonctionnalité améliore les performances des bases de données, réduit la taille des journaux binaires et optimise l’utilisation des ressources pour la gestion et la réplication des journaux dans les clusters de bases de données multi-AZ.

Amazon RDS fournit la compression des transactions de journaux binaires pour les clusters de bases de données multi-AZ RDS for MySQL via les paramètres suivants :
+ `binlog_transaction_compression` : lorsque cette option est activée (`1`), le moteur de base de données compresse les données utiles des transactions et les écrit dans le journal binaire sous la forme d’un événement unique. Cela réduit l'utilisation du stockage et les I/O frais généraux. Ce paramètre est désactivé par défaut.
+ `binlog_transaction_compression_level_zstd` : configure le niveau de compression zstd pour les transactions du journal binaire. Des valeurs plus élevées augmentent le taux de compression, ce qui réduit encore les besoins en stockage mais augmente l’utilisation du processeur et de la mémoire pour la compression. La valeur par défaut est de 3, avec une plage de 1 à 22.

Ces paramètres vous permettent d’optimiser la compression des journaux binaires en fonction des caractéristiques de la charge de travail et de la disponibilité des ressources. Pour plus d’informations, consultez [Compression des transactions de journaux binaires](https://dev.mysql.com/doc/refman/8.4/en/binary-log-transaction-compression.html) dans la documentation MySQL.

La compression des transactions dans les journaux binaires présente les principaux avantages suivants :
+ La compression réduit la taille des journaux binaires, en particulier pour les charges de travail comportant des transactions importantes ou des volumes d’écriture élevés.
+ Les journaux binaires plus petits réduisent le réseau et la I/O surcharge, améliorant ainsi les performances de réplication.
+ Le paramètre `binlog_transaction_compression_level_zstd` permet de contrôler le compromis entre le taux de compression et la consommation de ressources.

## Configuration de la compression des transactions de journaux binaires pour les clusters de bases de données multi-AZ
<a name="USER_Binlog.MultiAZ.configuring"></a>

Pour configurer la compression des transactions de journaux binaires pour un cluster de bases de données multi-AZ RDS for MySQL, modifiez les paramètres de cluster appropriés en fonction de vos exigences de charge de travail.

### Console
<a name="USER_Binlog.MultiAZ.configuring-console"></a>

**Pour activer la compression des transactions de journaux binaires**

1. Modifiez le groupe de paramètres du cluster de bases de données pour définir le paramètre `binlog_transaction_compression` sur `1`.

1. (Facultatif) Ajustez la valeur du paramètre `binlog_transaction_compression_level_zstd` en fonction de vos exigences en matière de charge de travail et de la disponibilité des ressources.

Pour de plus amples informations, veuillez consulter [Modification des paramètres d'un groupe de paramètres de cluster de base de données ](USER_WorkingWithParamGroups.ModifyingCluster.md).

### AWS CLI
<a name="USER_Binlog.MultiAZ.configuring-cli"></a>

Pour configurer la compression des transactions du journal binaire à l'aide de AWS CLI, utilisez la commande [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html).

**Example**  
Pour Linux, macOS ou Unix :  

```
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name your-cluster-parameter-group \
  --parameters "ParameterName=binlog_transaction_compression,ParameterValue=1,ApplyMethod=pending-reboot"
```
Pour Windows :  

```
aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name your-cluster-parameter-group ^
  --parameters "ParameterName=binlog_transaction_compression,ParameterValue=1,ApplyMethod=pending-reboot"
```

### API RDS
<a name="USER_Binlog.MultiAZ.configuring-api"></a>

Pour configurer la compression des transactions de journaux binaires à l’aide de l’API Amazon RDS, utilisez l’opération [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html).

# Accès aux journaux binaires MySQL
<a name="USER_LogAccess.MySQL.Binarylog"></a>

Vous pouvez utiliser l'utilitaire mysqlbinlog pour télécharger ou diffuser des journaux binaires à partir des instances de base de données RDS for MySQL. Le journal binaire est téléchargé dans votre ordinateur local et vous pouvez effectuer des actions comme relire le journal à l'aide de l'utilitaire mysql. Pour plus d'informations sur l'utilisation de l'utilitaire mysqlbinlog, consultez [Using mysqlbinlog to back up binary log files](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html) (Utilisation de mysqlbinlog pour sauvegarder les fichiers journaux binaires) dans la documentation MySQL.

Pour exécuter à nouveau l'utilitaire mysqlbinlog sur une instance Amazon RDS, utilisez les options suivantes :
+ `--read-from-remote-server` : obligatoire.
+ `--host` : le nom DNS du point de terminaison de l'instance.
+ `--port` : le port utilisé par l'instance.
+ `--user` : un utilisateur MySQL ayant l'autorisation `REPLICATION SLAVE`.
+ `--password` : le mot de passe de l'utilisateur MySQL ou omettez la valeur de mot de passe pour que l'utilitaire vous invite à saisir un mot de passe.
+ `--raw` : téléchargez le fichier au format binaire.
+ `--result-file` : le fichier local qui recevra la sortie brute.
+ `--stop-never` : diffusez les fichiers journaux binaires.
+ `--verbose` : lorsque vous utilisez le format binlog `ROW`, incluez cette option pour afficher les événements de ligne sous forme d'instructions pseudo-SQL. Pour plus d'informations sur l'option `--verbose`, consultez [mysqlbinlog row event display](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html) (Affichage d'événements de ligne mysqlbinlog) dans la documentation MySQL.
+ Spécifiez les noms pour un ou plusieurs fichiers journaux binaires. Pour obtenir la liste des journaux disponibles, utilisez la commande SQL `SHOW BINARY LOGS`.

Pour plus d'informations sur les options mysqlbinlog, consultez [mysqlbinlog — Utility for processing binary log files](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) (mysqlbinlog : utilitaire de traitement des fichiers journaux binaires) dans la documentation MySQL.

Les exemples suivants montrent comment utiliser l'utilitaire mysqlbinlog.

Pour Linux, macOS ou Unix :

```
mysqlbinlog \
    --read-from-remote-server \
    --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \
    --port=3306  \
    --user ReplUser \
    --password \
    --raw \
    --verbose \
    --result-file=/tmp/ \
    binlog.00098
```

Pour Windows :

```
mysqlbinlog ^
    --read-from-remote-server ^
    --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com ^
    --port=3306  ^
    --user ReplUser ^
    --password ^
    --raw ^
    --verbose ^
    --result-file=/tmp/ ^
    binlog.00098
```

Les journaux binaires doivent rester disponibles sur l’instance de base de données pour que l’utilitaire mysqlbinlog puisse y accéder. Pour garantir leur disponibilité, utilisez la procédure [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) stockée et spécifiez une période suffisamment longue pour télécharger les journaux. Si cette configuration n’est pas définie, Amazon RDS purge les journaux binaires dès que possible, ce qui entraîne des lacunes dans les journaux binaires récupérés par l’utilitaire mysqlbinlog. 

L'exemple suivant définit la période de conservation sur 1 jour.

```
call mysql.rds_set_configuration('binlog retention hours', 24);
```

Pour afficher les paramètres actuels, utilisez la procédure stockée [mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration).

```
call mysql.rds_show_configuration;
```

# Fichiers journaux de base de données Amazon RDS for Oracle
<a name="USER_LogAccess.Concepts.Oracle"></a>

Vous pouvez accéder aux journaux des alertes, aux fichiers d’audits et aux fichiers de trace Oracle à l’aide de la console Amazon RDS ou de l’API. Pour plus d’informations sur l’affichage, le téléchargement ou la consultation des journaux de base de données basés sur des fichiers, consultez [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md). 

Les fichiers d’audit Oracle fournis sont les fichiers d’audit Oracle standard. Amazon RDS prend en charge la fonction d’audit fin (FGA) Oracle. Cependant, l’accès aux journaux ne donne pas accès aux événements FGA stockés dans la table `SYS.FGA_LOG$`, accessibles via la vue `DBA_FGA_AUDIT_TRAIL`. 

L’opération de l’API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html) qui répertorie les fichiers journaux Oracle disponibles pour une instance de base de données ignore le paramètre `MaxRecords` et renvoie jusqu’à 1 000 enregistrements. L’appel renvoie `LastWritten` sous la forme d’une date POSIX en millisecondes.

**Topics**
+ [Programme de rétention](#USER_LogAccess.Concepts.Oracle.Retention)
+ [Utilisation des fichiers de trace Oracle](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles)
+ [Publication de journaux Oracle sur Amazon CloudWatch Logs](#USER_LogAccess.Oracle.PublishtoCloudWatchLogs)
+ [Accès aux journaux des alertes et aux journaux de l’écouteur](#USER_LogAccess.Concepts.Oracle.AlertLogAndListenerLog)

## Programme de rétention
<a name="USER_LogAccess.Concepts.Oracle.Retention"></a>

Le moteur de base de données Oracle peut procéder à la rotation des fichiers journaux s’ils deviennent très volumineux. Pour conserver les fichiers d’audit ou de trace, vous devez les télécharger. Si vous stockez les fichiers localement, vous réduisez vos coûts de stockage Amazon RDS et libérez plus d’espace pour vos données. 

Le tableau suivant présente le programme de rétention des journaux d’alertes, des fichiers d’audit et des fichiers de trace Oracle sur Amazon RDS. 


****  

| Log type (Type de journal) | Programme de rétention | 
| --- | --- | 
|  Journaux des alertes  |   Le journal d’alerte de texte fait l’objet d’une rotation quotidienne avec une rétention de 30 jours gérée par Amazon RDS. Le journal d’alerte XML est conservé au moins 7 jours. Vous pouvez accéder à ce journal grâce à la vue `ALERTLOG`.   | 
|  Fichiers d’audit  |   La période de rétention par défaut des fichiers d’audit est de 7 jours. Amazon RDS forrait supprimer des fichiers d’audit datant de plus de sept jours.   | 
|  Fichiers de trace  |  La période de rétention par défaut des fichiers de trace est de 7 jours. Amazon RDS forrait supprimer des fichiers de trace datant de plus de sept jours.   | 
|  Journaux de l’écouteur  |   La période de rétention par défaut pour les journaux d’écouteur est de 7 jours. Amazon RDS forrait supprimer les journaux d’écouteur datant de plus de 7 jours.   | 

**Note**  
Les fichiers d’audit et les fichiers de trace partagent la même configuration de rétention.

## Utilisation des fichiers de trace Oracle
<a name="USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles"></a>

Vous trouverez ci-après de descriptions de procédures Amazon RDS permettant de créer, d’actualiser, de supprimer les fichiers de trace ou d’y accéder.

**Topics**
+ [Liste de fichiers](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.ViewingBackgroundDumpDest)
+ [Génération de fichiers de trace et suivi d’une session](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Generating)
+ [Récupération de fichiers de trace](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Retrieving)
+ [Purge des fichiers de trace](#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Purging)

### Liste de fichiers
<a name="USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.ViewingBackgroundDumpDest"></a>

Vous pouvez utiliser l’une ou l’autre de deux procédures permettent d’accéder à tous les fichiers dans le chemin `background_dump_dest`. La première actualise la liste de l’ensemble des fichiers actuellement dans `background_dump_dest`. 

```
1. EXEC rdsadmin.manage_tracefiles.refresh_tracefile_listing;
```

Une fois la liste actualisée, interrogez la vue suivante pour accéder aux résultats.

```
1. SELECT * FROM rdsadmin.tracefile_listing;
```

Vous pouvez également utiliser `FROM table` pour diffuser des données non relationnelles dans un format de table afin de répertorier le contenu de l’annuaire de bases de données.

```
1. SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir('BDUMP'));
```

La requête suivante affiche le texte d’un fichier journal.

```
1. SELECT text FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP','alert_dbname.log.date'));
```

Sur un réplica en lecture, obtenez le nom du répertoire BDUMP en interrogeant `V$DATABASE.DB_UNIQUE_NAME`. Si le nom unique est `DATABASE_B`, le répertoire BDUMP est `BDUMP_B`. L’exemple suivant interroge le nom BDUMP sur un réplica, puis utilise ce nom pour interroger le contenu de `alert_DATABASE.log.2020-06-23`.

```
1. SELECT 'BDUMP' || (SELECT regexp_replace(DB_UNIQUE_NAME,'.*(_[A-Z])', '\1') FROM V$DATABASE) AS BDUMP_VARIABLE FROM DUAL;
2. 
3. BDUMP_VARIABLE
4. --------------
5. BDUMP_B
6. 
7. SELECT TEXT FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP_B','alert_DATABASE.log.2020-06-23'));
```

### Génération de fichiers de trace et suivi d’une session
<a name="USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Generating"></a>

Puisqu’il n’existe aucune restriction sur `ALTER SESSION`, un grand nombre de méthodes standard permettant de générer des fichiers de trace dans Oracle restent disponibles pour les instances de base de données Amazon RDS. Les procédures suivantes sont fournies pour les fichiers de trace pour lesquels l’accès doit être élargi. 


****  

|  Méthode Oracle  |  Méthode Amazon RDS | 
| --- | --- | 
|  `oradebug hanganalyze 3 `  |  `EXEC rdsadmin.manage_tracefiles.hanganalyze; `  | 
|  `oradebug dump systemstate 266 `  |  `EXEC rdsadmin.manage_tracefiles.dump_systemstate;`  | 

Vous pouvez utiliser de nombreuses méthodes standard pour suivre des sessions individuelles connectées à une instance de base de données Oracle dans Amazon RDS. Pour activer le suivi d'une session, vous pouvez exécuter des sous-programmes dans des PL/SQL packages fournis par Oracle, tels que `DBMS_SESSION` et`DBMS_MONITOR`. Pour plus d’informations, consultez [Activation du suivi d’une session](https://docs.oracle.com/database/121/TGSQL/tgsql_trace.htm#GUID-F872D6F9-E015-481F-80F6-8A7036A6AD29) dans la documentation d’Oracle. 

### Récupération de fichiers de trace
<a name="USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Retrieving"></a>

Vous pouvez récupérer tous les fichiers dans `background_dump_dest` à l’aide d’une requête SQL standard sur un tableau Amazon RDS externe gérée. Pour utiliser cette méthode, vous devez exécuter la procédure définissant l’emplacement de cette table sur le fichier de trace spécifique. 

Par exemple, vous pouvez utiliser la vue `rdsadmin.tracefile_listing` indiquée ci-dessus pour répertorier tous les fichiers de trace sur le système. Vous pouvez ensuite définir la vue `tracefile_table` afin qu’elle pointe vers le fichier de trace souhaité à l’aide de la procédure suivante. 

```
1. EXEC rdsadmin.manage_tracefiles.set_tracefile_table_location('CUST01_ora_3260_SYSTEMSTATE.trc');
```

L’exemple suivant créé une table externe selon le schéma actuel. L’emplacement est défini sur le fichier fourni. Vous pouvez récupérer le contenu dans un fichier local à l’aide d’une requête SQL. 

```
1. SPOOL /tmp/tracefile.txt
2. SELECT * FROM tracefile_table;
3. SPOOL OFF;
```

### Purge des fichiers de trace
<a name="USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.Purging"></a>

Les fichiers de trace peuvent s’accumuler et consommer de l’espace sur le disque. Par défaut, Amazon RDS purge les fichiers de trace et les fichiers journaux de plus de sept jours. Vous pouvez afficher et définir la période de rétention des fichiers à l’aide de la procédure `show_configuration`. Vous devez exécuter la commande `SET SERVEROUTPUT ON` afin de pouvoir afficher les résultats de la configuration. 

L’exemple suivant affiche la période de rétention des fichiers de trace actuelle, puis définit une nouvelle période. 

```
 1. # Show the current tracefile retention
 2. SQL> EXEC rdsadmin.rdsadmin_util.show_configuration;
 3. NAME:tracefile retention
 4. VALUE:10080
 5. DESCRIPTION:tracefile expiration specifies the duration in minutes before tracefiles in bdump are automatically deleted.
 6. 		
 7. # Set the tracefile retention to 24 hours:
 8. SQL> EXEC rdsadmin.rdsadmin_util.set_configuration('tracefile retention',1440);
 9. SQL> commit;
10. 
11. #show the new tracefile retention
12. SQL> EXEC rdsadmin.rdsadmin_util.show_configuration;
13. NAME:tracefile retention
14. VALUE:1440
15. DESCRIPTION:tracefile expiration specifies the duration in minutes before tracefiles in bdump are automatically deleted.
```

En complément du processus de purge périodique, vous pouvez supprimer manuellement des fichiers de `background_dump_dest`. L’exemple suivant montre comment purger tous les fichiers datant de plus de cinq minutes. 

```
EXEC rdsadmin.manage_tracefiles.purge_tracefiles(5);
```

Vous pouvez également purger tous les fichiers correspondant à un modèle spécifique (dans ce cas, n’incluez pas l’extension de fichier, par exemple .trc). L’exemple suivant montre comment purger tous les fichiers commençant par `SCHPOC1_ora_5935`. 

```
1. EXEC rdsadmin.manage_tracefiles.purge_tracefiles('SCHPOC1_ora_5935');
```

## Publication de journaux Oracle sur Amazon CloudWatch Logs
<a name="USER_LogAccess.Oracle.PublishtoCloudWatchLogs"></a>

Vous pouvez configurer votre instance de base de données RDS pour Oracle afin de publier les données de journal dans un groupe de CloudWatch journaux dans Amazon Logs. Avec CloudWatch Logs, vous pouvez analyser les données du journal et les utiliser CloudWatch pour créer des alarmes et afficher des métriques. Vous pouvez utiliser CloudWatch les journaux pour stocker vos enregistrements de journal dans un espace de stockage hautement durable. 

Amazon RDS publie chaque journal de base de données Oracle sous la forme d’un flux de base de données distinct dans le groupe de journaux. Par exemple, si vous configurez la fonction d’exportation de sorte à inclure le journal d’audit, les données d’audit sont stockées dans un flux de journal d’audit dans le groupe de journaux `/aws/rds/instance/my_instance/audit`. Le tableau suivant récapitule les conditions requises pour que RDS for Oracle publie des journaux sur Amazon CloudWatch Logs.


| Nom du journal | Exigence | Par défaut | 
| --- | --- | --- | 
|  Journal des alertes  |  Aucune. Vous ne pouvez pas désactiver ce journal.  |  Activé  | 
|  Journal de suivi  |  Définissez le paramètre `trace_enabled` sur `TRUE` ou laissez-le tel que défini par défaut.  |  `TRUE`  | 
|  Journal d’audit  |  Définissez le paramètre `audit_trail` sur l’une des valeurs autorisées suivantes : <pre>{ none | os | db [, extended] | xml [, extended] }</pre>  |  `none`  | 
|  Journal d’écoute  |  Aucune. Vous ne pouvez pas désactiver ce journal.  |  Activé  | 
|  Journal d’Oracle Management Agent  |  Aucune. Vous ne pouvez pas désactiver ce journal.  |  Activé  | 

Le journal d’Oracle Management Agent contient les groupes de journaux présentés dans le tableau suivant.


****  

| Nom du journal | CloudWatch groupe de journaux | 
| --- | --- | 
| emctl.log | oemagent-emctl | 
| emdctlj.log | oemagent-emdctlj | 
| gcagent.log | oemagent-gcagent | 
| gcagent\$1errors.log | oemagent-gcagent-errors | 
| emagent.nohup | oemagent-emagent-nohup | 
| secure.log | oemagent-secure | 

Pour plus d’informations, consultez [Localisation des fichiers de suivi et des fichiers journaux de Management Agent](https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/13.4/emadm/locating-management-agent-log-and-trace-files1.html#GUID-9C710D78-6AA4-42E4-83CD-47B5FF4892DF) dans la documentation Oracle.

### Console
<a name="USER_LogAccess.Oracle.PublishtoCloudWatchLogs.console"></a>

**Pour publier les journaux Oracle DB dans CloudWatch Logs à partir du AWS Management Console**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Bases de données**, puis l’instance de base de données que vous souhaitez modifier.

1. Sélectionnez **Modify (Modifier)**.

1. Dans la section **Exportations de journaux**, choisissez les journaux que vous souhaitez commencer à publier dans CloudWatch Logs.

1. Choisissez **Continuer**, puis **Modifier l’instance de base de données** sur la page récapitulative.

### AWS CLI
<a name="USER_LogAccess.Oracle.PublishtoCloudWatchLogs.CLI"></a>

Pour publier les journaux Oracle vous pouvez utiliser la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) avec les paramètres suivants : 
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`

**Note**  
Une modification apportée à l’option `--cloudwatch-logs-export-configuration` est toujours appliquée immédiatement à l’instance de base de données. Par conséquent, les options `--apply-immediately` et `--no-apply-immediately` sont sans effet.

Vous pouvez également publier des journaux Oracle en utilisant les commandes suivantes : 
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)

**Example**  
L'exemple suivant crée une instance de base de données Oracle avec la publication CloudWatch des journaux activée. La valeur `--cloudwatch-logs-export-configuration` est un tableau de chaînes JSON. Les chaînes peuvent être une combinaison de `alert`, `audit`, `listener` et `trace`.  
Pour Linux, macOS ou Unix :  

```
aws rds create-db-instance \
    --db-instance-identifier mydbinstance \
    --cloudwatch-logs-export-configuration '["trace","audit","alert","listener","oemagent"]' \
    --db-instance-class db.m5.large \
    --allocated-storage 20 \
    --engine oracle-ee \
    --engine-version 19.0.0.0.ru-2024-04.rur-2024-04.r1 \
    --license-model bring-your-own-license \
    --master-username myadmin \
    --manage-master-user-password
```
Pour Windows :  

```
aws rds create-db-instance ^
    --db-instance-identifier mydbinstance ^
    --cloudwatch-logs-export-configuration trace alert audit listener oemagent ^
    --db-instance-class db.m5.large ^
    --allocated-storage 20 ^
    --engine oracle-ee ^
    --engine-version 19.0.0.0.ru-2024-04.rur-2024-04.r1 ^
    --license-model bring-your-own-license ^
    --master-username myadmin ^
    --manage-master-user-password
```

**Example**  
L'exemple suivant modifie une instance de base de données Oracle existante pour publier des fichiers CloudWatch journaux dans Logs. La valeur `--cloudwatch-logs-export-configuration` n’est pas un objet JSON. La clé pour cet objet est `EnableLogTypes` et sa valeur est un tableau de chaînes avec une combinaison quelconque de `alert`, `audit`, `listener` et `trace`.  
Pour Linux, macOS ou Unix :  

```
aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --cloudwatch-logs-export-configuration '{"EnableLogTypes":["trace","alert","audit","listener","oemagent"]}'
```
Pour Windows :  

```
aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --cloudwatch-logs-export-configuration EnableLogTypes=\"trace\",\"alert\",\"audit\",\"listener\",\"oemagent\"
```

**Example**  
L'exemple suivant modifie une instance de base de données Oracle existante pour désactiver la publication des fichiers journaux d'audit et d'écoute dans Logs. CloudWatch La valeur `--cloudwatch-logs-export-configuration` n’est pas un objet JSON. La clé pour cet objet est `DisableLogTypes` et sa valeur est un tableau de chaînes avec une combinaison quelconque de `alert`, `audit`, `listener` et `trace`.  
Pour Linux, macOS ou Unix :  

```
aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --cloudwatch-logs-export-configuration '{"DisableLogTypes":["audit","listener"]}'
```
Pour Windows :  

```
aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --cloudwatch-logs-export-configuration DisableLogTypes=\"audit\",\"listener\"
```

### API RDS
<a name="USER_LogAccess.Oracle.PublishtoCloudWatchLogs.API"></a>

Vous pouvez publier des journaux Oracle Database avec l’API RDS. Vous pouvez appeler l’action [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) avec les paramètres suivants : 
+ `DBInstanceIdentifier`
+ `CloudwatchLogsExportConfiguration`

**Note**  
Une modification apportée au paramètre `CloudwatchLogsExportConfiguration` est toujours appliquée immédiatement à l’instance de base de données. Par conséquent, le paramètre `ApplyImmediately` est sans effet.

Vous pouvez également publier des journaux Oracle en appelant les opérations de l’API RDS suivantes : 
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html)

Exécutez l’une de ces opérations d’API RDS avec les paramètres suivants : 
+ `DBInstanceIdentifier`
+ `EnableCloudwatchLogsExports`
+ `Engine`
+ `DBInstanceClass`

D’autres paramètres peuvent être requis en fonction de l’opération RDS que vous exécutez.

## Accès aux journaux des alertes et aux journaux de l’écouteur
<a name="USER_LogAccess.Concepts.Oracle.AlertLogAndListenerLog"></a>

Vous pouvez consulter le journal d’alertes à l’aide de la console Amazon RDS. Vous pouvez aussi utiliser l’instruction SQL suivante.

```
1. SELECT message_text FROM alertlog;
```

Accédez au journal de l'écouteur à l'aide d'Amazon CloudWatch Logs.

**Note**  
Oracle procède à la rotation des journaux des alertes et de l’écouteur lorsqu’ils dépassent 10 Mo. A ce moment là, ils ne sont pas disponibles dans les vues Amazon RDS.

# Fichiers journaux de base de données RDS pour PostgreSQL
<a name="USER_LogAccess.Concepts.PostgreSQL"></a>

Vous pouvez surveiller les types de fichiers journaux suivants :
+ Journal PostgreSQL
+ Journal de mise à niveau
+ Journal des erreurs d’authentification de base de données IAM
**Note**  
Pour activer les journaux d’erreurs d’authentification de base de données IAM, vous devez d’abord activer l’authentification de base de données IAM pour votre instance de base de données RDS pour PostgreSQL. Pour plus d’informations sur l’authentification de la base de données IAM, consultez [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md).

RDS pour PostgreSQL consigne les activités de base de données dans le fichier journal PostgreSQL par défaut. Pour une instance de base de données PostgreSQL sur site, ces messages sont stockés localement dans `log/postgresql.log`. Pour une instance de base de données RDS pour PostgreSQL, le fichier journal est disponible sur l’instance Amazon RDS. Ces journaux sont également accessibles via le AWS Management Console, où vous pouvez les consulter ou les télécharger. Le niveau de journalisation par défaut capture les échecs de connexion, les erreurs de serveur fatales, les blocages et les échecs de requête.

Pour plus d’informations sur l’affichage, le téléchargement et la consultation des journaux de base de données basés sur des fichiers, consultez [Surveillance des fichiers journaux Amazon RDS](USER_LogAccess.md). Pour en savoir plus sur les journaux PostgreSQL, consultez la section [Working with Amazon RDS and Aurora PostgreSQL logs: Part 1 (Utilisation des journaux Amazon RDS et Aurora PostgreSQL : Partie 1)](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) et [Working with Amazon RDS and Aurora PostgreSQL logs: Part 2 (Utilisation des journaux Amazon RDS et Aurora PostgreSQL : Partie 2)](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/). 

Outre les journaux PostgreSQL standard décrits dans cette rubrique, RDS pour PostgreSQL prend également en charge l’extension PostgreSQL Audit (`pgAudit`). La plupart des secteurs réglementés et des agences gouvernementales doivent conserver un journal d’audit ou une piste d’audit des modifications apportées aux données afin de se conformer aux exigences légales. Pour plus d’informations sur l’installation et l’utilisation de pgAudit, consultez [Utilisation de pgAudit pour journaliser l'activité de la base de données](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).

**Topics**
+ [Paramètres de journalisation dans RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md)
+ [Activation de la journalisation des requêtes pour votre RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md)
+ [Publication de journaux PostgreSQL sur Amazon Logs CloudWatch](#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs)

# Paramètres de journalisation dans RDS pour PostgreSQL
<a name="USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups"></a>

Vous pouvez personnaliser le comportement de journalisation de votre instance de base de données RDS pour PostgreSQL en modifiant divers paramètres. Dans le tableau suivant, vous trouverez les paramètres qui affectent combien de temps les journaux sont stockés, quand effectuer la rotation du journal et s’il convient de fournir en sortie le journal au format CSV (valeurs séparées par des virgules). Vous pouvez également trouver le texte de sortie envoyé à STDERR, entre autres paramètres. Pour modifier les valeurs des paramètres modifiables, utilisez un groupe de paramètres de base de données pour votre Instance RDS pour PostgreSQL. Pour plus d’informations, consultez [Groupes de paramètres de base de données pour les instances de base de données Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).


| Paramètre | Par défaut | Description | 
| --- | --- | --- | 
| log\$1destination | stderr | Définit le format de sortie pour le journal. La valeur par défaut est `stderr`, mais vous pouvez également spécifier une valeur séparée par des virgules (CSV) en ajoutant `csvlog` au paramètre. Pour plus d’informations, consultez [Définition de la destination du journal (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format).  | 
| log\$1filename |  postgresql.log.%Y-%m-%d-%H  | Spécifie le modèle du nom de fichier journal. Outre la valeur par défaut, ce paramètre prend en charge `postgresql.log.%Y-%m-%d` et `postgresql.log.%Y-%m-%d-%H%M` pour le modèle de nom de fichier.  | 
| log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | Définit le préfixe pour chaque ligne de journal qui est écrite sur `stderr`, afin de noter l’heure (%t), l’hôte distant (%r), l’utilisateur (%u), la base de données (%d) et l’ID du processus (%p). | 
| log\$1rotation\$1age | 60 | Minutes après lesquelles la rotation automatique du fichier journal est effectuée. Vous pouvez remplacer cette valeur par toute valeur comprise entre 1 et 1 440 minutes. Pour plus d’informations, consultez [Définition de la rotation des fichiers journaux](#USER_LogAccess.Concepts.PostgreSQL.log_rotation).  | 
| log\$1rotation\$1size | – | Taille (en Ko) à laquelle la rotation automatique du fichier journal est effectuée. Par défaut, ce paramètre n’est pas utilisé, car une rotation des journaux est effectuée en fonction du paramètre `log_rotation_age`. Pour en savoir plus, consultez [Définition de la rotation des fichiers journaux](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). | 
| rds.log\$1retention\$1period | 4320 | Les journaux PostgreSQL plus anciens que le nombre de minutes spécifié sont supprimés. La valeur par défaut de 4 320 minutes supprime les fichiers journaux après trois jours. Pour plus d’informations, consultez [Définition de la période de conservation des journaux](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period). | 

Pour identifier les problèmes d’application, vous pouvez rechercher dans le journal les échecs de requête, les échecs de connexion, les interblocages et les erreurs fatales du serveur. Par exemple, supposons que vous avez converti une application héritée d’Oracle vers Amazon RDS pour PostgreSQL, mais que certaines requêtes n’ont pas été converties correctement. Ces requêtes mal formatées génèrent des messages d’erreur que vous pouvez trouver dans les journaux pour aider à identifier les problèmes. Pour plus d’informations sur la journalisation des requêtes, consultez [Activation de la journalisation des requêtes pour votre RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md). 

Dans les rubriques suivantes, vous pouvez trouver des informations sur la manière de définir les différents paramètres qui contrôlent les détails de base de vos journaux PostgreSQL. 

**Topics**
+ [Définition de la période de conservation des journaux](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period)
+ [Définition de la rotation des fichiers journaux](#USER_LogAccess.Concepts.PostgreSQL.log_rotation)
+ [Définition de la destination du journal (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format)
+ [Compréhension du paramètre log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix)

## Définition de la période de conservation des journaux
<a name="USER_LogAccess.Concepts.PostgreSQL.log_retention_period"></a>

Le paramètre `rds.log_retention_period` indique la durée pendant laquelle votre instance de base de données RDS pour PostgreSQL conserve ses fichiers journaux. La valeur par défaut est de 3 jours (4 320 minutes), mais vous pouvez définir une valeur comprise entre 1 jour (1 440 minutes) et 7 jours (10 080 minutes). Assurez-vous que votre instance de base de données RDS pour PostgreSQL dispose d’un espace de stockage suffisant pour contenir les fichiers journaux pendant cette période.

Nous vous recommandons de publier régulièrement vos CloudWatch journaux sur Amazon Logs afin de pouvoir consulter et analyser les données système longtemps après leur suppression de votre cluster de base de données . Instance de base de données RDS pour PostgreSQL. Pour plus d’informations, consultez [Publication de journaux PostgreSQL sur Amazon Logs CloudWatch](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs).  

## Définition de la rotation des fichiers journaux
<a name="USER_LogAccess.Concepts.PostgreSQL.log_rotation"></a>

Amazon RDS crée de nouveaux fichiers journaux toutes les heures, par défaut. Le timing est contrôlé par le paramètre `log_rotation_age`. Ce paramètre a une valeur par défaut de 60 (minutes), mais vous pouvez le régler sur une valeur comprise entre 1 minute et 24 heures (1 440 minutes). Au moment de la rotation, un fichier journal distinct est créé. Le fichier est nommé selon le modèle spécifié par le paramètre `log_filename`. 

Les fichiers journaux peuvent également faire l’objet d’une rotation en fonction de leur taille, comme indiqué dans le paramètre `log_rotation_size`. Ce paramètre indique que le journal doit faire l’objet d’une rotation lorsqu’il atteint la taille spécifiée (en kilo-octets). Pour une instance de base de données RDS pour PostgreSQL, la valeur `log_rotation_size` n’est pas définie, c’est-à-dire qu’il n’y a pas de valeur spécifiée. Toutefois, vous pouvez définir ce paramètre entre 0 et 2 097 151 Ko (kilo-octets).  

Les noms de fichier journal sont basés sur le modèle de nom de fichier spécifié dans le paramètre `log_filename`. Les valeurs disponibles pour ce paramètre sont les suivantes :
+ `postgresql.log.%Y-%m-%d` : format par défaut du nom de fichier journal. Inclut l’année, le mois et la date dans le nom du fichier journal.
+ `postgresql.log.%Y-%m-%d-%H` : inclut l’heure dans le format du nom de fichier journal.

Pour plus d’informations, consultez [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE) et [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE) dans la documentation de PostgreSQL.

## Définition de la destination du journal (`stderr`, `csvlog`)
<a name="USER_LogAccess.Concepts.PostgreSQL.Log_Format"></a>

Par défaut, Amazon RDS PostgreSQL génère des journaux au format d’erreur standard (stderr). Ce format correspond au réglage par défaut du paramètre `log_destination`. Chaque message est préfixé selon le modèle spécifié dans le paramètre `log_line_prefix`. Pour plus d’informations, consultez [Compréhension du paramètre log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix). 

RDS pour PostgreSQL peut également générer les journaux au format `csvlog`. La valeur `csvlog` permet d’analyser les données du journal en tant que données CSV (valeurs séparées par des virgules). Par exemple, supposons que vous utilisez l’extension `log_fdw` pour travailler avec vos journaux en tant que tables externes. La table externe créée sur les fichiers journaux `stderr` contient une seule colonne avec les données des événements de journal. En ajoutant `csvlog` au paramètre `log_destination`, vous obtenez le fichier journal au format CSV avec des démarcations pour les différentes colonnes de la table externe. Vous pouvez désormais trier et analyser vos journaux plus facilement. Pour savoir comment utiliser `log_fdw` avec `csvlog`, consultez [Utilisation de l'extension log\$1fdw pour accéder au journal de base de données à l'aide de SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).

Si vous spécifiez `csvlog` pour ce paramètre, sachez que les deux fichiers `stderr` et `csvlog` sont générés. Assurez-vous de surveiller le stockage consommé par les journaux, en tenant compte de `rds.log_retention_period` et des autres paramètres qui affectent le stockage et la rotation des journaux. Utiliser `stderr` et `csvlog` fait plus que doubler le stockage consommé par les journaux.

Si vous ajoutez `csvlog` à `log_destination` et que vous souhaitez revenir au paramètre `stderr` seul, vous devez réinitialiser le paramètre. Pour ce faire, ouvrez la console Amazon RDS, puis ouvrez le groupe de paramètres personnalisé de la base de données pour votre instance. Choisissez le paramètre `log_destination`, choisissez **Edit parameter** (Modifier le paramètre), puis **Reset** (Réinitialiser). 

Pour plus d’informations sur la configuration de la journalisation, consultez [Working with Amazon RDS and Aurora PostgreSQL logs: Part 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) (Utiliser les journaux d’Amazon RDS et Aurora PostgreSQL : partie 1).

## Compréhension du paramètre log\$1line\$1prefix
<a name="USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix"></a>

Le format du journal `stderr` précède chaque message du journal des détails spécifiés par le paramètre `log_line_prefix`. La valeur par défaut est :

```
%t:%r:%u@%d:[%p]:t
```

À partir de la version 16 d’Aurora PostgreSQL, vous pouvez également choisir :

```
%m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a
```

Chaque entrée de journal envoyée à stderr inclut les informations suivantes en fonction de la valeur sélectionnée :
+ `%t` : heure de l’entrée du journal sans millisecondes
+ `%m` : heure de l’entrée du journal, en millisecondes
+  `%r` : adresse de l’hôte distant
+  `%u@%d` : nom d’utilisateur @ nom de base de données
+  `[%p]` : ID de processus si disponible
+  `%l` : numéro de ligne de journal par session 
+  `%e` : code d’erreur SQL 
+  `%s` : horodatage de début du processus 
+  `%v` : identifiant de transaction virtuel 
+  `%x` : ID de transaction 
+  `%c` : ID de session 
+  `%q` : délimiteur non session 
+  `%a` : nom de l’application 

# Activation de la journalisation des requêtes pour votre RDS pour PostgreSQL
<a name="USER_LogAccess.Concepts.PostgreSQL.Query_Logging"></a>

Vous pouvez collecter des informations plus détaillées sur les activités de votre base de données, notamment les requêtes, les requêtes en attente de verrouillage, les points de contrôle et de nombreux autres détails en définissant certains des paramètres répertoriés dans le tableau suivant. Cette rubrique se concentre sur la journalisation des requêtes.


| Paramètre | Par défaut | Description | 
| --- | --- | --- | 
| log\$1connections | – | Enregistre toutes les connexions réussies.  | 
| log\$1disconnections | – | Journalise la fin de chaque session et sa durée.  | 
| log\$1checkpoints | 1 | Enregistre chaque point de vérification.  | 
| log\$1lock\$1waits | – | Enregistre les longs temps d’attente pour l’acquisition d’un verrou. Ce paramètre n’est pas défini par défaut. | 
| log\$1min\$1duration\$1sample | – | (ms) Définit la durée minimum d’exécution au-delà de laquelle les instructions sont journalisées. La taille de l’échantillon est définie à l’aide du paramètre log\$1statement\$1sample\$1rate. | 
| log\$1min\$1duration\$1statement | – | Toute instruction SQL exécutée au moins pendant la durée spécifiée ou plus est journalisée. Ce paramètre n’est pas défini par défaut. L’activation de ce paramètre peut vous aider à identifier les requêtes non optimisées. | 
| log\$1statement | – | Définit le type d’instructions enregistrées. Par défaut, ce paramètre n’est pas défini, mais vous pouvez le modifier pour `all`, `ddl` ou `mod` afin de spécifier les types d’instructions SQL que vous souhaitez journaliser. Si vous spécifiez autre chose que `none` pour ce paramètre, vous devez également prendre des mesures supplémentaires pour empêcher l’exposition des mots de passe dans les fichiers journaux. Pour plus d’informations, consultez [Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtesAtténuation du risque d’exposition des mots de passe](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).  | 
| log\$1statement\$1sample\$1rate | – | Le pourcentage d’instructions dépassant la durée spécifiée dans `log_min_duration_sample` pour être journalisées, exprimé sous la forme d’une valeur à virgule flottante comprise entre 0,0 et 1,0.  | 
| log\$1statement\$1stats | – | Ecrit les statistiques de performance cumulées dans le journal du serveur. | 

## Utilisation de la journalisation pour détecter les requêtes lentes
<a name="USER_LogAccess.Concepts.PostgreSQL.Query_Logging.using"></a>

Vous pouvez journaliser les instructions et les requêtes SQL pour favoriser la recherche des requêtes lentes. Vous pouvez activer cette fonctionnalité en modifiant les valeurs des paramètres `log_statement` et `log_min_duration`, comme indiqué dans cette section. Avant d’activer la journalisation des requêtes pour votre instance de base de données RDS pour PostgreSQL, vous devez être conscient de l’exposition possible à des mots de passe dans les journaux et de la manière d’atténuer les risques. Pour plus d’informations, consultez [Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtesAtténuation du risque d’exposition des mots de passe](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). 

Vous trouverez ci-dessous des informations de référence sur les paramètres `log_statement` et `log_min_duration`.log\$1statement

Ce paramètre indique le type d’instructions SQL qui doivent être envoyées au journal. La valeur par défaut est `none`. Si vous remplacez ce paramètre par `all`, `ddl` ou `mod`, veillez à prendre les mesures recommandées pour réduire le risque d’exposition des mots de passe dans les journaux. Pour plus d’informations, consultez [Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtesAtténuation du risque d’exposition des mots de passe](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). 

**tout**  
Journalise toutes les instructions. Ce paramètre est recommandé à des fins de débogage.

**ddl**  
Journalise toutes les instructions DDL (Data Definition Language), telles que CREATE, ALTER, DROP, etc.

**mod**  
Journalise toutes les instructions DDL et les instructions de langage de manipulation des données (DML) telles que INSERT, UPDATE et DELETE, qui modifient les données.

**Aucune**  
Aucune instruction SQL n’est journalisée. Nous recommandons ce paramètre pour éviter le risque d’exposer des mots de passe dans les journaux.log\$1min\$1duration\$1statement

Toute instruction SQL exécutée au moins pendant la durée spécifiée ou plus est journalisée. Ce paramètre n’est pas défini par défaut. L’activation de ce paramètre peut vous aider à identifier les requêtes non optimisées.

**–1–2147483647**  
Le nombre de millisecondes (ms) d’exécution pendant lequel une instruction est journalisée.

**Configurer la journalisation des requêtes**

Ces étapes supposent que votre L’instance de base de données RDS pour PostgreSQL utilise un groupe de paramètres de base de données personnalisé. 

1. Définissez le paramètre `log_statement` sur `all`. L’exemple suivant illustre les informations écrites dans le fichier `postgresql.log` avec cette définition de paramètre.

   ```
   2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: statement: SELECT feedback, s.sentiment,s.confidence
   FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s
   ORDER BY s.confidence DESC;
   2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: QUERY STATISTICS
   2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:DETAIL: ! system usage stats:
   ! 0.017355 s user, 0.000000 s system, 0.168593 s elapsed
   ! [0.025146 s user, 0.000000 s system total]
   ! 36644 kB max resident size
   ! 0/8 [0/8] filesystem blocks in/out
   ! 0/733 [0/1364] page faults/reclaims, 0 [0] swaps
   ! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
   ! 19/0 [27/0] voluntary/involuntary context switches
   2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: SELECT feedback, s.sentiment,s.confidence
   FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s
   ORDER BY s.confidence DESC;
   2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:ERROR: syntax error at or near "ORDER" at character 1
   2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: ORDER BY s.confidence DESC;
   ----------------------- END OF LOG ----------------------
   ```

1. Définissez le paramètre `log_min_duration_statement`. L’exemple suivant illustre les informations écrites dans le fichier `postgresql.log` lorsque le paramètre est défini sur `1`.

   Les requêtes qui dépassent la durée spécifiée dans le paramètre `log_min_duration_statement` sont enregistrées. Vous en trouverez un exemple ci-dessous. Vous pouvez consulter le fichier journal de votre instance de base de données RDS pour PostgreSQL dans la console Amazon RDS. 

   ```
   2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: statement: DROP table comments;
   2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: duration: 167.754 ms
   2022-10-05 19:08:07 UTC::@:[355]:LOG: checkpoint starting: time
   2022-10-05 19:08:08 UTC::@:[355]:LOG: checkpoint complete: wrote 11 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.013 s, sync=0.006 s, total=1.033 s; sync files=8, longest=0.004 s, average=0.001 s; distance=131028 kB, estimate=131028 kB
   ----------------------- END OF LOG ----------------------
   ```

### Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtes
<a name="USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk"></a>

Nous vous recommandons de garder `log_statement` sur `none` pour éviter de dévoiler les mots de passe. Si vous avez réglé `log_statement` sur `all`, `ddl` ou `mod`, nous vous recommandons de suivre une ou plusieurs des étapes suivantes.
+ Pour le client, chiffrez les informations sensibles. Pour plus d’informations, consultez [Options de chiffrement](https://www.postgresql.org/docs/current/encryption-options.html) dans la documentation PostgreSQL. Utilisez les options `ENCRYPTED` (et `UNENCRYPTED`) des instructions `CREATE` et `ALTER`. Pour plus d’informations, consultez [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) dans la documentation PostgreSQL.
+ Pour votre instance de base de données RDS pour PostgreSQL, configurez et utilisez l’extension PostgreSQL Auditing (pgAudit). Cette extension supprime les informations sensibles dans les instructions CREATE et ALTER envoyées au journal. Pour de plus amples informations, veuillez consulter [Utilisation de pgAudit pour journaliser l'activité de la base de données](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md). 
+ Limitez l'accès aux CloudWatch journaux.
+ Utilisez des mécanismes d’authentification plus forts tels que IAM.

## Publication de journaux PostgreSQL sur Amazon Logs CloudWatch
<a name="USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs"></a>

Pour stocker vos enregistrements de journal PostgreSQL dans un espace de stockage hautement durable, vous pouvez utiliser Amazon Logs. CloudWatch Avec CloudWatch Logs, vous pouvez également effectuer une analyse en temps réel des données des journaux et les utiliser CloudWatch pour consulter les métriques et créer des alarmes. Par exemple, si vous définissez `log_statement` sur `ddl`, vous pouvez configurer une alarme pour vous alerter chaque fois qu’une instruction DDL est exécutée. Vous pouvez choisir de télécharger vos journaux PostgreSQL dans Logs pendant le processus de création CloudWatch de votre instance de base de données RDS pour PostgreSQL. Si vous avez choisi de ne pas télécharger de journaux à ce moment-là, vous pouvez modifier ultérieurement votre instance pour commencer à charger les journaux à partir de ce moment. En d’autres termes, les journaux existants ne sont pas chargés. Seuls les nouveaux journaux sont chargés lorsqu’ils sont créés sur votre instance de base de données RDS pour PostgreSQL modifiée.

Toutes les versions de RDS pour PostgreSQL actuellement disponibles prennent en charge la publication de fichiers journaux dans Logs. CloudWatch Pour plus d’informations, consultez [Mises à jour d’Amazon RDS pour PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html) dans *Notes de mise à jour d’Amazon RDS pour PostgreSQL*. 

Pour utiliser les CloudWatch journaux, configurez votre instance de base de données RDS pour PostgreSQL afin de publier les données des journaux dans un groupe de journaux.

Vous pouvez publier les types de CloudWatch journaux suivants dans Logs for RDS pour PostgreSQL : 
+ Journal PostgreSQL
+ Journal de mise à niveau 
+ Journal des erreurs d’authentification de base de données IAM

Une fois la configuration terminée, Amazon RDS publie les événements du journal dans les flux de journaux au sein d'un groupe de CloudWatch journaux. Par exemple, les données de journaux PostgreSQL sont stockés dans le groupe de journaux `/aws/rds/instance/my_instance/postgresql`. Pour consulter vos journaux, ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

### Console
<a name="USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs.CON"></a>

**Pour publier les journaux PostgreSQL dans Logs CloudWatch à l'aide de la console**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**.

1. Choisissez l’instance de base de données que vous souhaitez modifier, puis choisissez **Modifier**.

1. Dans la section **Exportations de journaux**, choisissez les journaux que vous souhaitez commencer à publier dans CloudWatch Logs.

   La section **Exportations de journaux** n'est disponible que pour les versions de PostgreSQL qui prennent en charge la publication dans Logs. CloudWatch 

1. Choisissez **Continuer**, puis **Modifier l’instance de base de données** sur la page récapitulative.

### AWS CLI
<a name="USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs.CLI"></a>

Vous pouvez publier des journaux PostgreSQL à l'aide du. AWS CLI Vous pouvez appeler la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) avec les paramètres suivants.
+ `--db-instance-identifier`
+ `--cloudwatch-logs-export-configuration`

**Note**  
Une modification apportée à l’option `--cloudwatch-logs-export-configuration` est toujours appliquée immédiatement à l’instance de base de données. Par conséquent, les options `--apply-immediately` et `--no-apply-immediately` sont sans effet.

Vous pouvez également publier des journaux PostgreSQL en appelant les commandes de CLI suivantes :
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)

Exécutez l’une de ces commandes de CLI avec les options suivantes : 
+ `--db-instance-identifier`
+ `--enable-cloudwatch-logs-exports`
+ `--db-instance-class`
+ `--engine`

D’autres options peuvent être requises en fonction de la commande de CLI que vous exécutez.

**Example Modifier une instance pour publier des journaux dans CloudWatch Logs**  
L'exemple suivant modifie une instance de base de données PostgreSQL existante pour publier des fichiers journaux dans Logs. CloudWatch La valeur `--cloudwatch-logs-export-configuration` n’est pas un objet JSON. La clé pour cet objet est `EnableLogTypes` et sa valeur est un tableau de chaînes avec une combinaison quelconque de `postgresql` et `upgrade`.  
Pour Linux, macOS ou Unix :  

```
1. aws rds modify-db-instance \
2.     --db-instance-identifier mydbinstance \
3.     --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql", "upgrade"]}'
```
Pour Windows :  

```
1. aws rds modify-db-instance ^
2.     --db-instance-identifier mydbinstance ^
3.     --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql","upgrade"]}'
```

**Example Création d'une instance pour publier des journaux dans CloudWatch Logs**  
L'exemple suivant crée une instance de base de données PostgreSQL et publie des fichiers journaux dans Logs. CloudWatch La valeur `--enable-cloudwatch-logs-exports` est un tableau de chaînes JSON. Les chaînes peuvent être une combinaison quelconque de `postgresql` et `upgrade`.  
Pour Linux, macOS ou Unix :  

```
1. aws rds create-db-instance \
2.     --db-instance-identifier mydbinstance \
3.     --enable-cloudwatch-logs-exports '["postgresql","upgrade"]' \
4.     --db-instance-class db.m4.large \
5.     --engine postgres
```
Pour Windows :  

```
1. aws rds create-db-instance ^
2.     --db-instance-identifier mydbinstance ^
3.     --enable-cloudwatch-logs-exports '["postgresql","upgrade"]' ^
4.     --db-instance-class db.m4.large ^
5.     --engine postgres
```

### API RDS
<a name="USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs.API"></a>

Vous pouvez publier des journaux PostgreSQL avec l’API RDS. Vous pouvez appeler l’action [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) avec les paramètres suivants : 
+ `DBInstanceIdentifier`
+ `CloudwatchLogsExportConfiguration`

**Note**  
Une modification apportée au paramètre `CloudwatchLogsExportConfiguration` est toujours appliquée immédiatement à l’instance de base de données. Par conséquent, le paramètre `ApplyImmediately` est sans effet.

Vous pouvez également publier des journaux PostgreSQL en appelant les opérations d’API RDS suivantes : 
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html)

Exécutez l’une de ces opérations d’API RDS avec les paramètres suivants : 
+ `DBInstanceIdentifier`
+ `EnableCloudwatchLogsExports`
+ `Engine`
+ `DBInstanceClass`

D’autres paramètres peuvent être requis en fonction de l’opération que vous exécutez.

 

# Surveillance des appels d'API Amazon RDS dansAWS CloudTrail
<a name="logging-using-cloudtrail"></a>

AWS CloudTrail est un service AWS qui vous aide à auditer votre compte AWS. AWS CloudTrail est activé sur votre compte AWS lorsque vous le créez. Pour de plus amples informations sur CloudTrail, consultez le [AWS CloudTrailGuide de l’utilisateur ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).

**Topics**
+ [Intégration de CloudTrail à Amazon RDS](#service-name-info-in-cloudtrail)
+ [Entrées de fichier journal Amazon RDS](#understanding-service-name-entries)

## Intégration de CloudTrail à Amazon RDS
<a name="service-name-info-in-cloudtrail"></a>

Toutes les actions Amazon RDS sont journalisées par CloudTrail. CloudTrail fournit un registre des actions entreprises par un utilisateur, un rôle ou un service AWS dans Amazon Aurora.

### Événements CloudTrail
<a name="service-name-info-in-cloudtrail.events"></a>

CloudTrail capture tous les appels d'API pour Amazon Aurora en tant qu'événements. Un événement représente une demande individuelle émise à partir d’une source quelconque et comprend des informations sur l’action demandée, la date et l’heure de l’action, les paramètres de la demande, etc. Les événements incluent les appels de la console Amazon RDS et les appels de code aux opérations de l'API Amazon RDS. 

L'activité Amazon RDS est enregistrée dans un événement CloudTrail dans **Event history (Historique des événements)**. Vous pouvez utiliser la console CloudTrail pour afficher l'activité d'API et les événements enregistrés dans une région AWS au cours des 90 derniers jours. Pour de plus amples informations, veuillez consulter [Affichage des événements avec l'historique des événements CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html). 

### Journaux de suivi CloudTrail
<a name="service-name-info-in-cloudtrail.trails"></a>

Pour un enregistrement continu des événements dans votre compte AWS, y compris les événements pour Amazon RDS, créez un journal d'activité. Un journal d'activité est une configuration qui permet la livraison d'événements à un compartiment Amazon S3 spécifié. CloudTrail fournit généralement des fichiers journaux dans les 15 minutes suivant une activité du compte.

**Note**  
Si vous ne configurez pas de journal de suivi, vous pouvez toujours afficher les événements les plus récents dans la console CloudTrail dans **Event history** (Historique des événements).

Vous pouvez créer deux types de journaux d'activité pour un compte AWS : un journal d'activité qui s'applique à toutes les Régions ou un journal d'activité qui s'applique à une Région. Par défaut, lorsque vous créez un journal de suivi dans la console, il s’applique à toutes les régions . 

En outre, vous pouvez configurer d’autres services AWS pour analyser plus en profondeur les données d’événement collectées dans les journaux CloudTrail et agir sur celles-ci. Pour plus d’informations, consultez : 
+ [Présentation de la création d’un journal d’activité](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [Intégrations et services pris en charge par CloudTrail](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 journaux CloudTrail 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 journaux CloudTrail de plusieurs comptes](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)

## Entrées de fichier journal Amazon RDS
<a name="understanding-service-name-entries"></a>

Les fichiers journaux CloudTrail peuvent contenir une ou plusieurs entrées. Les fichiers journaux CloudTrail ne constituent pas une trace de pile ordonnée d'appels d'API publics. Ils ne suivent aucun ordre précis. 

L'exemple suivant montre une entrée de journal CloudTrail qui illustre l'action `CreateDBInstance`.

```
{
    "eventVersion": "1.04",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AKIAIOSFODNN7EXAMPLE",
        "arn": "arn:aws:iam::123456789012:user/johndoe",
        "accountId": "123456789012",
        "accessKeyId": "AKIAI44QH8DHBEXAMPLE",
        "userName": "johndoe"
    },
    "eventTime": "2018-07-30T22:14:06Z",
    "eventSource": "rds.amazonaws.com",
    "eventName": "CreateDBInstance",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "192.0.2.0",
    "userAgent": "aws-cli/1.15.42 Python/3.6.1 Darwin/17.7.0 botocore/1.10.42",
    "requestParameters": {
        "enableCloudwatchLogsExports": [
            "audit",
            "error",
            "general",
            "slowquery"
        ],
        "dBInstanceIdentifier": "test-instance",
        "engine": "mysql",
        "masterUsername": "myawsuser",
        "allocatedStorage": 20,
        "dBInstanceClass": "db.m1.small",
        "masterUserPassword": "****"
    },
    "responseElements": {
        "dBInstanceArn": "arn:aws:rds:us-east-1:123456789012:db:test-instance",
        "storageEncrypted": false,
        "preferredBackupWindow": "10:27-10:57",
        "preferredMaintenanceWindow": "sat:05:47-sat:06:17",
        "backupRetentionPeriod": 1,
        "allocatedStorage": 20,
        "storageType": "standard",
        "engineVersion": "8.0.28",
        "dbInstancePort": 0,
        "optionGroupMemberships": [
            {
                "status": "in-sync",
                "optionGroupName": "default:mysql-8-0"
            }
        ],
        "dBParameterGroups": [
            {
                "dBParameterGroupName": "default.mysql8.0",
                "parameterApplyStatus": "in-sync"
            }
        ],
        "monitoringInterval": 0,
        "dBInstanceClass": "db.m1.small",
        "readReplicaDBInstanceIdentifiers": [],
        "dBSubnetGroup": {
            "dBSubnetGroupName": "default",
            "dBSubnetGroupDescription": "default",
            "subnets": [
                {
                    "subnetAvailabilityZone": {"name": "us-east-1b"},
                    "subnetIdentifier": "subnet-cbfff283",
                    "subnetStatus": "Active"
                },
                {
                    "subnetAvailabilityZone": {"name": "us-east-1e"},
                    "subnetIdentifier": "subnet-d7c825e8",
                    "subnetStatus": "Active"
                },
                {
                    "subnetAvailabilityZone": {"name": "us-east-1f"},
                    "subnetIdentifier": "subnet-6746046b",
                    "subnetStatus": "Active"
                },
                {
                    "subnetAvailabilityZone": {"name": "us-east-1c"},
                    "subnetIdentifier": "subnet-bac383e0",
                    "subnetStatus": "Active"
                },
                {
                    "subnetAvailabilityZone": {"name": "us-east-1d"},
                    "subnetIdentifier": "subnet-42599426",
                    "subnetStatus": "Active"
                },
                {
                    "subnetAvailabilityZone": {"name": "us-east-1a"},
                    "subnetIdentifier": "subnet-da327bf6",
                    "subnetStatus": "Active"
                }
            ],
            "vpcId": "vpc-136a4c6a",
            "subnetGroupStatus": "Complete"
        },
        "masterUsername": "myawsuser",
        "multiAZ": false,
        "autoMinorVersionUpgrade": true,
        "engine": "mysql",
        "cACertificateIdentifier": "rds-ca-2015",
        "dbiResourceId": "db-ETDZIIXHEWY5N7GXVC4SH7H5IA",
        "dBSecurityGroups": [],
        "pendingModifiedValues": {
            "masterUserPassword": "****",
            "pendingCloudwatchLogsExports": {
                "logTypesToEnable": [
                    "audit",
                    "error",
                    "general",
                    "slowquery"
                ]
            }
        },
        "dBInstanceStatus": "creating",
        "publiclyAccessible": true,
        "domainMemberships": [],
        "copyTagsToSnapshot": false,
        "dBInstanceIdentifier": "test-instance",
        "licenseModel": "general-public-license",
        "iAMDatabaseAuthenticationEnabled": false,
        "performanceInsightsEnabled": false,
        "vpcSecurityGroups": [
            {
                "status": "active",
                "vpcSecurityGroupId": "sg-f839b688"
            }
        ]
    },
    "requestID": "daf2e3f5-96a3-4df7-a026-863f96db793e",
    "eventID": "797163d3-5726-441d-80a7-6eeb7464acd4",
    "eventType": "AwsApiCall",
    "recipientAccountId": "123456789012"
}
```

Comme indiqué dans l'élément `userIdentity` de l'exemple précédent, chaque événement ou entrée de journal contient des informations sur la personne qui a généré 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é effectuée par un autre service AWS.

Pour de plus amples informations sur `userIdentity`, veuillez consulter la section [Élément userIdentity CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html). Pour plus d'informations sur `CreateDBInstance` et d'autres actions Amazon RDS, veuillez consulter la [Référence d'API Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/).

# Surveillance d’Amazon RDS à l’aide des flux d’activité de base de données
<a name="DBActivityStreams"></a><a name="das"></a>

En utilisant les flux d’activité de base de données, vous pouvez surveiller en temps quasi réel les flux d’activité de base de données.

**Topics**
+ [Présentation des flux d’activité de base de données](#DBActivityStreams.Overview)
+ [Configuration d'un audit unifié pour Oracle Database](DBActivityStreams.configuring-auditing.md)
+ [Configuration de la politique d’audit pour Amazon RDS for Microsoft SQL Server](DBActivityStreams.configuring-auditing-SQLServer.md)
+ [Démarrage d’un flux d’activité de base de données](DBActivityStreams.Enabling.md)
+ [Modification d’un flux d’activité de base de données pour Amazon RDS](DBActivityStreams.Modifying.md)
+ [Obtention de l'état d'un flux d'activité de base de données](DBActivityStreams.Status.md)
+ [Arrêt d’un flux d’activité de base de données](DBActivityStreams.Disabling.md)
+ [Surveillance des flux d’activité de base de données](DBActivityStreams.Monitoring.md)
+ [Exemples de politique IAM pour les flux d’activité de base de données](DBActivityStreams.ManagingAccess.md)

## Présentation des flux d’activité de base de données
<a name="DBActivityStreams.Overview"></a>

En tant qu’administrateur de base de données Amazon RDS, vous devez protéger votre base de données et satisfaire aux exigences en matière de conformité et de réglementation. Une politique consiste à intégrer les flux d’activités de base de données avec vos outils de surveillance. De cette façon, vous surveillez l’activité d’audit dans votre base de données et définissez des alarmes.

Les menaces de sécurité sont à la fois externes et internes. Pour vous protéger contre des menaces internes, vous pouvez contrôler l’accès administrateur aux flux de données à l’aide de la fonction Database Activity Streams. Amazon RDS DBAs n'a pas accès à la collecte, à la transmission, au stockage et au traitement des flux.

**Contents**
+ [Fonctionnement des flux d’activité de base de données](#DBActivityStreams.Overview.how-they-work)
+ [Audit dans Oracle Database et la base de données Microsoft SQL Server](#DBActivityStreams.Overview.auditing)
  + [Audit unifié dans Oracle Database](#DBActivityStreams.Overview.unified-auditing)
  + [Audit dans Microsoft SQL Server](#DBActivityStreams.Overview.SQLServer-auditing)
  + [Champs d’audit non natifs pour Oracle Database et SQL Server](#DBActivityStreams.Overview.unified-auditing.non-native)
  + [Remplacement de groupe de paramètres de base de données](#DBActivityStreams.Overview.unified-auditing.parameter-group)
+ [Mode asynchrone pour les flux d'activité de base de données](#DBActivityStreams.Overview.sync-mode)
+ [Exigences et limites pour les flux d’activité de base de données](#DBActivityStreams.Overview.requirements)
+ [Disponibilité des régions et des versions](#DBActivityStreams.RegionVersionAvailability)
+ [Classes d’instance de base de données prises en charge pour les flux d’activité de base de données](#DBActivityStreams.Overview.requirements.classes)

### Fonctionnement des flux d’activité de base de données
<a name="DBActivityStreams.Overview.how-they-work"></a>

Amazon RDS envoie (push) les activités vers un flux de données Amazon Kinesis en temps quasi réel. Le flux Kinesis est créé automatiquement. Kinesis vous permet de configurer des AWS services tels qu'Amazon Data Firehose, de consommer le flux et AWS Lambda de stocker les données.

**Important**  
L’utilisation de la fonction de flux d’activité de base de données dans Amazon RDS est gratuite, mais Amazon Kinesis facture un flux de données. Pour plus d’informations, consultez la [Tarification d’Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/pricing/).

Vous pouvez configurer les applications de gestion de la conformité pour qu’elles consomment les flux d’activité des bases de données. Ces applications peuvent utiliser le flux pour générer des alertes et auditer l’activité sur votre base de données.

Amazon RDS prend en charge les flux d’activité des bases de données dans les déploiements multi-AZ. Dans ce cas, les flux d’activité de la base de données vérifient à la fois les instances principales et les instances en veille.

### Audit dans Oracle Database et la base de données Microsoft SQL Server
<a name="DBActivityStreams.Overview.auditing"></a>

L’audit est la surveillance et l’enregistrement d’actions de base de données configurées. Amazon RDS ne capture aucune activité de base de données par défaut. Vous créez et gérez vous-même les politiques d’audit dans votre base de données.

**Topics**
+ [Audit unifié dans Oracle Database](#DBActivityStreams.Overview.unified-auditing)
+ [Audit dans Microsoft SQL Server](#DBActivityStreams.Overview.SQLServer-auditing)
+ [Champs d’audit non natifs pour Oracle Database et SQL Server](#DBActivityStreams.Overview.unified-auditing.non-native)
+ [Remplacement de groupe de paramètres de base de données](#DBActivityStreams.Overview.unified-auditing.parameter-group)

#### Audit unifié dans Oracle Database
<a name="DBActivityStreams.Overview.unified-auditing"></a>

Dans une base de données Oracle, une *politique d’audit unifié* est un groupe nommé de paramètres d’audit que vous pouvez utiliser pour auditer un aspect du comportement utilisateur. Une politique peut être aussi simple que l’audit des activités d’un seul utilisateur. Vous pouvez également créer des politiques d’audit complexes qui utilisent des conditions.

Une base de données Oracle écrit des enregistrements d’audit, dont des enregistrements d’audit `SYS`, dans la *trace d’audit unifié*. Par exemple, si une erreur survient pendant une instruction `INSERT`, un audit standard indique le numéro d’erreur et le code SQL qui a été exécuté. La trace d’audit se trouve dans une table en lecture seule dans le schéma `AUDSYS`. Pour accéder à ces enregistrements, interrogez la vue du dictionnaire de données `UNIFIED_AUDIT_TRAIL`.

Généralement, vous configurez les flux d’activité de base de données comme suit :

1. Créez une politique d’audit Oracle Database à l’aide de la commande `CREATE AUDIT POLICY`.

   Oracle Database génère des enregistrements d’audit.

1. Activez la politique d’audit à l’aide de la commande `AUDIT POLICY`.

1. Configurer les flux d’activité de base de données.

   Seules les activités qui correspondent aux politiques d’audit d’Oracle Database sont capturées et envoyées au flux de données Amazon Kinesis. Lorsque les flux d’activité de base de données sont activés, un administrateur de base de données Oracle ne peut pas modifier la politique d’audit ou supprimer des journaux d’audit.

Pour en savoir plus sur les politiques d’audit unifié, consultez [About Auditing Activities with Unified Audit Policies and AUDIT](https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/configuring-audit-policies.html#GUID-2435D929-10AD-43C7-8A6C-5133170074D0) dans *Oracle Database Security Guide*.

#### Audit dans Microsoft SQL Server
<a name="DBActivityStreams.Overview.SQLServer-auditing"></a>

Database Activity Stream utilise SQLAudit une fonctionnalité pour auditer la base de données SQL Server.

L’instance RDS for SQL Server contient les éléments suivants :
+ Audit de serveur : l’audit SQL Server collecte une instance unique d’actions au niveau du serveur ou de la base de données, ainsi qu’un groupe d’actions à surveiller. Les audits au niveau du serveur `RDS_DAS_AUDIT` et `RDS_DAS_AUDIT_CHANGES` sont gérés par RDS.
+ Spécification d’audit de serveur : la spécification d’audit de serveur enregistre les événements au niveau du serveur. Vous pouvez modifier la spécification `RDS_DAS_SERVER_AUDIT_SPEC`. Cette spécification est liée à l’audit du serveur `RDS_DAS_AUDIT`. La spécification `RDS_DAS_CHANGES_AUDIT_SPEC` est gérée par RDS.
+ Spécification d’audit de base de données : la spécification d’audit de base de données enregistre les événements au niveau du serveur. Vous pouvez créer une spécification d’audit de base de données `RDS_DAS_DB_<name>` et la lier à l’audit de serveur `RDS_DAS_AUDIT`.

Vous pouvez configurer les flux d’activité de base de données à l’aide de la console ou de l’interface de ligne de commande. Généralement, vous configurez les flux d’activité de base de données comme suit :

1. (Facultatif) Créez une spécification d’audit de base de données à l’aide de la commande `CREATE DATABASE AUDIT SPECIFICATION` et associez-la à l’audit de serveur `RDS_DAS_AUDIT`. 

1. (Facultatif) Modifiez la spécification d’audit de serveur à l’aide de la commande `ALTER SERVER AUDIT SPECIFICATION` et définissez les politiques. 

1. Activez les politiques d’audit de base de données et de serveur. Par exemple :

   `ALTER DATABASE AUDIT SPECIFICATION [<Your database specification>] WITH (STATE=ON)`

   `ALTER SERVER AUDIT SPECIFICATION [RDS_DAS_SERVER_AUDIT_SPEC] WITH (STATE=ON)`

1. Configurer les flux d’activité de base de données.

   Seules les activités qui correspondent aux politiques d’audit de serveur et de base de données sont capturées et envoyées au flux de données Amazon Kinesis. Quand les flux d’activité de base de données sont activés et que les politiques sont verrouillées, un administrateur de base de données ne peut pas modifier la politique d’audit ni supprimer des journaux d’audit. 
**Important**  
Si la spécification d’audit de base de données pour une base de données spécifique est activée et que la politique est à l’état verrouillé, la base de données ne peut pas être supprimée.

Pour plus d’informations sur l’audit SQL Server, consultez [Composants d’audit SQL Server](https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine?view=sql-server-ver16) dans la *documentation sur Microsoft SQL Server*.



#### Champs d’audit non natifs pour Oracle Database et SQL Server
<a name="DBActivityStreams.Overview.unified-auditing.non-native"></a>

Lorsque vous démarrez un flux d’activité de base de données, chaque événement de base de données génère un événement de flux d’activité correspondant. Par exemple, un utilisateur de base de données peut exécuter des instructions `SELECT` et `INSERT`. La base de données audite ces événements et les envoie à un flux de données Amazon Kinesis Data Stream.

Les événements sont représentés dans le flux comme des objets JSON. Un objet JSON contient un `DatabaseActivityMonitoringRecord`, qui contient un tableau `databaseActivityEventList`. Les champs prédéfinis dans le tableau sont `class`, `clientApplication` et `command`.

Par défaut, un flux d’activité n’inclut pas de champs d’audit natifs du moteur. Vous pouvez configurer Amazon RDS for Oracle et SQL Server de sorte qu’il inclue ces champs supplémentaires dans l’objet JSON `engineNativeAuditFields`.

Dans Oracle Database, la plupart des événements dans la trace d’audit unifié sont mappés à des champs dans le flux d’activité de données RDS. Par exemple, le champ `UNIFIED_AUDIT_TRAIL.SQL_TEXT` dans un audit mappe au champ `commandText` dans un flux d’activité de base de données. Toutefois, des champs d’audit d’Oracle Database tels que `OS_USERNAME` ne mappent pas à des champs prédéfinis dans un flux d’activité de base de données.

Dans SQL Server, la plupart des champs de l'événement enregistrés par le système SQLAudit correspondent aux champs du flux d'activité de la base de données RDS. Par exemple, le champ `code` issu de `sys.fn_get_audit_file` dans l’audit est mappé sur le champ `commandText` dans un flux d’activité de base de données. Toutefois, les champs d’audit de base de données SQL Server, tels que `permission_bitmask`, ne sont pas mappés sur les champs prédéfinis dans un flux d’activité de base de données.

Pour plus d'informations sur databaseActivityEvent List, consultez[Tableau JSON databaseActivityEventList pour les flux d’activité de base de données](DBActivityStreams.AuditLog.databaseActivityEventList.md).

#### Remplacement de groupe de paramètres de base de données
<a name="DBActivityStreams.Overview.unified-auditing.parameter-group"></a>

En règle générale, vous activez l’audit unifié dans RDS for Oracle en attachant un groupe de paramètres. Toutefois, les flux d’activité de base de données nécessitent une configuration supplémentaire. Pour améliorer votre expérience client, Amazon RDS procède comme suit :
+ Si vous activez un flux d’activité, RDS for Oracle ignore les paramètres d’audit dans le groupe de paramètres.
+ Si vous désactivez un flux d’activité, RDS for Oracle cesse d’ignorer les paramètres d’audit.

Le flux d’activité de base de données pour SQL Server est indépendant des paramètres que vous définissez dans l’option d’audit SQL.

### Mode asynchrone pour les flux d'activité de base de données
<a name="DBActivityStreams.Overview.sync-mode"></a>

Les flux d’activité dans Amazon RDS sont toujours asynchrones. Quand une session de base de données génère un événement de flux d’activité, la session revient immédiatement aux activités normales. En arrière-plan, Amazon RDS transforme l’événement de flux d’activité en un enregistrement durable.

Si une erreur se produit dans la tâche en arrière-plan, Amazon RDS génère un événement. Cet événement indique le début et la fin de toute fenêtre de temps au cours de laquelle des enregistrements d’événement de flux d’activité ont pu être perdus. Le mode asynchrone favorise les performances de la base de données plutôt que la précision du flux d’activité.

### Exigences et limites pour les flux d’activité de base de données
<a name="DBActivityStreams.Overview.requirements"></a>

Dans RDS, les flux d’activité de base de données présentent les limites et les exigences suivantes :
+ Amazon Kinesis est nécessaire pour les flux d’activité des bases de données.
+ AWS Key Management Service (AWS KMS) est obligatoire pour les flux d'activité de base de données car ils sont toujours chiffrés.
+ L'application d'un chiffrement supplémentaire à votre flux de données Amazon Kinesis est incompatible avec les flux d'activité de base de données, qui sont déjà chiffrés avec votre AWS KMS clé.
+ Vous créez et gérez vous-même les politiques d’audit. Contrairement à Amazon Aurora, RDS for Oracle ne capture aucune activité de base de données par défaut.
+ Vous créez et gérez vous-même les politiques d’audit ou les spécifications. Contrairement à Amazon Aurora, Amazon RDS ne capture aucune activité de base de données par défaut.
+ Dans un déploiement multi-AZ, démarrez le flux d’activité de base de données uniquement sur l’instance de base de données principale. Le flux d’activité vérifie automatiquement les instances de base de données principales et en veille. Aucune étape supplémentaire n’est requise lors d’un basculement.
+ Le fait de renommer une instance de base de données ne crée pas un nouveau flux Kinesis.
+ CDBs ne sont pas pris en charge par RDS pour Oracle.
+ Les réplicas en lecture ne sont pas pris en charge.

### Disponibilité des régions et des versions
<a name="DBActivityStreams.RegionVersionAvailability"></a>

La disponibilité et la prise en charge des fonctionnalités varient selon les versions spécifiques de chaque moteur de base de données, et selon les Régions AWS. Pour obtenir plus d’informations sur la disponibilité des versions et des régions avec les flux d’activité des bases de données, consultez [Régions et moteurs de base de données pris en charge pour les flux d’activité des bases de données dans Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.DBActivityStreams.md).

### Classes d’instance de base de données prises en charge pour les flux d’activité de base de données
<a name="DBActivityStreams.Overview.requirements.classes"></a>

Pour RDS for Oracle, vous pouvez utiliser des flux d’activité de base de données avec les classes d’instance de base de données suivantes :
+ db.m4.\$1large
+ db.m5.\$1large
+ db.m5d.\$1large
+ db.m6i.\$1large
+ db.r4.\$1large
+ db.r5.\$1large
+ db.r5.\$1large.tpc\$1.mem\$1x
+ db.r5b.\$1large
+ db.r5b.\$1large.tpc\$1.mem\$1x
+ db.r5d.\$1large
+ db.r6i.\$1large
+ db.r6i.\$1large.tpc\$1.mem\$1x
+ db.x2idn.\$1large
+ db.x2iedn.\$1large
+ db.x2iezn.\$1large
+ db.z1d.\$1large

Pour RDS for SQL Server, vous pouvez utiliser des flux d’activité de base de données avec les classes d’instance de base de données suivantes :
+ db.m4.\$1large
+ db.m5.\$1large
+ db.m5d.\$1large
+ db.m6i.\$1large
+ db.r4.\$1large
+ db.r5.\$1large
+ db.r5b.\$1large
+ db.r5d.\$1large
+ db.r6i.\$1large
+ db.x1e.\$1large
+ db.x2iedn.\$1large
+ db.z1d.\$1large

Pour plus d’informations sur les types de classes d’instance , consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).

# Configuration d'un audit unifié pour Oracle Database
<a name="DBActivityStreams.configuring-auditing"></a>

Lorsque vous configurez un audit unifié pour une utilisation avec des flux d'activité de base de données, les situations suivantes peuvent se présenter :
+ L'audit unifié est configuré pour votre base de données Oracle

  Dans ce cas, créez de nouvelles politiques avec la commande `CREATE AUDIT POLICY`, puis activez-les avec la commande `AUDIT POLICY`. L'exemple suivant crée et active une politique pour surveiller les utilisateurs disposant de privilèges et de rôles spécifiques.

  ```
  CREATE AUDIT POLICY table_pol
  PRIVILEGES CREATE ANY TABLE, DROP ANY TABLE
  ROLES emp_admin, sales_admin;
  
  AUDIT POLICY table_pol;
  ```

  Pour obtenir des instructions complètes, consultez [Configuring Audit Policies](https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/configuring-audit-policies.html#GUID-22CDB667-5AA2-4051-A262-FBD0236763CB) dans la documentation Oracle Database.
+ L'audit unifié est configuré pour votre base de données Oracle

  Lorsque vous activez un flux d'activité de base de données, RDS pour Oracle efface automatiquement les données d'audit existantes. Il révoque également les privilèges de trace d'audit. RDS for Oracle ne peut plus effectuer les opérations suivantes :
  + Purger les enregistrements de journal d'activité d'audit unifié.
  + Ajouter, supprimer ou modifier la politique d'audit unifié.
  + Mettre à jour le dernier horodatage archivé.
**Important**  
Nous vous recommandons fortement de sauvegarder vos données d'audit avant d'activer un flux d'activité de base de données.

  Pour obtenir une description de la vue `UNIFIED_AUDIT_TRAIL`, consultez [UNIFIED\$1AUDIT\$1TRAIL](https://docs.oracle.com/database/121/REFRN/GUID-B7CE1C02-2FD4-47D6-80AA-CF74A60CDD1D.htm#REFRN29162). Si vous possédez un compte auprès d'Oracle Support, consultez [How To Purge The UNIFIED AUDIT TRAIL](https://support.oracle.com/knowledge/Oracle%20Database%20Products/1582627_1.html).

# Configuration de la politique d’audit pour Amazon RDS for Microsoft SQL Server
<a name="DBActivityStreams.configuring-auditing-SQLServer"></a>

Une instance de base de données SQL Server comporte l’audit de serveur `RDS_DAS_AUDIT`, qui est géré par Amazon RDS. Vous pouvez définir les politiques d’enregistrement des événements de serveur dans la spécification d’audit de serveur `RDS_DAS_SERVER_AUDIT_SPEC`. Vous pouvez créer une spécification d’audit de base de données, telle que `RDS_DAS_DB_<name>`, et définir les politiques d’enregistrement des événements de base de données. Pour obtenir la liste des groupes d’actions d’audit au niveau du serveur et de la base de données, consultez [Actions et groupes d’actions d’audit SQL Server](https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-action-groups-and-actions) dans la *documentation sur Microsoft SQL Server*.

La politique de serveur par défaut surveille uniquement les échecs de connexion et les modifications apportées aux spécifications d’audit de base de données ou de serveur pour les flux d’activité de base de données.

Les limites de l’audit et des spécifications d’audit sont les suivantes :
+ Vous ne pouvez pas modifier les spécifications d’audit de serveur ou de base de données lorsque le flux d’activité de base de données est à l’état *verrouillé*.
+ Vous ne pouvez pas modifier la spécification `RDS_DAS_AUDIT` d’audit de serveur.
+ Vous ne pouvez pas modifier l’audit SQL Server `RDS_DAS_CHANGES` ni sa spécification d’audit de serveur associée `RDS_DAS_CHANGES_AUDIT_SPEC`.
+ Lors de la création d’une spécification d’audit de base de données, vous devez utiliser le format `RDS_DAS_DB_<name>`, par exemple `RDS_DAS_DB_databaseActions`.

**Important**  
Pour les classes d’instance plus petites, nous vous recommandons de ne pas auditer toutes les données, mais seulement les données requises. Cela permet de réduire l’impact des flux d’activité de base de données sur les performances de ces classes d’instance.

L’exemple de code suivant modifie la spécification d’audit de serveur `RDS_DAS_SERVER_AUDIT_SPEC` et audite toute déconnexion et toute action de connexion réussie :

```
ALTER SERVER AUDIT SPECIFICATION [RDS_DAS_SERVER_AUDIT_SPEC]
      WITH (STATE=OFF);
ALTER SERVER AUDIT SPECIFICATION [RDS_DAS_SERVER_AUDIT_SPEC]
      ADD (LOGOUT_GROUP),
      ADD (SUCCESSFUL_LOGIN_GROUP)
      WITH (STATE = ON );
```

L’exemple de code suivant crée une spécification d’audit de base de données `RDS_DAS_DB_database_spec` et l’attache à l’audit de serveur `RDS_DAS_AUDIT` :

```
USE testDB;
CREATE DATABASE AUDIT SPECIFICATION [RDS_DAS_DB_database_spec]
     FOR SERVER AUDIT [RDS_DAS_AUDIT]
     ADD ( INSERT, UPDATE, DELETE  
          ON testTable BY testUser )  
     WITH (STATE = ON);
```

Une fois les spécifications d’audit configurées, veillez à ce que les spécifications `RDS_DAS_SERVER_AUDIT_SPEC` et `RDS_DAS_DB_<name>` soient définies sur l’état `ON`. Elles peuvent désormais envoyer les données d’audit à votre flux d’activité de base de données.

# Démarrage d’un flux d’activité de base de données
<a name="DBActivityStreams.Enabling"></a>

Lorsque vous démarrez un flux d'activité pour l'instance de base de données, chaque événement d'activité de base de données que vous avez configuré dans la politique d'audit génère un événement de flux d'activité. Des commandes SQL telles que `CONNECT` et `SELECT` génèrent des événements d’accès. Des commandes SQL telles que `CREATE` et `INSERT` génèrent des événements de modification.

**Important**  
L'activation d'un flux d'activité pour une instance de base de données Oracle efface les données d'audit existantes. Il révoque également les privilèges de trace d'audit. Quand le flux est activé, RDS for Oracle ne peut plus effectuer les opérations suivantes :  
Purger les enregistrements de journal d’activité d’audit unifié.
Ajouter, supprimer ou modifier la politique d'audit unifié.
Mettre à jour le dernier horodatage archivé.

------
#### [ Console ]

**Pour démarrer un flux d’activité de base de données**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans la panneau de navigation, choisissez **Bases de données**.

1. Choisissez l'instance de base de données Amazon RDS sur laquelle vous souhaitez démarrer un flux d'activité. Dans un déploiement Multi-AZ, démarrez le flux uniquement sur l’instance principale. Le flux d'activité vérifie à la fois l'instance principale et l'instance en veille.

1. Pour **Actions**, choisissez **Start activity stream** (Démarrer le flux d’activité). 

   La fenêtre **Démarrer un flux d'activité de base de données : ***nom* s'affiche, où *nom* est votre instance RDS.

1. Définissez les paramètres suivants :
   + Pour une **AWS KMS key**, choisissez une clé dans la liste des AWS KMS keys.

     Amazon RDS utilise la clé KMS pour chiffrer la clé qui va à son tour chiffrer l'activité de base de données. Choisissez une clé KMS différente de la clé par défaut. Pour plus d’informations sur les clés de chiffrement et AWS KMS, consultez [Présentation d’AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) dans le *Manuel du développeur AWS Key Management Service*.
   + Pour **Événements d'activité de base de données**, choisissez **Activer les champs d'audit natifs au moteur** pour inclure les champs d'audit spécifiques du moteur.
   + Choisissez **Immédiatement**.

     Lorsque vous choisissez **Immédiatement**, le instance RDSredémarre tout de suite. Si vous choisissez **Pendant la prochaine fenêtre de maintenance**, le instance RDS ne redémarre pas tout de suite. Dans ce cas, le flux d’activité de base de données ne démarre pas avant la prochaine fenêtre de maintenance.

1. Choisissez **Démarrer le flux d’activité de base de données**.

   Le statut pour la base de données indique que le flux d'activité démarre.
**Note**  
Si l’erreur `You can't start a database activity stream in this configuration` s’affiche, vérifiez [Classes d’instance de base de données prises en charge pour les flux d’activité de base de données](DBActivityStreams.md#DBActivityStreams.Overview.requirements.classes) pour voir si votre instance RDS utilise une classe d’instance prise en charge.

------
#### [ AWS CLI ]

Pour démarrer des flux d'activité de base de données pour une instance de base de données, configurez la base de données à l'aide de la commande AWS CLI [start-activity-stream](https://docs.aws.amazon.com/cli/latest/reference/rds/start-activity-stream.html).
+ `--resource-arn arn` – Spécifie l’Amazon Resource Name (ARN) du instance de base de données.
+ `--kms-key-id key` – Spécifie l’identifiant de clé KMS pour le chiffrement des messages dans le flux d’activité de base de données. L’identifiant de clé KMS AWS est l’ARN de clé, l’ID de clé, l’ARN d’alias ou le nom d’alias pour la AWS KMS key.
+ `--engine-native-audit-fields-included` – Inclut des champs d'audit spécifiques du moteur dans le flux de données. Pour exclure ces champs, spécifiez `--no-engine-native-audit-fields-included` (par défaut).

L’exemple suivant démarre un flux d’activité de base de données pour une instance de base de données en mode asynchrone.

Pour Linux, macOS ou Unix :

```
aws rds start-activity-stream \
    --mode async \
    --kms-key-id my-kms-key-arn \
    --resource-arn my-instance-arn \
    --engine-native-audit-fields-included \
    --apply-immediately
```

Pour Windows :

```
aws rds start-activity-stream ^
    --mode async ^
    --kms-key-id my-kms-key-arn ^
    --resource-arn my-instance-arn ^
    --engine-native-audit-fields-included ^
    --apply-immediately
```

------
#### [ Amazon RDS API ]

Pour démarrer des flux d’activité de base de données pour un instance de base de données, configurez l’instance à l’aide de l’opération [StartActivityStream](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StartActivityStream.html).

Appelez l’action avec les paramètres ci-dessous :
+ `Region`
+ `KmsKeyId`
+ `ResourceArn`
+ `Mode`
+ `EngineNativeAuditFieldsIncluded`

------

# Modification d’un flux d’activité de base de données pour Amazon RDS
<a name="DBActivityStreams.Modifying"></a>

Vous voudrez peut-être personnaliser votre politique d’audit Amazon RDS lors du lancement de votre flux d’activité. Si vous ne voulez pas perdre de temps et de données en arrêtant votre flux d’activité, vous pouvez modifier *l’état de la politique d’audit* en choisissant l’un des paramètres suivants :

**Locked (default)** [Verrouillé (par défaut)]  
Les politiques d'audit de votre base de données sont en lecture seule.

**Unlocked** (Débloqué)  
Les politiques d'audit de votre base de données sont en lecture/écriture.

La procédure de base est la suivante :

1. Modifiez l'état de la politique d'audit pour qu'elle soit déverrouillée.

1. Personnalisez votre politique d'audit.

1. Modifier l'état de la politique d'audit pour qu'elle soit verrouillée.

## Console
<a name="DBActivityStreams.Modifying-collapsible-section-E1"></a>

**Pour modifier l'état de la politique d'audit de votre flux d'activité**

1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans la panneau de navigation, choisissez **Bases de données**.

1. Pour **Actions**, sélectionnez **Modify database activity stream** (Modifier le flux d'activité de la base de données). 

   La fenêtre **Modify database activity stream: *name*** (Modifier le flux d'activité de la base de données : nom) apparaît, où la valeur *name* (nom) est votre instance RDS.

1. Choisissez l’une des options suivantes :  
**Locked** (Verrouillée)  
Lorsque vous verrouillez votre politique d'audit, elle passe en lecture seule. Vous ne pouvez pas modifier votre politique d'audit à moins de déverrouiller la politique ou d'arrêter le flux d'activité.  
**Unlocked** (Débloqué)  
Lorsque vous déverrouillez votre politique d'audit, elle passe en lecture/écriture. Vous pouvez modifier votre politique d'audit pendant que le flux d'activité est lancé.

1. Sélectionnez **Modify DB activity stream** (Modifier le flux d’activité de la base de données).

   Le statut de la base de données Amazon RDS montre **Configuration du flux d'activité**.

1. (Facultatif) Choisissez le lien de l’instance de base de données. Choisissez ensuite l’onglet **Configuration**.

   Le champ **Audit policy status** (Statut de la politique d'audit) affiche l'une des valeurs suivantes :
   + **Locked** (Verrouillée)
   + **Unlocked** (Débloqué)
   + **Locking policy** (Politique de verrouillage)
   + **Unlocking policy** (Politique de déverrouillage)

## AWS CLI
<a name="DBActivityStreams.Modifying-collapsible-section-E2"></a>

Pour modifier l'état du flux d'activité de l'instance de base de données, utilisez la commande AWS CLI [modify-activity-stream](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-activity-stream.html).


****  

| Option | Obligatoire ? | Description | 
| --- | --- | --- | 
|  `--resource-arn my-instance-ARN`  |  Oui  |  L'Amazon Resource Name (ARN) de votre instance de base de données RDS.  | 
|  `--audit-policy-state`  |  Non  |  Le nouvel état de la politique d'audit pour le flux d'activité de la base de données sur votre instance : `locked` ou `unlocked`.  | 

L’exemple suivant déverrouille la politique d’audit pour le flux d’activité démarré sur *my-instance-ARN*.

Pour Linux, macOS ou Unix :

```
aws rds modify-activity-stream \
    --resource-arn my-instance-ARN \
    --audit-policy-state unlocked
```

Pour Windows :

```
aws rds modify-activity-stream ^
    --resource-arn my-instance-ARN ^
    --audit-policy-state unlocked
```

L’exemple suivant décrit l’instance *my-instance*. L'exemple de sortie partielle montre que la politique d'audit est déverrouillée.

```
aws rds describe-db-instances --db-instance-identifier my-instance

{
    "DBInstances": [
        {
            ...
            "Engine": "oracle-ee",
            ...
            "ActivityStreamStatus": "started",
            "ActivityStreamKmsKeyId": "ab12345e-1111-2bc3-12a3-ab1cd12345e",
            "ActivityStreamKinesisStreamName": "aws-rds-das-db-AB1CDEFG23GHIJK4LMNOPQRST",
            "ActivityStreamMode": "async",
            "ActivityStreamEngineNativeAuditFieldsIncluded": true, 
            "ActivityStreamPolicyStatus": "unlocked",
            ...
        }
    ]
}
```

## API RDS
<a name="DBActivityStreams.Modifying-collapsible-section-E3"></a>

Pour modifier l'état de la politique du flux d'activité de votre base de données, utilisez l'opération [ModifyActivityStream](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyActivityStream.html).

Appelez l’action avec les paramètres ci-dessous :
+ `AuditPolicyState`
+ `ResourceArn`

# Obtention de l'état d'un flux d'activité de base de données
<a name="DBActivityStreams.Status"></a>

Vous pouvez obtenir le statut d'un flux d'activité pour votre instance de base de données Amazon RDS en utilisant la console ou AWS CLI.

## console
<a name="DBActivityStreams.Status-collapsible-section-S1"></a>

**Obtention de l'état d'un flux d'activité de base de données**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans le panneau de navigation, choisissez **Bases de données**, puis le lien du instance de base de données.

1. Choisissez l'onglet **Configuration** et cochez l'option **Flux d'activité de base de données** pour obtenir l'état.

## AWS CLI
<a name="DBActivityStreams.Status-collapsible-section-S2"></a>

Vous pouvez obtenir la configuration du flux d'activité pour une instance de base de données en réponse à une demande CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html).

L'exemple suivant décrit *my-instance*.

```
aws rds --region my-region describe-db-instances --db-instance-identifier my-db
```

Voici un exemple de réponse JSON. Les champs suivants s'affichent :
+ `ActivityStreamKinesisStreamName`
+ `ActivityStreamKmsKeyId`
+ `ActivityStreamStatus`
+ `ActivityStreamMode`
+ `ActivityStreamPolicyStatus`



```
{
    "DBInstances": [
        {
            ...
            "Engine": "oracle-ee",
            ...
            "ActivityStreamStatus": "starting",
            "ActivityStreamKmsKeyId": "ab12345e-1111-2bc3-12a3-ab1cd12345e",
            "ActivityStreamKinesisStreamName": "aws-rds-das-db-AB1CDEFG23GHIJK4LMNOPQRST",
            "ActivityStreamMode": "async",
            "ActivityStreamEngineNativeAuditFieldsIncluded": true, 
            "ActivityStreamPolicyStatus": locked",
            ...
        }
    ]
}
```

## API RDS
<a name="DBActivityStreams.Status-collapsible-section-S3"></a>

Vous pouvez obtenir la configuration du flux d'activité pour une base de données en réponse à une opération [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html).

# Arrêt d’un flux d’activité de base de données
<a name="DBActivityStreams.Disabling"></a>

Vous pouvez arrêter un flux d’activité à partir de la console ou d’AWS CLI.

Si vous supprimez votre instance de base de données Amazon RDS, le flux d'activité est arrêté et le flux Amazon Kinesis sous-jacent est supprimé automatiquement.

## Console
<a name="DBActivityStreams.Disabling-collapsible-section-D1"></a>

**Pour désactiver un flux d’activité**

1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**.

1. Choisissez une base de données pour lequel vous souhaitez arrêter le flux d'activité de base de données.

1. Pour **Actions**, choisissez **Stop activity stream** (Arrêter le flux d’activité). La fenêtre **Database Activity Stream** (Flux d’activité de base de données) apparaît.

   1. Choisissez **Immédiatement**.

      Lorsque vous choisissez **Immédiatement**, le instance RDSredémarre tout de suite. Si vous choisissez **Pendant la prochaine fenêtre de maintenance**, le instance RDS ne redémarre pas tout de suite. Dans ce cas, le flux d'activité de base de données ne s'arrête pas avant la prochaine fenêtre de maintenance.

   1. Choisissez **Continuer**.

## AWS CLI
<a name="DBActivityStreams.Disabling-collapsible-section-D2"></a>

Pour arrêter les flux d'activité de base de données pour votre base de données, configurez le instance de base de données à l'aide de la commande AWS CLI [stop-activity-stream](https://docs.aws.amazon.com/cli/latest/reference/rds/stop-activity-stream.html). Identifiez la région AWS pour le instance de base de données avec le paramètre `--region`. Le paramètre `--apply-immediately` est facultatif.

Pour Linux, macOS ou Unix :

```
aws rds --region MY_REGION \
    stop-activity-stream \
    --resource-arn MY_DB_ARN \
    --apply-immediately
```

Pour Windows :

```
aws rds --region MY_REGION ^
    stop-activity-stream ^
    --resource-arn MY_DB_ARN ^
    --apply-immediately
```

## API RDS
<a name="DBActivityStreams.Disabling-collapsible-section-D3"></a>

Pour arrêter les flux d’activité de base de données pour base de données, configurez ce cette instance de base de données à l’aide de l’opération [StopActivityStream](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StopActivityStream.html). Identifiez la région AWS pour le instance de base de données avec le paramètre `Region`. Le paramètre `ApplyImmediately` est facultatif.

# Surveillance des flux d’activité de base de données
<a name="DBActivityStreams.Monitoring"></a>

Les flux d’activité de base de données surveillent et rapportent les activités. Le flux d'activité est collecté et transmis à Amazon Kinesis. Depuis Kinesis, vous pouvez surveiller le flux d'activité ou d'autres services et applications peuvent utiliser le flux d'activité pour une analyse plus approfondie. Vous pouvez trouver le nom du flux Kinesis sous-jacent à l’aide de la commande `describe-db-instances` de AWS CLI ou de l’opération `DescribeDBInstances` de l’API RDS.

Amazon RDS gère le flux Kinesis pour vous comme suit :
+ Amazon RDS crée automatiquement le flux Kinesis avec une période de rétention de 24 heures. 
+  Amazon RDS met à l'échelle le flux Kinesis si nécessaire. 
+  Si vous arrêtez le flux d’activité de base de données ou supprimez l’instance de base de données, Amazon RDS supprime le flux Kinesis. 

Les catégories d'activité suivantes sont surveillées et incluses dans le journal d'audit de flux d'activité :
+ **Commandes SQL** – Toutes les commandes SQL sont auditées, ainsi que les instructions préparées, les fonctions intégrées et les fonctions en PL/SQL. Les appels aux procédures stockées sont vérifiés. Toutes les instructions SQL émises dans des procédures ou fonctions stockées sont également vérifiées.
+ **Autres informations de bases de données** – L'activité surveillée inclut l'instruction SQL complète, le nombre des lignes affectées par les commandes DML, les objets consultés et le nom unique de base de données. Les flux d'activité de base de données surveillent également les variables de liaison et les paramètres de procédure stockée. 
**Important**  
Le texte SQL complet de chaque instruction est visible dans le journal d'audit du flux d'activité, y compris les données sensibles. Cependant, les mots de passe des utilisateurs de base de données sont expurgés si Oracle peut les déterminer d'après le contexte, comme dans l'instruction SQL suivante.   

  ```
  ALTER ROLE role-name WITH password
  ```
+ **Informations de connexion** – L'activité surveillée inclut les informations de session et de réseau, l'ID de processus serveur et les codes de sortie.

Si un flux d’activité rencontre un échec pendant la surveillance de votre instance de base de données, vous en êtes informé via des événements RDS.

Les sections ci-après vous permettent d’accéder aux flux d’activité des bases de données, de les auditer et de les traiter.

**Topics**
+ [Accès à un flux d’activité depuis Amazon Kinesis](DBActivityStreams.KinesisAccess.md)
+ [Contenu du journal d’audit et exemples pour les flux d’activité de base de données](DBActivityStreams.AuditLog.md)
+ [Tableau JSON databaseActivityEventList pour les flux d’activité de base de données](DBActivityStreams.AuditLog.databaseActivityEventList.md)
+ [Traitement d’un flux d’activité de base de données à l’aide du kit AWS SDK](DBActivityStreams.CodeExample.md)

# Accès à un flux d’activité depuis Amazon Kinesis
<a name="DBActivityStreams.KinesisAccess"></a>

Lorsque vous activez un flux d’activité pour une base de données, un flux Kinesis est créé pour vous. Depuis Kinesis, vous pouvez surveiller l'activité de votre base de données en temps réel. Pour effectuer des analyses plus poussées de l'activité de base de données, vous pouvez connecter votre flux Kinesis à des applications grand public. Vous pouvez également connecter le flux à des applications de gestion de la conformité telles que Security Guardium d’IBM ou SecureSphere Database Audit and Protection d’Imperva.

Vous pouvez accéder à votre flux Kinesis à partir de la console RDS ou de la console Kinesis.

**Pour accéder à un flux d'activité depuis Kinesis avec la console RDS**

1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Dans la panneau de navigation, choisissez **Bases de données**.

1. Choisissez l'instance de base de données Amazon RDS où vous souhaitez démarrer un flux d'activité.

1. Choisissez **Configuration**.

1. Sous **Database activity stream** (Flux d'activité de la base de données), choisissez le lien sous **Kinesis stream** (Flux Kinesis).

1. Dans la console Kinesis, choisissez **Monitoring** (Surveillance) pour commencer à observer l'activité de la base de données.

**Pour accéder à un flux d'activité depuis Kinesis avec la console Kinesis**

1. Ouvrez la console Kinesis à l’adresse [https://console.aws.amazon.com/kinesis](https://console.aws.amazon.com/kinesis).

1. Choisissez votre flux d'activité dans la liste des flux Kinesis.

   Le nom d'un flux d'activité comprend le préfixe `aws-rds-das-db-` suivi de l'ID de ressource de la base de données. Voici un exemple de. 

   ```
   aws-rds-das-db-NHVOV4PCLWHGF52NP
   ```

   Pour utiliser la console Amazon RDS afin de trouver l’ID de ressource pour la base de données, choisissez votre instance de base de données dans la liste des bases de données, puis choisissez l’onglet **Configuration**.

   Pour trouver le nom complet de flux Kinesis pour un flux d’activité à l’aide de AWS CLI, utilisez une demande de CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) et notez la valeur de `ActivityStreamKinesisStreamName` dans la réponse.

1. Choisissez **Surveillance** pour commencer à observer l'activité de base de données.

Pour plus d’informations sur l’utilisation d’Amazon Kinesis, consultez [En quoi consiste le service Amazon Kinesis Data Streams ?](https://docs.aws.amazon.com/streams/latest/dev/introduction.html).

# Contenu du journal d’audit et exemples pour les flux d’activité de base de données
<a name="DBActivityStreams.AuditLog"></a>

Les événements surveillés sont représentés dans le flux d’activité de base de données sous la forme de chaînes JSON. La structure se compose d’un objet JSON contenant un `DatabaseActivityMonitoringRecord`, qui contient lui-même un tableau des événements d’activité `databaseActivityEventList`. 

**Note**  
Pour les flux d’activité de base de données, le tableau JSON `paramList` n’inclut pas les valeurs null des applications Hibernate.

**Topics**
+ [Exemples de journaux d’audit de flux d’activité](#DBActivityStreams.AuditLog.Examples)
+ [DatabaseActivityMonitoringRecords Objet JSON](#DBActivityStreams.AuditLog.DatabaseActivityMonitoringRecords)
+ [databaseActivityEvents Objet JSON](#DBActivityStreams.AuditLog.databaseActivityEvents)

## Exemples de journaux d’audit de flux d’activité
<a name="DBActivityStreams.AuditLog.Examples"></a>

Vous trouverez ci-après des exemples de journaux d’audits JSON déchiffrés d’enregistrements d’événements d’activité.

**Example Enregistrement d'événement d'activité d' CONNECT**  
L’enregistrement d’événement d’activité suivant indique une connexion à l’aide d’une instruction SQL `CONNECT` (`command`) par un client léger JDBC (`clientApplication`) pour votre base de données Oracle.  

```
{
    "class": "Standard",
    "clientApplication": "JDBC Thin Client",
    "command": "LOGON",
    "commandText": null,
    "dbid": "0123456789",
    "databaseName": "ORCL",
    "dbProtocol": "oracle",
    "dbUserName": "TEST",
    "endTime": null,
    "errorMessage": null,
    "exitCode": 0,
    "logTime": "2021-01-15 00:15:36.233787",
    "netProtocol": "tcp",
    "objectName": null,
    "objectType": null,
    "paramList": [],
    "pid": 17904,
    "remoteHost": "123.456.789.012",
    "remotePort": "25440",
    "rowCount": null,
    "serverHost": "987.654.321.098",
    "serverType": "oracle",
    "serverVersion": "19.0.0.0.ru-2020-01.rur-2020-01.r1.EE.3",
    "serviceName": "oracle-ee",
    "sessionId": 987654321,
    "startTime": null,
    "statementId": 1,
    "substatementId": null,
    "transactionId": "0000000000000000",
    "engineNativeAuditFields": {
        "UNIFIED_AUDIT_POLICIES": "TEST_POL_EVERYTHING",
        "FGA_POLICY_NAME": null,
        "DV_OBJECT_STATUS": null,
        "SYSTEM_PRIVILEGE_USED": "CREATE SESSION",
        "OLS_LABEL_COMPONENT_TYPE": null,
        "XS_SESSIONID": null,
        "ADDITIONAL_INFO": null,
        "INSTANCE_ID": 1,
        "DBID": 123456789
        "DV_COMMENT": null,
        "RMAN_SESSION_STAMP": null,
        "NEW_NAME": null,
        "DV_ACTION_NAME": null,
        "OLS_PROGRAM_UNIT_NAME": null,
        "OLS_STRING_LABEL": null,
        "RMAN_SESSION_RECID": null,
        "OBJECT_PRIVILEGES": null,
        "OLS_OLD_VALUE": null,
        "XS_TARGET_PRINCIPAL_NAME": null,
        "XS_NS_ATTRIBUTE": null,
        "XS_NS_NAME": null,
        "DBLINK_INFO": null,
        "AUTHENTICATION_TYPE": "(TYPE\u003d(DATABASE));(CLIENT ADDRESS\u003d((ADDRESS\u003d(PROTOCOL\u003dtcp)(HOST\u003d205.251.233.183)(PORT\u003d25440))));",
        "OBJECT_EDITION": null,
        "OLS_PRIVILEGES_GRANTED": null,
        "EXCLUDED_USER": null,
        "DV_ACTION_OBJECT_NAME": null,
        "OLS_LABEL_COMPONENT_NAME": null,
        "EXCLUDED_SCHEMA": null,
        "DP_TEXT_PARAMETERS1": null,
        "XS_USER_NAME": null,
        "XS_ENABLED_ROLE": null,
        "XS_NS_ATTRIBUTE_NEW_VAL": null,
        "DIRECT_PATH_NUM_COLUMNS_LOADED": null,
        "AUDIT_OPTION": null,
        "DV_EXTENDED_ACTION_CODE": null,
        "XS_PACKAGE_NAME": null,
        "OLS_NEW_VALUE": null,
        "DV_RETURN_CODE": null,
        "XS_CALLBACK_EVENT_TYPE": null,
        "USERHOST": "a1b2c3d4e5f6.amazon.com",
        "GLOBAL_USERID": null,
        "CLIENT_IDENTIFIER": null,
        "RMAN_OPERATION": null,
        "TERMINAL": "unknown",
        "OS_USERNAME": "sumepate",
        "OLS_MAX_READ_LABEL": null,
        "XS_PROXY_USER_NAME": null,
        "XS_DATASEC_POLICY_NAME": null,
        "DV_FACTOR_CONTEXT": null,
        "OLS_MAX_WRITE_LABEL": null,
        "OLS_PARENT_GROUP_NAME": null,
        "EXCLUDED_OBJECT": null,
        "DV_RULE_SET_NAME": null,
        "EXTERNAL_USERID": null,
        "EXECUTION_ID": null,
        "ROLE": null,
        "PROXY_SESSIONID": 0,
        "DP_BOOLEAN_PARAMETERS1": null,
        "OLS_POLICY_NAME": null,
        "OLS_GRANTEE": null,
        "OLS_MIN_WRITE_LABEL": null,
        "APPLICATION_CONTEXTS": null,
        "XS_SCHEMA_NAME": null,
        "DV_GRANTEE": null,
        "XS_COOKIE": null,
        "DBPROXY_USERNAME": null,
        "DV_ACTION_CODE": null,
        "OLS_PRIVILEGES_USED": null,
        "RMAN_DEVICE_TYPE": null,
        "XS_NS_ATTRIBUTE_OLD_VAL": null,
        "TARGET_USER": null,
        "XS_ENTITY_TYPE": null,
        "ENTRY_ID": 1,
        "XS_PROCEDURE_NAME": null,
        "XS_INACTIVITY_TIMEOUT": null,
        "RMAN_OBJECT_TYPE": null,
        "SYSTEM_PRIVILEGE": null,
        "NEW_SCHEMA": null,
        "SCN": 5124715
    }
}
```
L’enregistrement d’événement d’activité suivant indique un échec de connexion pour votre base de données SQL Server.  

```
{
    "type": "DatabaseActivityMonitoringRecord",
    "clusterId": "",
    "instanceId": "db-4JCWQLUZVFYP7DIWP6JVQ77O3Q",
    "databaseActivityEventList": [
        {
            "class": "LOGIN",
            "clientApplication": "Microsoft SQL Server Management Studio",
            "command": "LOGIN FAILED",
            "commandText": "Login failed for user 'test'. Reason: Password did not match that for the login provided. [CLIENT: local-machine]",
            "databaseName": "",
            "dbProtocol": "SQLSERVER",
            "dbUserName": "test",
            "endTime": null,
            "errorMessage": null,
            "exitCode": 0,
            "logTime": "2022-10-06 21:34:42.7113072+00",
            "netProtocol": null,
            "objectName": "",
            "objectType": "LOGIN",
            "paramList": null,
            "pid": null,
            "remoteHost": "local machine",
            "remotePort": null,
            "rowCount": 0,
            "serverHost": "172.31.30.159",
            "serverType": "SQLSERVER",
            "serverVersion": "15.00.4073.23.v1.R1",
            "serviceName": "sqlserver-ee",
            "sessionId": 0,
            "startTime": null,
            "statementId": "0x1eb0d1808d34a94b9d3dcf5432750f02",
            "substatementId": 1,
            "transactionId": "0",
            "type": "record",
            "engineNativeAuditFields": {
                "target_database_principal_id": 0,
                "target_server_principal_id": 0,
                "target_database_principal_name": "",
                "server_principal_id": 0,
                "user_defined_information": "",
                "response_rows": 0,
                "database_principal_name": "",
                "target_server_principal_name": "",
                "schema_name": "",
                "is_column_permission": false,
                "object_id": 0,
                "server_instance_name": "EC2AMAZ-NFUJJNO",
                "target_server_principal_sid": null,
                "additional_information": "<action_info "xmlns=\"http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data\"><pooled_connection>0</pooled_connection><error>0x00004818</error><state>8</state><address>local machine</address><PasswordFirstNibbleHash>B</PasswordFirstNibbleHash></action_info>"-->,
                "duration_milliseconds": 0,
                "permission_bitmask": "0x00000000000000000000000000000000",
                "data_sensitivity_information": "",
                "session_server_principal_name": "",
                "connection_id": "98B4F537-0F82-49E3-AB08-B9D33B5893EF",
                "audit_schema_version": 1,
                "database_principal_id": 0,
                "server_principal_sid": null,
                "user_defined_event_id": 0,
                "host_name": "EC2AMAZ-NFUJJNO"
            }
        }
    ]
}
```
Si un flux d’activité de base de données n’est pas activé, le dernier champ du document JSON est `"engineNativeAuditFields": { }`. 

**Example Registre d’événement d’activité d’une instruction CREATE TABLE**  
L’exemple suivant montre un événement `CREATE TABLE` pour votre base de données Oracle.  

```
{
    "class": "Standard",
    "clientApplication": "sqlplus@ip-12-34-5-678 (TNS V1-V3)",
    "command": "CREATE TABLE",
    "commandText": "CREATE TABLE persons(\n    person_id NUMBER GENERATED BY DEFAULT AS IDENTITY,\n    first_name VARCHAR2(50) NOT NULL,\n    last_name VARCHAR2(50) NOT NULL,\n    PRIMARY KEY(person_id)\n)",
    "dbid": "0123456789",
    "databaseName": "ORCL",
    "dbProtocol": "oracle",
    "dbUserName": "TEST",
    "endTime": null,
    "errorMessage": null,
    "exitCode": 0,
    "logTime": "2021-01-15 00:22:49.535239",
    "netProtocol": "beq",
    "objectName": "PERSONS",
    "objectType": "TEST",
    "paramList": [],
    "pid": 17687,
    "remoteHost": "123.456.789.0",
    "remotePort": null,
    "rowCount": null,
    "serverHost": "987.654.321.01",
    "serverType": "oracle",
    "serverVersion": "19.0.0.0.ru-2020-01.rur-2020-01.r1.EE.3",
    "serviceName": "oracle-ee",
    "sessionId": 1234567890,
    "startTime": null,
    "statementId": 43,
    "substatementId": null,
    "transactionId": "090011007F0D0000",
    "engineNativeAuditFields": {
        "UNIFIED_AUDIT_POLICIES": "TEST_POL_EVERYTHING",
        "FGA_POLICY_NAME": null,
        "DV_OBJECT_STATUS": null,
        "SYSTEM_PRIVILEGE_USED": "CREATE SEQUENCE, CREATE TABLE",
        "OLS_LABEL_COMPONENT_TYPE": null,
        "XS_SESSIONID": null,
        "ADDITIONAL_INFO": null,
        "INSTANCE_ID": 1,
        "DV_COMMENT": null,
        "RMAN_SESSION_STAMP": null,
        "NEW_NAME": null,
        "DV_ACTION_NAME": null,
        "OLS_PROGRAM_UNIT_NAME": null,
        "OLS_STRING_LABEL": null,
        "RMAN_SESSION_RECID": null,
        "OBJECT_PRIVILEGES": null,
        "OLS_OLD_VALUE": null,
        "XS_TARGET_PRINCIPAL_NAME": null,
        "XS_NS_ATTRIBUTE": null,
        "XS_NS_NAME": null,
        "DBLINK_INFO": null,
        "AUTHENTICATION_TYPE": "(TYPE\u003d(DATABASE));(CLIENT ADDRESS\u003d((PROTOCOL\u003dbeq)(HOST\u003d123.456.789.0)));",
        "OBJECT_EDITION": null,
        "OLS_PRIVILEGES_GRANTED": null,
        "EXCLUDED_USER": null,
        "DV_ACTION_OBJECT_NAME": null,
        "OLS_LABEL_COMPONENT_NAME": null,
        "EXCLUDED_SCHEMA": null,
        "DP_TEXT_PARAMETERS1": null,
        "XS_USER_NAME": null,
        "XS_ENABLED_ROLE": null,
        "XS_NS_ATTRIBUTE_NEW_VAL": null,
        "DIRECT_PATH_NUM_COLUMNS_LOADED": null,
        "AUDIT_OPTION": null,
        "DV_EXTENDED_ACTION_CODE": null,
        "XS_PACKAGE_NAME": null,
        "OLS_NEW_VALUE": null,
        "DV_RETURN_CODE": null,
        "XS_CALLBACK_EVENT_TYPE": null,
        "USERHOST": "ip-10-13-0-122",
        "GLOBAL_USERID": null,
        "CLIENT_IDENTIFIER": null,
        "RMAN_OPERATION": null,
        "TERMINAL": "pts/1",
        "OS_USERNAME": "rdsdb",
        "OLS_MAX_READ_LABEL": null,
        "XS_PROXY_USER_NAME": null,
        "XS_DATASEC_POLICY_NAME": null,
        "DV_FACTOR_CONTEXT": null,
        "OLS_MAX_WRITE_LABEL": null,
        "OLS_PARENT_GROUP_NAME": null,
        "EXCLUDED_OBJECT": null,
        "DV_RULE_SET_NAME": null,
        "EXTERNAL_USERID": null,
        "EXECUTION_ID": null,
        "ROLE": null,
        "PROXY_SESSIONID": 0,
        "DP_BOOLEAN_PARAMETERS1": null,
        "OLS_POLICY_NAME": null,
        "OLS_GRANTEE": null,
        "OLS_MIN_WRITE_LABEL": null,
        "APPLICATION_CONTEXTS": null,
        "XS_SCHEMA_NAME": null,
        "DV_GRANTEE": null,
        "XS_COOKIE": null,
        "DBPROXY_USERNAME": null,
        "DV_ACTION_CODE": null,
        "OLS_PRIVILEGES_USED": null,
        "RMAN_DEVICE_TYPE": null,
        "XS_NS_ATTRIBUTE_OLD_VAL": null,
        "TARGET_USER": null,
        "XS_ENTITY_TYPE": null,
        "ENTRY_ID": 12,
        "XS_PROCEDURE_NAME": null,
        "XS_INACTIVITY_TIMEOUT": null,
        "RMAN_OBJECT_TYPE": null,
        "SYSTEM_PRIVILEGE": null,
        "NEW_SCHEMA": null,
        "SCN": 5133083
    }
}
```
L’exemple suivant montre un événement `CREATE TABLE` pour votre base de données SQL Server.  

```
{
    "type": "DatabaseActivityMonitoringRecord",
    "clusterId": "",
    "instanceId": "db-4JCWQLUZVFYP7DIWP6JVQ77O3Q",
    "databaseActivityEventList": [
        {
            "class": "SCHEMA",
            "clientApplication": "Microsoft SQL Server Management Studio - Query",
            "command": "ALTER",
            "commandText": "Create table [testDB].[dbo].[TestTable2](\r\ntextA varchar(6000),\r\n    textB varchar(6000)\r\n)",
            "databaseName": "testDB",
            "dbProtocol": "SQLSERVER",
            "dbUserName": "test",
            "endTime": null,
            "errorMessage": null,
            "exitCode": 1,
            "logTime": "2022-10-06 21:44:38.4120677+00",
            "netProtocol": null,
            "objectName": "dbo",
            "objectType": "SCHEMA",
            "paramList": null,
            "pid": null,
            "remoteHost": "local machine",
            "remotePort": null,
            "rowCount": 0,
            "serverHost": "172.31.30.159",
            "serverType": "SQLSERVER",
            "serverVersion": "15.00.4073.23.v1.R1",
            "serviceName": "sqlserver-ee",
            "sessionId": 84,
            "startTime": null,
            "statementId": "0x5178d33d56e95e419558b9607158a5bd",
            "substatementId": 1,
            "transactionId": "4561864",
            "type": "record",
            "engineNativeAuditFields": {
                "target_database_principal_id": 0,
                "target_server_principal_id": 0,
                "target_database_principal_name": "",
                "server_principal_id": 2,
                "user_defined_information": "",
                "response_rows": 0,
                "database_principal_name": "dbo",
                "target_server_principal_name": "",
                "schema_name": "",
                "is_column_permission": false,
                "object_id": 1,
                "server_instance_name": "EC2AMAZ-NFUJJNO",
                "target_server_principal_sid": null,
                "additional_information": "",
                "duration_milliseconds": 0,
                "permission_bitmask": "0x00000000000000000000000000000000",
                "data_sensitivity_information": "",
                "session_server_principal_name": "test",
                "connection_id": "EE1FE3FD-EF2C-41FD-AF45-9051E0CD983A",
                "audit_schema_version": 1,
                "database_principal_id": 1,
                "server_principal_sid": "0x010500000000000515000000bdc2795e2d0717901ba6998cf4010000",
                "user_defined_event_id": 0,
                "host_name": "EC2AMAZ-NFUJJNO"
            }
        }
    ]
}
```

**Example Registre d’événement d’activité d’une instruction SELECT**  
L’exemple suivant montre un événement `SELECT` pour votre base de données Oracle.  

```
{
    "class": "Standard",
    "clientApplication": "sqlplus@ip-12-34-5-678 (TNS V1-V3)",
    "command": "SELECT",
    "commandText": "select count(*) from persons",
    "databaseName": "1234567890",
    "dbProtocol": "oracle",
    "dbUserName": "TEST",
    "endTime": null,
    "errorMessage": null,
    "exitCode": 0,
    "logTime": "2021-01-15 00:25:18.850375",
    "netProtocol": "beq",
    "objectName": "PERSONS",
    "objectType": "TEST",
    "paramList": [],
    "pid": 17687,
    "remoteHost": "123.456.789.0",
    "remotePort": null,
    "rowCount": null,
    "serverHost": "987.654.321.09",
    "serverType": "oracle",
    "serverVersion": "19.0.0.0.ru-2020-01.rur-2020-01.r1.EE.3",
    "serviceName": "oracle-ee",
    "sessionId": 1080639707,
    "startTime": null,
    "statementId": 44,
    "substatementId": null,
    "transactionId": null,
    "engineNativeAuditFields": {
        "UNIFIED_AUDIT_POLICIES": "TEST_POL_EVERYTHING",
        "FGA_POLICY_NAME": null,
        "DV_OBJECT_STATUS": null,
        "SYSTEM_PRIVILEGE_USED": null,
        "OLS_LABEL_COMPONENT_TYPE": null,
        "XS_SESSIONID": null,
        "ADDITIONAL_INFO": null,
        "INSTANCE_ID": 1,
        "DV_COMMENT": null,
        "RMAN_SESSION_STAMP": null,
        "NEW_NAME": null,
        "DV_ACTION_NAME": null,
        "OLS_PROGRAM_UNIT_NAME": null,
        "OLS_STRING_LABEL": null,
        "RMAN_SESSION_RECID": null,
        "OBJECT_PRIVILEGES": null,
        "OLS_OLD_VALUE": null,
        "XS_TARGET_PRINCIPAL_NAME": null,
        "XS_NS_ATTRIBUTE": null,
        "XS_NS_NAME": null,
        "DBLINK_INFO": null,
        "AUTHENTICATION_TYPE": "(TYPE\u003d(DATABASE));(CLIENT ADDRESS\u003d((PROTOCOL\u003dbeq)(HOST\u003d123.456.789.0)));",
        "OBJECT_EDITION": null,
        "OLS_PRIVILEGES_GRANTED": null,
        "EXCLUDED_USER": null,
        "DV_ACTION_OBJECT_NAME": null,
        "OLS_LABEL_COMPONENT_NAME": null,
        "EXCLUDED_SCHEMA": null,
        "DP_TEXT_PARAMETERS1": null,
        "XS_USER_NAME": null,
        "XS_ENABLED_ROLE": null,
        "XS_NS_ATTRIBUTE_NEW_VAL": null,
        "DIRECT_PATH_NUM_COLUMNS_LOADED": null,
        "AUDIT_OPTION": null,
        "DV_EXTENDED_ACTION_CODE": null,
        "XS_PACKAGE_NAME": null,
        "OLS_NEW_VALUE": null,
        "DV_RETURN_CODE": null,
        "XS_CALLBACK_EVENT_TYPE": null,
        "USERHOST": "ip-12-34-5-678",
        "GLOBAL_USERID": null,
        "CLIENT_IDENTIFIER": null,
        "RMAN_OPERATION": null,
        "TERMINAL": "pts/1",
        "OS_USERNAME": "rdsdb",
        "OLS_MAX_READ_LABEL": null,
        "XS_PROXY_USER_NAME": null,
        "XS_DATASEC_POLICY_NAME": null,
        "DV_FACTOR_CONTEXT": null,
        "OLS_MAX_WRITE_LABEL": null,
        "OLS_PARENT_GROUP_NAME": null,
        "EXCLUDED_OBJECT": null,
        "DV_RULE_SET_NAME": null,
        "EXTERNAL_USERID": null,
        "EXECUTION_ID": null,
        "ROLE": null,
        "PROXY_SESSIONID": 0,
        "DP_BOOLEAN_PARAMETERS1": null,
        "OLS_POLICY_NAME": null,
        "OLS_GRANTEE": null,
        "OLS_MIN_WRITE_LABEL": null,
        "APPLICATION_CONTEXTS": null,
        "XS_SCHEMA_NAME": null,
        "DV_GRANTEE": null,
        "XS_COOKIE": null,
        "DBPROXY_USERNAME": null,
        "DV_ACTION_CODE": null,
        "OLS_PRIVILEGES_USED": null,
        "RMAN_DEVICE_TYPE": null,
        "XS_NS_ATTRIBUTE_OLD_VAL": null,
        "TARGET_USER": null,
        "XS_ENTITY_TYPE": null,
        "ENTRY_ID": 13,
        "XS_PROCEDURE_NAME": null,
        "XS_INACTIVITY_TIMEOUT": null,
        "RMAN_OBJECT_TYPE": null,
        "SYSTEM_PRIVILEGE": null,
        "NEW_SCHEMA": null,
        "SCN": 5136972
    }
}
```
L’exemple suivant montre un événement `SELECT` pour votre base de données SQL Server.  

```
{
    "type": "DatabaseActivityMonitoringRecord",
    "clusterId": "",
    "instanceId": "db-4JCWQLUZVFYP7DIWP6JVQ77O3Q",
    "databaseActivityEventList": [
        {
            "class": "TABLE",
            "clientApplication": "Microsoft SQL Server Management Studio - Query",
            "command": "SELECT",
            "commandText": "select * from [testDB].[dbo].[TestTable]",
            "databaseName": "testDB",
            "dbProtocol": "SQLSERVER",
            "dbUserName": "test",
            "endTime": null,
            "errorMessage": null,
            "exitCode": 1,
            "logTime": "2022-10-06 21:24:59.9422268+00",
            "netProtocol": null,
            "objectName": "TestTable",
            "objectType": "TABLE",
            "paramList": null,
            "pid": null,
            "remoteHost": "local machine",
            "remotePort": null,
            "rowCount": 0,
            "serverHost": "172.31.30.159",
            "serverType": "SQLSERVER",
            "serverVersion": "15.00.4073.23.v1.R1",
            "serviceName": "sqlserver-ee",
            "sessionId": 62,
            "startTime": null,
            "statementId": "0x03baed90412f564fad640ebe51f89b99",
            "substatementId": 1,
            "transactionId": "4532935",
            "type": "record",
            "engineNativeAuditFields": {
                "target_database_principal_id": 0,
                "target_server_principal_id": 0,
                "target_database_principal_name": "",
                "server_principal_id": 2,
                "user_defined_information": "",
                "response_rows": 0,
                "database_principal_name": "dbo",
                "target_server_principal_name": "",
                "schema_name": "dbo",
                "is_column_permission": true,
                "object_id": 581577110,
                "server_instance_name": "EC2AMAZ-NFUJJNO",
                "target_server_principal_sid": null,
                "additional_information": "",
                "duration_milliseconds": 0,
                "permission_bitmask": "0x00000000000000000000000000000001",
                "data_sensitivity_information": "",
                "session_server_principal_name": "test",
                "connection_id": "AD3A5084-FB83-45C1-8334-E923459A8109",
                "audit_schema_version": 1,
                "database_principal_id": 1,
                "server_principal_sid": "0x010500000000000515000000bdc2795e2d0717901ba6998cf4010000",
                "user_defined_event_id": 0,
                "host_name": "EC2AMAZ-NFUJJNO"
            }
        }
    ]
}
```

## DatabaseActivityMonitoringRecords Objet JSON
<a name="DBActivityStreams.AuditLog.DatabaseActivityMonitoringRecords"></a>

Les enregistrements d’événement d’activité de base de données se trouvent dans un objet JSON qui contient les informations suivantes.


****  

| Champ JSON | Type de données | Description | 
| --- | --- | --- | 
|  `type`  | chaîne |  Type de l’enregistrement JSON. La valeur est `DatabaseActivityMonitoringRecords`.  | 
| version | chaîne |  Version des enregistrements de surveillance d’activité de base de données. La base de données Oracle utilise la version 1.3 et SQL Server utilise la version 1.4. Ces versions du moteur introduisent l’objet JSON engineNativeAuditFields.  | 
|  [databaseActivityEvents](#DBActivityStreams.AuditLog.databaseActivityEvents)  | chaîne |  Objet JSON qui contient les événements d’activité.  | 
| key | chaîne | Clé de chiffrement que vous utilisez pour déchiffrer [Tableau JSON databaseActivityEventList](DBActivityStreams.AuditLog.databaseActivityEventList.md)  | 

## databaseActivityEvents Objet JSON
<a name="DBActivityStreams.AuditLog.databaseActivityEvents"></a>

L’objet JSON `databaseActivityEvents` contient les informations suivantes.

### Champs de niveau supérieur dans l’enregistrement JSON
<a name="DBActivityStreams.AuditLog.topLevel"></a>

 Chaque événement du journal d’audit est encapsulé dans un enregistrement au format JSON. Cet enregistrement contient les champs suivants. 

**type**  
 Ce champ a toujours la valeur `DatabaseActivityMonitoringRecords`. 

**version ;**  
 Ce champ représente la version du contrat ou du protocole de données de flux d’activité de base de données. Il définit les champs disponibles.

**databaseActivityEvents**  
 Chaîne chiffrée représentant un ou plusieurs événements d’activité. Elle est représentée sou la forme d’un tableau base64 octets. Lorsque vous déchiffrez la chaîne, le résultat est un enregistrement au format JSON avec des champs comme ceux des exemples de cette section.

**key**  
 Clé de données chiffrée utilisée pour chiffrer la chaîne `databaseActivityEvents`. Il s'agit du même AWS KMS key que celui que vous avez fourni lorsque vous avez démarré le flux d'activité de la base de données.

 L’exemple suivant illustre le format de cet enregistrement.

```
{
  "type":"DatabaseActivityMonitoringRecords",
  "version":"1.3",
  "databaseActivityEvents":"encrypted audit records",
  "key":"encrypted key"
}
```

```
           "type":"DatabaseActivityMonitoringRecords",
           "version":"1.4",
           "databaseActivityEvents":"encrypted audit records",
           "key":"encrypted key"
```

Pour déchiffrer le contenu du champ `databaseActivityEvents`, procédez comme suit :

1.  Déchiffrez la valeur dans le champ JSON `key` à l’aide de la clé KMS que vous avez fournie lors du démarrage du flux d’activité de base de données. Cette opération renvoie la clé de chiffrement des données en texte clair. 

1.  Décodez en base64 la valeur dans le champ JSON `databaseActivityEvents` pour obtenir le texte chiffré, au format binaire, de la charge utile d’audit. 

1.  Déchiffrez le chiffrement binaire avec la clé de chiffrement de données que vous avez décodée au cours de la première étape. 

1.  Décompressez la charge utile déchiffrée. 
   +  La charge utile chiffrée se trouve dans le champ `databaseActivityEvents`. 
   +  Le champ `databaseActivityEventList` contient un tableau d’enregistrements d’audits. Les champs `type` du tableau peuvent être `record` ou `heartbeat`. 

L’enregistrement d’événement d’activité du journal d’audit est un objet JSON qui contient les informations suivantes.


****  

| Champ JSON | Type de données | Description | 
| --- | --- | --- | 
|  `type`  | chaîne |  Type de l’enregistrement JSON. La valeur est `DatabaseActivityMonitoringRecord`.  | 
| instanceId | chaîne | Identifiant de ressource d’instance de base de données. Il correspond à l’attribut d’instance de base de données DbiResourceId. | 
|  [Tableau JSON databaseActivityEventList](DBActivityStreams.AuditLog.databaseActivityEventList.md)   | chaîne |  Tableau d’enregistrements d’audits d’activité ou de messages de pulsations.  | 

# Tableau JSON databaseActivityEventList pour les flux d’activité de base de données
<a name="DBActivityStreams.AuditLog.databaseActivityEventList"></a>

Les données utiles du journal d’audit sont un tableau JSON `databaseActivityEventList` chiffré. Ci-dessous, le tableau répertorie par ordre alphabétique les champs de chaque événement d'activité dans le tableau `DatabaseActivityEventList` déchiffré d'un journal d'audit. 

Lorsque l'audit unifié est activé dans Oracle Database, les enregistrements d'audit sont renseignés dans cette nouvelle trace d'audit. La vue `UNIFIED_AUDIT_TRAIL` affiche les enregistrements d'audit sous forme de tableau en extrayant les enregistrements d'audit de la trace d'audit. Lorsque vous démarrez un flux d'activité de base de données, une colonne dans `UNIFIED_AUDIT_TRAIL` mappe à un champ dans le tableau `databaseActivityEventList`.

**Important**  
Il se peut que la structure d'événement change. Il se peut qu'Amazon RDS ajoute de nouveaux champs aux événements d'activité à l'avenir. Dans les applications qui analysent les données JSON, assurez-vous que votre code peut ignorer ou prendre les mesures appropriées pour les noms de champs inconnus. 

## Champs databaseActivityEventList pour Amazon RDS for Oracle
<a name="DBActivityStreams.AuditLog.databaseActivityEventList.ro"></a>

Voici les champs `databaseActivityEventList` pour Amazon RDS for Oracle.


| Champ | Type de données | Source | Description | 
| --- | --- | --- | --- | 
|  `class`  |  chaîne  |  Colonne `AUDIT_TYPE` dans `UNIFIED_AUDIT_TRAIL`  |  La classe d'un événement d'activité. Celle-ci correspond à la colonne `AUDIT_TYPE` dans la vue `UNIFIED_AUDIT_TRAIL`. Les valeurs valides pour Amazon RDS for Oracle sont les suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/DBActivityStreams.AuditLog.databaseActivityEventList.html) Pour plus d'informations, consultez [UNIFIED\$1AUDIT\$1TRAIL](https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/UNIFIED_AUDIT_TRAIL.html#GUID-B7CE1C02-2FD4-47D6-80AA-CF74A60CDD1D) dans la documentation Oracle.  | 
|  `clientApplication`  |  chaîne  |  `CLIENT_PROGRAM_NAME` dans `UNIFIED_AUDIT_TRAIL`  |  Application utilisée par le client pour se connecter, telle que signalée par le client. Le client n'a pas à fournir cette information, la valeur peut être « null ». Un exemple de valeur est `JDBC Thin Client`.  | 
|  `command`  |  chaîne  |  Colonne `ACTION_NAME` dans `UNIFIED_AUDIT_TRAIL`  |  Nom de l'action exécutée par l'utilisateur. Pour comprendre l'action complète, lisez le nom de la commande et la valeur `AUDIT_TYPE`. Un exemple de valeur est `ALTER DATABASE`.  | 
|  `commandText`  |  chaîne  |  Colonne `SQL_TEXT` dans `UNIFIED_AUDIT_TRAIL`  |  Instruction SQL associée à l'événement. Un exemple de valeur est `ALTER DATABASE BEGIN BACKUP`.  | 
|  `databaseName`  |  chaîne  |  Colonne `NAME` dans `V$DATABASE`  |  Nom de la base de données.  | 
|  `dbid`  |  nombre  |  Colonne `DBID` dans `UNIFIED_AUDIT_TRAIL`  |  Identifiant numérique de la base de données. Un exemple de valeur est `1559204751`.  | 
|  `dbProtocol`  |  chaîne  |  N/A  |  Protocole de la base de données. Dans cette version bêta, la valeur est `oracle`.  | 
|  `dbUserName`  |  chaîne  |  Colonne `DBUSERNAME` dans `UNIFIED_AUDIT_TRAIL`  |  Nom de l'utilisateur de la base de données dont les actions ont été auditées. Un exemple de valeur est `RDSADMIN`.  | 
|  `endTime`  |  chaîne  |  N/A  |  Ce champ n'est pas utilisé pour RDS for Oracle. Sa valeur est toujours null.  | 
|  `engineNativeAuditFields`  |  objet  |  `UNIFIED_AUDIT_TRAIL`  |  Par défaut, cet objet est vide. Lorsque vous démarrez le flux d'activité avec l'option `--engine-native-audit-fields-included`, cet objet inclut les colonnes et leurs valeurs suivantes : <pre>ADDITIONAL_INFO<br />APPLICATION_CONTEXTS<br />AUDIT_OPTION<br />AUTHENTICATION_TYPE<br />CLIENT_IDENTIFIER<br />CURRENT_USER<br />DBLINK_INFO<br />DBPROXY_USERNAME<br />DIRECT_PATH_NUM_COLUMNS_LOADED<br />DP_BOOLEAN_PARAMETERS1<br />DP_TEXT_PARAMETERS1<br />DV_ACTION_CODE<br />DV_ACTION_NAME<br />DV_ACTION_OBJECT_NAME<br />DV_COMMENT<br />DV_EXTENDED_ACTION_CODE<br />DV_FACTOR_CONTEXT<br />DV_GRANTEE<br />DV_OBJECT_STATUS<br />DV_RETURN_CODE<br />DV_RULE_SET_NAME<br />ENTRY_ID<br />EXCLUDED_OBJECT<br />EXCLUDED_SCHEMA<br />EXCLUDED_USER<br />EXECUTION_ID<br />EXTERNAL_USERID<br />FGA_POLICY_NAME<br />GLOBAL_USERID<br />INSTANCE_ID<br />KSACL_SERVICE_NAME<br />KSACL_SOURCE_LOCATION<br />KSACL_USER_NAME<br />NEW_NAME<br />NEW_SCHEMA<br />OBJECT_EDITION<br />OBJECT_PRIVILEGES<br />OLS_GRANTEE<br />OLS_LABEL_COMPONENT_NAME<br />OLS_LABEL_COMPONENT_TYPE<br />OLS_MAX_READ_LABEL<br />OLS_MAX_WRITE_LABEL<br />OLS_MIN_WRITE_LABEL<br />OLS_NEW_VALUE<br />OLS_OLD_VALUE<br />OLS_PARENT_GROUP_NAME<br />OLS_POLICY_NAME<br />OLS_PRIVILEGES_GRANTED<br />OLS_PRIVILEGES_USED<br />OLS_PROGRAM_UNIT_NAME<br />OLS_STRING_LABEL<br />OS_USERNAME<br />PROTOCOL_ACTION_NAME<br />PROTOCOL_MESSAGE<br />PROTOCOL_RETURN_CODE<br />PROTOCOL_SESSION_ID<br />PROTOCOL_USERHOST<br />PROXY_SESSIONID<br />RLS_INFO<br />RMAN_DEVICE_TYPE<br />RMAN_OBJECT_TYPE<br />RMAN_OPERATION<br />RMAN_SESSION_RECID<br />RMAN_SESSION_STAMP<br />ROLE<br />SCN<br />SYSTEM_PRIVILEGE<br />SYSTEM_PRIVILEGE_USED<br />TARGET_USER<br />TERMINAL<br />UNIFIED_AUDIT_POLICIES<br />USERHOST<br />XS_CALLBACK_EVENT_TYPE<br />XS_COOKIE<br />XS_DATASEC_POLICY_NAME<br />XS_ENABLED_ROLE<br />XS_ENTITY_TYPE<br />XS_INACTIVITY_TIMEOUT<br />XS_NS_ATTRIBUTE<br />XS_NS_ATTRIBUTE_NEW_VAL<br />XS_NS_ATTRIBUTE_OLD_VAL<br />XS_NS_NAME<br />XS_PACKAGE_NAME<br />XS_PROCEDURE_NAME<br />XS_PROXY_USER_NAME<br />XS_SCHEMA_NAME<br />XS_SESSIONID<br />XS_TARGET_PRINCIPAL_NAME<br />XS_USER_NAME</pre> Pour plus d'informations, consultez [UNIFIED\$1AUDIT\$1TRAIL](https://docs.oracle.com/database/121/REFRN/GUID-B7CE1C02-2FD4-47D6-80AA-CF74A60CDD1D.htm#REFRN29162) dans la documentation Oracle Database.  | 
|  `errorMessage`  |  chaîne  |  N/A  |  Ce champ n'est pas utilisé pour RDS for Oracle. Sa valeur est toujours null.  | 
|  `exitCode`  |  nombre  |  Colonne `RETURN_CODE` dans `UNIFIED_AUDIT_TRAIL`  |  Code d'erreur Oracle Database généré par l'action. Si l'action a réussi, la valeur est `0`.  | 
|  `logTime`  |  chaîne  |  Colonne `EVENT_TIMESTAMP_UTC` dans `UNIFIED_AUDIT_TRAIL`  |  Horodatage de la création de l'entrée de trace d'audit. Un exemple de valeur est `2020-11-27 06:56:14.981404`.  | 
|  `netProtocol`  |  chaîne  |  Colonne `AUTHENTICATION_TYPE` dans `UNIFIED_AUDIT_TRAIL`  |  Protocole de communication réseau. Un exemple de valeur est `TCP`.  | 
|  `objectName`  |  chaîne  |  Colonne `OBJECT_NAME` dans `UNIFIED_AUDIT_TRAIL`  |  Nom de l'objet affecté par l'action. Un exemple de valeur est `employees`.  | 
|  `objectType`  |  chaîne  |  Colonne `OBJECT_SCHEMA` dans `UNIFIED_AUDIT_TRAIL`  |  Nom de schéma de l'objet affecté par l'action. Un exemple de valeur est `hr`.  | 
|  `paramList`  |  liste  |  Colonne `SQL_BINDS` dans `UNIFIED_AUDIT_TRAIL`  |  La liste des variables de liaison éventuelles associées à `SQL_TEXT`. Un exemple de valeur est `parameter_1,parameter_2`.  | 
|  `pid`  |  nombre  |  Colonne `OS_PROCESS` dans `UNIFIED_AUDIT_TRAIL`  |  Identifiant de processus du système d’exploitation du processus de base de données Oracle. Un exemple de valeur est `22396`.  | 
|  `remoteHost`  |  chaîne  |  Colonne `AUTHENTICATION_TYPE` dans `UNIFIED_AUDIT_TRAIL`  |  Soit l'adresse IP du client, soit le nom de l'hôte à partir duquel la session a été générée. Un exemple de valeur est `123.456.789.123`.  | 
|  `remotePort`  |  chaîne  |  Colonne `AUTHENTICATION_TYPE` dans `UNIFIED_AUDIT_TRAIL`  |  Numéro de port du client. Une valeur typique dans les environnements Oracle Database est `1521`.  | 
|  `rowCount`  |  nombre  |  N/A  |  Ce champ n'est pas utilisé pour RDS for Oracle. Sa valeur est toujours null.  | 
|  `serverHost`  |  chaîne  |  Hôte de base de données   |  Adresse IP de l'hôte du serveur de base de données. Un exemple de valeur est `123.456.789.123`.  | 
|  `serverType`  |  chaîne  |  N/A  |  Type de serveur de base de données. La valeur est toujours `ORACLE`.  | 
|  `serverVersion`  |  chaîne  |  Hôte de base de données   |  Version d'Amazon RDS for Oracle, Release Update (RU) et Release Update Revision (RUR). Un exemple de valeur est `19.0.0.0.ru-2020-01.rur-2020-01.r1.EE.3`.  | 
|  `serviceName`  |  chaîne  |  Hôte de base de données   |  Nom du service. Un exemple de valeur est `oracle-ee`.   | 
|  `sessionId`  |  nombre  |  Colonne `SESSIONID` dans `UNIFIED_AUDIT_TRAIL`  |  Identifiant de session de l’audit. Par exemple : `1894327130`.  | 
|  `startTime`  |  chaîne  |  N/A  |  Ce champ n'est pas utilisé pour RDS for Oracle. Sa valeur est toujours null.  | 
|  `statementId`  |  nombre  |  Colonne `STATEMENT_ID` dans `UNIFIED_AUDIT_TRAIL`  |  ID numérique pour chaque exécution d'instruction. Une instruction peut provoquer de nombreuses actions. Un exemple de valeur est `142197`.  | 
|  `substatementId`  |  N/A  |  N/A  |  Ce champ n'est pas utilisé pour RDS for Oracle. Sa valeur est toujours null.  | 
|  `transactionId`  |  chaîne  |  Colonne `TRANSACTION_ID` dans `UNIFIED_AUDIT_TRAIL`  |  L’identifiant de la transaction dans laquelle l’objet est modifié. Un exemple de valeur est `02000800D5030000`.  | 

## Champs databaseActivityEventList pour Amazon RDS for SQL Server
<a name="DBActivityStreams.AuditLog.databaseActivityEventList.rss"></a>

Voici les champs `databaseActivityEventList` pour Amazon RDS for SQL Server.


| Champ | Type de données | Source | Description | 
| --- | --- | --- | --- | 
|  `class`  |  chaîne  |  ` sys.fn_get_audit_file.class_type` mappé sur `sys.dm_audit_class_type_map.class_type_desc`  |  La classe d’un événement d’activité. Pour plus d'informations, consultez [Audit SQL Server (moteur de base de données)](https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine?view=sql-server-ver16) dans la documentation Microsoft.  | 
|  `clientApplication`  |  chaîne  |  `sys.fn_get_audit_file.application_name`  |  Application à laquelle le client se connecte, comme indiqué par le client (SQL Server versions 14 et ultérieures). Ce champ a la valeur null dans SQL Server version 13.  | 
|  `command`  |  chaîne  |  `sys.fn_get_audit_file.action_id` mappé sur `sys.dm_audit_actions.name`  |  Catégorie générale de l’instruction SQL. La valeur de ce champ dépend de la valeur de la classe.  | 
|  `commandText`  |  chaîne  |  `sys.fn_get_audit_file.statement`  |  Ce champ indique l'instruction SQL.  | 
|  `databaseName`  |  chaîne  |  `sys.fn_get_audit_file.database_name`  |  Nom du moteur de la base de données.  | 
|  `dbProtocol`  |  chaîne  |  N/A  |  Protocole de la base de données. Cette valeur est `SQLSERVER`.  | 
|  `dbUserName`  |  chaîne  |  `sys.fn_get_audit_file.server_principal_name`  |  L'utilisateur de la base de données pour l'authentification du client.  | 
|  `endTime`  |  chaîne  |  N/A  |  Ce champ n’est pas utilisé par Amazon RDS for SQL Server et la valeur est null.  | 
|  `engineNativeAuditFields`  |  objet  |  Chaque champ dans `sys.fn_get_audit_file` qui n'est pas répertorié dans cette colonne.  |  Par défaut, cet objet est vide. Lorsque vous démarrez le flux d'activité avec l'option `--engine-native-audit-fields-included`, cet objet inclut d'autres champs d'audit de moteur natifs, qui ne sont pas renvoyés par cette carte JSON.  | 
|  `errorMessage`  |  chaîne  |  N/A  |  Ce champ n’est pas utilisé par Amazon RDS for SQL Server et la valeur est null.  | 
|  `exitCode`  |  entier  |  `sys.fn_get_audit_file.succeeded`  |  Indique si l'action qui a démarré l'événement a réussi. Ce champ ne peut pas avoir la valeur null. Pour tous les événements, à l'exception des événements de connexion, ce champ indique si la vérification des autorisations a réussi ou échoué, mais pas si l'opération a réussi ou échoué. Les valeurs sont les suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/DBActivityStreams.AuditLog.databaseActivityEventList.html)  | 
|  `logTime`  |  chaîne  |  `sys.fn_get_audit_file.event_time`  |  Horodatage de l'événement enregistré par le serveur SQL Server.  | 
|  `netProtocol`  |  chaîne  |  N/A  |  Ce champ n’est pas utilisé par Amazon RDS for SQL Server et la valeur est null.  | 
|  `objectName`  |  chaîne  |  `sys.fn_get_audit_file.object_name`  |  Nom de l'objet de base de données si l'instruction SQL agit sur un objet.  | 
|  `objectType`  |  chaîne  |  `sys.fn_get_audit_file.class_type` mappé sur `sys.dm_audit_class_type_map.class_type_desc`  |  Type de l'objet de base de données si l'instruction SQL agit sur un type d'objet.  | 
|  `paramList`  |  chaîne  |  N/A  |  Ce champ n’est pas utilisé par Amazon RDS for SQL Server et la valeur est null.  | 
|  `pid`  |  entier  |  N/A  |  Ce champ n’est pas utilisé par Amazon RDS for SQL Server et la valeur est null.  | 
|  `remoteHost`  |  chaîne  |  `sys.fn_get_audit_file.client_ip`  |  L'adresse IP ou le nom d'hôte du client qui a émis l'instruction SQL (SQL Server versions 14 et ultérieures). Ce champ a la valeur null dans SQL Server version 13.  | 
|  `remotePort`  |  entier  |  N/A  |  Ce champ n’est pas utilisé par Amazon RDS for SQL Server et la valeur est null.  | 
|  `rowCount`  |  entier  |  `sys.fn_get_audit_file.affected_rows`  |  Nombre de lignes de la table affectées par l'instruction SQL (SQL Server versions 14 et ultérieures). Ce champ figure dans SQL Server version 13.  | 
|  `serverHost`  |  chaîne  |  Hôte de base de données  |  Adresse IP du serveur de base de données hôte.  | 
|  `serverType`  |  chaîne  |  N/A  |  Type de serveur de base de données. La valeur est `SQLSERVER`.  | 
|  `serverVersion`  |  chaîne  |  Hôte de base de données  |  Version du serveur de base de données, par exemple 15.00.4073.23.v1.R1 pour SQL Server 2017.  | 
|  `serviceName`  |  chaîne  |  Hôte de base de données  |  Nom du service. Un exemple de valeur est `sqlserver-ee`.  | 
|  `sessionId`  |  entier  |  `sys.fn_get_audit_file.session_id`  |  Identifiant unique de la session.  | 
|  `startTime`  |  chaîne  |  N/A  |  Ce champ n’est pas utilisé par Amazon RDS for SQL Server et la valeur est null.  | 
|  `statementId`  |  chaîne  |  `sys.fn_get_audit_file.sequence_group_id`  |  Identifiant unique de l’instruction SQL du client. L’identifiant est différent pour chaque événement généré. Un exemple de valeur est `0x38eaf4156267184094bb82071aaab644`.  | 
|  `substatementId`  |  entier  |  `sys.fn_get_audit_file.sequence_number`  |  Identifiant permettant de déterminer le numéro de séquence d’une instruction. Cet identifiant est utile quand des enregistrements volumineux sont divisés en plusieurs enregistrements.  | 
|  `transactionId`  |  entier  |  `sys.fn_get_audit_file.transaction_id`  |  Identifiant d’une transaction. S'il n'existe pas de transactions actives, la valeur est zéro.  | 
|  `type`  |  chaîne  |  Flux d'activité de base de données généré  |  Type d’événement. Les valeurs sont `record` ou `heartbeat`.  | 

# Traitement d’un flux d’activité de base de données à l’aide du kit AWS SDK
<a name="DBActivityStreams.CodeExample"></a>

Vous pouvez traiter par programmation un flux d’activité à l’aide du kit AWS SDK. Les exemples suivants sont des exemples Java et Python entièrement fonctionnels d'utilisation des enregistrements de flux d'activité de base de données pour une activation basée sur des instances.

------
#### [ Java ]

```
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.net.InetAddress;
import java.nio.ByteBuffer;
import java.nio.charset.StandardCharsets;
import java.security.NoSuchAlgorithmException;
import java.security.NoSuchProviderException;
import java.security.Security;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.UUID;
import java.util.zip.GZIPInputStream;

import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.spec.SecretKeySpec;

import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.encryptionsdk.AwsCrypto;
import com.amazonaws.encryptionsdk.CryptoInputStream;
import com.amazonaws.encryptionsdk.jce.JceMasterKey;
import com.amazonaws.services.kinesis.clientlibrary.exceptions.InvalidStateException;
import com.amazonaws.services.kinesis.clientlibrary.exceptions.ShutdownException;
import com.amazonaws.services.kinesis.clientlibrary.exceptions.ThrottlingException;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessor;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessorCheckpointer;
import com.amazonaws.services.kinesis.clientlibrary.interfaces.IRecordProcessorFactory;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.InitialPositionInStream;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.KinesisClientLibConfiguration;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.ShutdownReason;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.Worker;
import com.amazonaws.services.kinesis.clientlibrary.lib.worker.Worker.Builder;
import com.amazonaws.services.kinesis.model.Record;
import com.amazonaws.services.kms.AWSKMS;
import com.amazonaws.services.kms.AWSKMSClientBuilder;
import com.amazonaws.services.kms.model.DecryptRequest;
import com.amazonaws.services.kms.model.DecryptResult;
import com.amazonaws.util.Base64;
import com.amazonaws.util.IOUtils;
import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import com.google.gson.annotations.SerializedName;
import org.bouncycastle.jce.provider.BouncyCastleProvider;

public class DemoConsumer {

    private static final String STREAM_NAME = "aws-rds-das-[instance-external-resource-id]"; // aws-rds-das-db-ABCD123456
    private static final String APPLICATION_NAME = "AnyApplication"; //unique application name for dynamo table generation that holds kinesis shard tracking
    private static final String AWS_ACCESS_KEY = "[AWS_ACCESS_KEY_TO_ACCESS_KINESIS]";
    private static final String AWS_SECRET_KEY = "[AWS_SECRET_KEY_TO_ACCESS_KINESIS]";
    private static final String RESOURCE_ID = "[external-resource-id]"; // db-ABCD123456
    private static final String REGION_NAME = "[region-name]"; //us-east-1, us-east-2...
    private static final BasicAWSCredentials CREDENTIALS = new BasicAWSCredentials(AWS_ACCESS_KEY, AWS_SECRET_KEY);
    private static final AWSStaticCredentialsProvider CREDENTIALS_PROVIDER = new AWSStaticCredentialsProvider(CREDENTIALS);

    private static final AwsCrypto CRYPTO = new AwsCrypto();
    private static final AWSKMS KMS = AWSKMSClientBuilder.standard()
            .withRegion(REGION_NAME)
            .withCredentials(CREDENTIALS_PROVIDER).build();

    class Activity {
        String type;
        String version;
        String databaseActivityEvents;
        String key;
    }

    class ActivityEvent {
        @SerializedName("class") String _class;
        String clientApplication;
        String command;
        String commandText;
        String databaseName;
        String dbProtocol;
        String dbUserName;
        String endTime;
        String errorMessage;
        String exitCode;
        String logTime;
        String netProtocol;
        String objectName;
        String objectType;
        List<String> paramList;
        String pid;
        String remoteHost;
        String remotePort;
        String rowCount;
        String serverHost;
        String serverType;
        String serverVersion;
        String serviceName;
        String sessionId;
        String startTime;
        String statementId;
        String substatementId;
        String transactionId;
        String type;
    }

    class ActivityRecords {
        String type;
        String clusterId; // note that clusterId will contain an empty string on RDS Oracle and RDS SQL Server
        String instanceId;
        List<ActivityEvent> databaseActivityEventList;
    }

    static class RecordProcessorFactory implements IRecordProcessorFactory {
        @Override
        public IRecordProcessor createProcessor() {
            return new RecordProcessor();
        }
    }

    static class RecordProcessor implements IRecordProcessor {

        private static final long BACKOFF_TIME_IN_MILLIS = 3000L;
        private static final int PROCESSING_RETRIES_MAX = 10;
        private static final long CHECKPOINT_INTERVAL_MILLIS = 60000L;
        private static final Gson GSON = new GsonBuilder().serializeNulls().create();

        private static final Cipher CIPHER;
        static {
            Security.insertProviderAt(new BouncyCastleProvider(), 1);
            try {
                CIPHER = Cipher.getInstance("AES/GCM/NoPadding", "BC");
            } catch (NoSuchAlgorithmException | NoSuchPaddingException | NoSuchProviderException e) {
                throw new ExceptionInInitializerError(e);
            }
        }

        private long nextCheckpointTimeInMillis;

        @Override
        public void initialize(String shardId) {
        }

        @Override
        public void processRecords(final List<Record> records, final IRecordProcessorCheckpointer checkpointer) {
            for (final Record record : records) {
                processSingleBlob(record.getData());
            }

            if (System.currentTimeMillis() > nextCheckpointTimeInMillis) {
                checkpoint(checkpointer);
                nextCheckpointTimeInMillis = System.currentTimeMillis() + CHECKPOINT_INTERVAL_MILLIS;
            }
        }

        @Override
        public void shutdown(IRecordProcessorCheckpointer checkpointer, ShutdownReason reason) {
            if (reason == ShutdownReason.TERMINATE) {
                checkpoint(checkpointer);
            }
        }

        private void processSingleBlob(final ByteBuffer bytes) {
            try {
                // JSON $Activity
                final Activity activity = GSON.fromJson(new String(bytes.array(), StandardCharsets.UTF_8), Activity.class);

                // Base64.Decode
                final byte[] decoded = Base64.decode(activity.databaseActivityEvents);
                final byte[] decodedDataKey = Base64.decode(activity.key);

                Map<String, String> context = new HashMap<>();
                context.put("aws:rds:db-id", RESOURCE_ID);

                // Decrypt
                final DecryptRequest decryptRequest = new DecryptRequest()
                        .withCiphertextBlob(ByteBuffer.wrap(decodedDataKey)).withEncryptionContext(context);
                final DecryptResult decryptResult = KMS.decrypt(decryptRequest);
                final byte[] decrypted = decrypt(decoded, getByteArray(decryptResult.getPlaintext()));

                // GZip Decompress
                final byte[] decompressed = decompress(decrypted);
                // JSON $ActivityRecords
                final ActivityRecords activityRecords = GSON.fromJson(new String(decompressed, StandardCharsets.UTF_8), ActivityRecords.class);

                // Iterate throught $ActivityEvents
                for (final ActivityEvent event : activityRecords.databaseActivityEventList) {
                    System.out.println(GSON.toJson(event));
                }
            } catch (Exception e) {
                // Handle error.
                e.printStackTrace();
            }
        }

        private static byte[] decompress(final byte[] src) throws IOException {
            ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(src);
            GZIPInputStream gzipInputStream = new GZIPInputStream(byteArrayInputStream);
            return IOUtils.toByteArray(gzipInputStream);
        }

        private void checkpoint(IRecordProcessorCheckpointer checkpointer) {
            for (int i = 0; i < PROCESSING_RETRIES_MAX; i++) {
                try {
                    checkpointer.checkpoint();
                    break;
                } catch (ShutdownException se) {
                    // Ignore checkpoint if the processor instance has been shutdown (fail over).
                    System.out.println("Caught shutdown exception, skipping checkpoint." + se);
                    break;
                } catch (ThrottlingException e) {
                    // Backoff and re-attempt checkpoint upon transient failures
                    if (i >= (PROCESSING_RETRIES_MAX - 1)) {
                        System.out.println("Checkpoint failed after " + (i + 1) + "attempts." + e);
                        break;
                    } else {
                        System.out.println("Transient issue when checkpointing - attempt " + (i + 1) + " of " + PROCESSING_RETRIES_MAX + e);
                    }
                } catch (InvalidStateException e) {
                    // This indicates an issue with the DynamoDB table (check for table, provisioned IOPS).
                    System.out.println("Cannot save checkpoint to the DynamoDB table used by the Amazon Kinesis Client Library." + e);
                    break;
                }
                try {
                    Thread.sleep(BACKOFF_TIME_IN_MILLIS);
                } catch (InterruptedException e) {
                    System.out.println("Interrupted sleep" + e);
                }
            }
        }
    }

    private static byte[] decrypt(final byte[] decoded, final byte[] decodedDataKey) throws IOException {
        // Create a JCE master key provider using the random key and an AES-GCM encryption algorithm
        final JceMasterKey masterKey = JceMasterKey.getInstance(new SecretKeySpec(decodedDataKey, "AES"),
                "BC", "DataKey", "AES/GCM/NoPadding");
        try (final CryptoInputStream<JceMasterKey> decryptingStream = CRYPTO.createDecryptingStream(masterKey, new ByteArrayInputStream(decoded));
             final ByteArrayOutputStream out = new ByteArrayOutputStream()) {
            IOUtils.copy(decryptingStream, out);
            return out.toByteArray();
        }
    }

    public static void main(String[] args) throws Exception {
        final String workerId = InetAddress.getLocalHost().getCanonicalHostName() + ":" + UUID.randomUUID();
        final KinesisClientLibConfiguration kinesisClientLibConfiguration =
                new KinesisClientLibConfiguration(APPLICATION_NAME, STREAM_NAME, CREDENTIALS_PROVIDER, workerId);
        kinesisClientLibConfiguration.withInitialPositionInStream(InitialPositionInStream.LATEST);
        kinesisClientLibConfiguration.withRegionName(REGION_NAME);
        final Worker worker = new Builder()
                .recordProcessorFactory(new RecordProcessorFactory())
                .config(kinesisClientLibConfiguration)
                .build();

        System.out.printf("Running %s to process stream %s as worker %s...\n", APPLICATION_NAME, STREAM_NAME, workerId);

        try {
            worker.run();
        } catch (Throwable t) {
            System.err.println("Caught throwable while processing data.");
            t.printStackTrace();
            System.exit(1);
        }
        System.exit(0);
    }

    private static byte[] getByteArray(final ByteBuffer b) {
        byte[] byteArray = new byte[b.remaining()];
        b.get(byteArray);
        return byteArray;
    }
}
```

------
#### [ Python ]

```
import base64
import json
import zlib
import aws_encryption_sdk
from aws_encryption_sdk import CommitmentPolicy
from aws_encryption_sdk.internal.crypto import WrappingKey
from aws_encryption_sdk.key_providers.raw import RawMasterKeyProvider
from aws_encryption_sdk.identifiers import WrappingAlgorithm, EncryptionKeyType
import boto3

REGION_NAME = '<region>'                    # us-east-1
RESOURCE_ID = '<external-resource-id>'      # db-ABCD123456
STREAM_NAME = 'aws-rds-das-' + RESOURCE_ID  # aws-rds-das-db-ABCD123456

enc_client = aws_encryption_sdk.EncryptionSDKClient(commitment_policy=CommitmentPolicy.FORBID_ENCRYPT_ALLOW_DECRYPT)

class MyRawMasterKeyProvider(RawMasterKeyProvider):
    provider_id = "BC"

    def __new__(cls, *args, **kwargs):
        obj = super(RawMasterKeyProvider, cls).__new__(cls)
        return obj

    def __init__(self, plain_key):
        RawMasterKeyProvider.__init__(self)
        self.wrapping_key = WrappingKey(wrapping_algorithm=WrappingAlgorithm.AES_256_GCM_IV12_TAG16_NO_PADDING,
                                        wrapping_key=plain_key, wrapping_key_type=EncryptionKeyType.SYMMETRIC)

    def _get_raw_key(self, key_id):
        return self.wrapping_key


def decrypt_payload(payload, data_key):
    my_key_provider = MyRawMasterKeyProvider(data_key)
    my_key_provider.add_master_key("DataKey")
    decrypted_plaintext, header = enc_client.decrypt(
        source=payload,
        materials_manager=aws_encryption_sdk.materials_managers.default.DefaultCryptoMaterialsManager(master_key_provider=my_key_provider))
    return decrypted_plaintext


def decrypt_decompress(payload, key):
    decrypted = decrypt_payload(payload, key)
    return zlib.decompress(decrypted, zlib.MAX_WBITS + 16)


def main():
    session = boto3.session.Session()
    kms = session.client('kms', region_name=REGION_NAME)
    kinesis = session.client('kinesis', region_name=REGION_NAME)

    response = kinesis.describe_stream(StreamName=STREAM_NAME)
    shard_iters = []
    for shard in response['StreamDescription']['Shards']:
        shard_iter_response = kinesis.get_shard_iterator(StreamName=STREAM_NAME, ShardId=shard['ShardId'],
                                                         ShardIteratorType='LATEST')
        shard_iters.append(shard_iter_response['ShardIterator'])

    while len(shard_iters) > 0:
        next_shard_iters = []
        for shard_iter in shard_iters:
            response = kinesis.get_records(ShardIterator=shard_iter, Limit=10000)
            for record in response['Records']:
                record_data = record['Data']
                record_data = json.loads(record_data)
                payload_decoded = base64.b64decode(record_data['databaseActivityEvents'])
                data_key_decoded = base64.b64decode(record_data['key'])
                data_key_decrypt_result = kms.decrypt(CiphertextBlob=data_key_decoded,
                                                      EncryptionContext={'aws:rds:db-id': RESOURCE_ID})
                print (decrypt_decompress(payload_decoded, data_key_decrypt_result['Plaintext']))
            if 'NextShardIterator' in response:
                next_shard_iters.append(response['NextShardIterator'])
        shard_iters = next_shard_iters


if __name__ == '__main__':
    main()
```

------

# Exemples de politique IAM pour les flux d’activité de base de données
<a name="DBActivityStreams.ManagingAccess"></a>

Tout utilisateur disposant des privilèges de rôle Gestion des identités et des accès AWS (IAM) appropriés pour les flux d'activité de base de données peut créer, démarrer, arrêter et modifier les paramètres des flux d'activité pour une instance de base de données de  de base de données. Ces actions sont consignées dans le journal d’audit du flux. Pour des raisons de conformité optimales, nous vous recommandons de ne pas octroyer ces privilèges à DBAs.

Vous devrez paramétrer les accès aux flux d’activité de base de données à l’aide de politiques IAM. Pour plus d’informations sur l’authentification Amazon RDS, consultez [Identity and Access Management pour Amazon RDS](UsingWithRDS.IAM.md). Pour plus d’informations sur la création des stratégies IAM, consultez [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). 

**Example politique pour autoriser la configuration de Database Activity Streams**  
Pour donner aux utilisateurs des accès précis en vue de modifier les flux d’activité, utilisez les clés de contexte d’opération spécifiques au service `rds:StartActivityStream` et `rds:StopActivityStream` dans une stratégie IAM. L’exemple de politique IAM suivant autorise un utilisateur ou un rôle à configurer des flux d’activité.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ConfigureActivityStreams",
            "Effect": "Allow",
            "Action": [
                "rds:StartActivityStream",
                "rds:StopActivityStream"
            ],
            "Resource": "*"
        }
    ]
}
```

**Example politique pour autoriser le démarrage de Database Activity Streams**  
L’exemple de politique IAM suivant autorise un utilisateur ou un rôle à démarrer des flux d’activité.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement":[
        {
            "Sid":"AllowStartActivityStreams",
            "Effect":"Allow",
            "Action":"rds:StartActivityStream",
            "Resource":"*"
        }
    ]
}
```

**Example politique pour autoriser l’arrêt de Database Activity Streams**  
L’exemple de politique IAM suivant autorise un utilisateur ou un rôle à arrêter des flux d’activité.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement":[
        {
            "Sid":"AllowStopActivityStreams",
            "Effect":"Allow",
            "Action":"rds:StopActivityStream",
            "Resource":"*"
        }
     ]
}
```

**Example politique pour refuser le démarrage de Database Activity Streams**  
La politique IAM suivante empêche un utilisateur ou un rôle de démarrer des flux d’activité.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement":[
        {
            "Sid":"DenyStartActivityStreams",
            "Effect":"Deny",
            "Action":"rds:StartActivityStream",
            "Resource":"*"
        }
     ]
}
```

**Example politique pour refuser l’arrêt de Database Activity Streams**  
La politique IAM suivante empêche un utilisateur ou un rôle d’arrêter des flux d’activité.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement":[
        {
            "Sid":"DenyStopActivityStreams",
            "Effect":"Deny",
            "Action":"rds:StopActivityStream",
            "Resource":"*"
        }
    ]
}
```

# Surveillance des menaces avec Amazon GuardDuty RDS Protection
<a name="guard-duty-rds-protection"></a>

Amazon GuardDuty est un service de détection des menaces qui aide à protéger vos comptes, vos conteneurs, vos charges de travail et les données de votre AWS environnement. À l'aide de modèles d'apprentissage automatique (ML) et de capacités de détection des anomalies et des menaces, vous surveillez GuardDuty en permanence les différentes sources de journaux et l'activité d'exécution afin d'identifier et de hiérarchiser les risques de sécurité potentiels et les activités malveillantes dans votre environnement.

GuardDuty RDS Protection analyse et établit le profil des événements de connexion pour détecter les menaces d'accès potentielles à vos bases de données Amazon RDS. Lorsque vous activez la protection RDS, GuardDuty consomme les événements de connexion RDS de vos bases de données RDS. RDS Protection surveille ces événements et en établit le profil pour détecter les menaces potentielles de l’intérieur ou des acteurs externes.

Pour plus d'informations sur l'activation de la protection GuardDuty RDS, consultez la section [Protection GuardDuty RDS](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html) dans le guide de * GuardDuty l'utilisateur Amazon*.

Lorsque RDS Protection détecte une menace potentielle, telle qu'un schéma inhabituel de tentatives de connexion réussies ou échouées, GuardDuty génère une nouvelle découverte contenant des informations détaillées sur la base de données potentiellement compromise. Vous pouvez consulter les détails de la recherche dans la section récapitulative des résultats de la GuardDuty console Amazon. Les détails des résultats varient en fonction du type de découverte. Les principaux détails, le type de ressource et le rôle de la ressource, déterminent le type d’informations disponibles pour toute recherche. Pour plus d'informations sur les informations couramment disponibles pour les résultats et les types de résultats, consultez les sections [Détails de recherche](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings-summary.html) et [types de résultats GuardDuty RDS Protection](https://docs.aws.amazon.com/guardduty/latest/ug/findings-rds-protection.html) respectivement dans le *guide de l' GuardDuty utilisateur Amazon*. 

Vous pouvez activer ou désactiver la fonction de protection RDS Compte AWS partout Région AWS où elle est disponible. Lorsque la protection RDS n'est pas activée, GuardDuty elle ne détecte pas les bases de données RDS potentiellement compromises et ne fournit pas de détails sur la compromission.

Un GuardDuty compte existant peut activer RDS Protection avec une période d'essai de 30 jours. Pour un nouveau GuardDuty compte, la protection RDS est déjà activée et incluse dans la période d'essai gratuite de 30 jours. Pour plus d'informations, consultez la section [Estimation GuardDuty des coûts](https://docs.aws.amazon.com/guardduty/latest/ug/monitoring_costs.html) dans le *guide de GuardDuty l'utilisateur Amazon*.

Pour plus d'informations sur l' Régions AWS endroit où la protection RDS GuardDuty n'est pas encore prise en charge, consultez la section [Disponibilité des fonctionnalités spécifiques à chaque région dans le guide](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_regions.html#gd-regional-feature-availability) de l'utilisateur *Amazon GuardDuty *.

*Pour plus d'informations sur les versions de base de données RDS [prises en charge par GuardDuty RDS Protection, consultez la section Bases de données Amazon Aurora, Amazon RDS et Aurora Limitless prises en charge dans](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html#rds-pro-supported-db) le guide de l'utilisateur Amazon. GuardDuty *