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.
# Surveillance des flux
**Important**
Cette fonctionnalité est fournie sous forme d' AWS aperçu et est sujette à modification. Pour plus d'informations, consultez la section 2, Bêtas et aperçus, des conditions de [AWS service](https://aws.amazon.com/service-terms/). Pour en savoir plus sur la tarification des flux CDC, consultez la [page de tarification d'Aurora DSQL](https://aws.amazon.com/rds/aurora/dsql/pricing/).
Avant la mise à disposition générale, nous ajouterons de nouveaux types d'opérations (`"op": "u"`pour les mises à jour) à votre charge utile de diffusion. Pour vous assurer que votre application gère ces modifications sans modification, considérez toute valeur non reconnue comme une `op` valeur ajoutée en appliquant la `after` charge utile. Consultez [Comprendre les dossiers du CDC](cdc-record-format.md) pour plus de détails.
Lorsqu'Aurora DSQL rencontre une erreur lors de la livraison d'un enregistrement CDC, le flux passe à l'`IMPAIRED`état. Un flux altéré continue de traiter et de fournir d'autres enregistrements : Aurora DSQL réessaie uniquement l'enregistrement défaillant. Aurora DSQL mesure le délai de réplication à partir du plus ancien enregistrement non livré, et ce délai augmente jusqu'à ce que vous résolviez le problème. Aurora DSQL conserve les modifications non livrées en interne pendant une semaine.
Si vous résolvez le problème sous-jacent dans cette fenêtre, la prochaine tentative aboutit, l'état d'erreur disparaît et le flux revient à. `ACTIVE` Corrigez le problème externe (politique IAM, AWS KMS clé, capacité Amazon Kinesis, etc.) et Aurora DSQL réessaiera automatiquement.
Si le délai de réplication dépasse le seuil d'échec, le flux passe à`FAILED`.
**Important**
Un flux défaillant ne peut pas être rétabli. Vous devez supprimer le flux défaillant et en créer un nouveau.
## Cycle de vie du stream
Un flux passe par les états suivants au cours de son cycle de vie :
+ **`CREATING`**— Aurora DSQL est en train de configurer le flux. Aurora DSQL ne fournit pas encore d'enregistrements CDC.
+ **`ACTIVE`**— Le flux est opérationnel et fournit les dossiers du CDC à la cible.
+ **`IMPAIRED`**— Le stream a rencontré un problème qui nécessite votre intervention. Aurora DSQL réessaie l'enregistrement défaillant avec un retard exponentiel, bien que d'autres enregistrements puissent continuer à être livrés. Aurora DSQL mesure le délai de réplication à partir du plus ancien enregistrement non livré, et ce délai augmente jusqu'à ce que vous résolviez le problème. Aurora DSQL met en mémoire tampon les modifications non livrées en interne pendant une semaine. Consultez [Référence du code d'erreur](#cdc-failure-reasons).
+ **`FAILED`**— Le flux a rencontré une erreur persistante et ne fournit plus d'enregistrements du CDC. Un flux défaillant ne peut pas être récupéré et vous devez le supprimer. Consultez [Référence du code d'erreur](#cdc-failure-reasons) les conditions qui font qu'un cours d'eau entre dans cet état.
+ **`DELETING`**— Aurora DSQL supprime les ressources de flux.
+ **`DELETED`**— Aurora DSQL a supprimé le flux. Une fois la suppression terminée, `GetStream` renvoie un`ResourceNotFoundException`.
Appelez `GetStream` pour voir l'état de la diffusion à tout moment. Lorsque le flux est `IMPAIRED` ou`FAILED`, la réponse inclut un `statusReason` objet avec le code d'erreur et l'horodatage. Pour plus de détails sur les champs de `GetStream` réponse, consultez le [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)manuel Amazon Aurora DSQL API Reference.
## Résolution des problèmes liés à un flux altéré ou défaillant
Suivez ces étapes lorsqu'un flux CDC est altéré ou échoue. Si c'est le cas`FAILED`, vous ne pouvez pas le récupérer. Supprimez-le, résolvez le problème sous-jacent et créez-en un nouveau.
1. **Obtenez le statut du stream.** Appelez `GetStream` et vérifiez le `status` champ. Si le statut est le cas`ACTIVE`, le flux est sain.
```
aws dsql get-stream \
--cluster-identifier {{cluster-id}} \
--stream-identifier {{stream-id}} \
--region {{region}}
```
1. **Lisez le code d'erreur.** Si le statut est `IMPAIRED` ou`FAILED`, la réponse inclut un `statusReason` objet. Le `error` champ contient le code d'erreur.
```
{
"status": "IMPAIRED",
"statusReason": {
"error": "KINESIS_THROUGHPUT_EXCEEDED",
"updatedAt": "2025-01-15T14:30:00Z"
}
}
```
1. **Suivez les mesures correctives.** Si c'est le cas`IMPAIRED`, recherchez le code d'erreur dans le tableau suivant et appliquez le correctif recommandé. Aurora DSQL réessaie automatiquement une fois que vous avez résolu le problème sous-jacent. Si c'est le cas`FAILED`, supprimez-le, résolvez le problème et créez un nouveau flux.
## Référence du code d'erreur
Le tableau suivant décrit chaque code d'erreur, sa cause, si le flux peut être rétabli et les étapes à suivre pour le résoudre.
| Code d’erreur | Cause | Récupérable ? | Comment résoudre |
| --- |--- |--- |--- |
| KINESIS\_THROUGHPUT\_EXCEEDED | Votre flux de données Kinesis a dépassé sa limite de débit ou a limité les opérations de AWS KMS chiffrement sur le flux de données Kinesis, et le délai de réplication s'est accru. | Oui | Augmentez le nombre de partitions dans votre flux de données Kinesis ou passez en mode capacité à la demande. Si le flux de données Kinesis utilise une clé gérée par AWS KMS le client, vérifiez que le quota de demandes de la clé est suffisamment élevé. Une fois que vous avez augmenté la capacité, Aurora DSQL réessaie automatiquement. |
| KINESIS\_STREAM\_NOT\_FOUND | Le flux de données Kinesis cible n'existe plus. | Non | Le flux passe directement àFAILED. Supprimez le flux CDC et créez-en un nouveau pointant vers un flux de données Kinesis valide. |
| ROLE\_ACCESS\_DENIED | Aurora DSQL ne peut pas assumer le rôle IAM spécifié dans la définition de la cible. L' AWS STS AssumeRoleappel est revenuAccessDenied. | Oui | Vérifiez que la politique de confiance du rôle autorise le principal du service Aurora DSQL (dsql.amazonaws.com) à l'assumer. Vérifiez que les aws:SourceArn conditions aws:SourceAccount et conditions correspondent à votre cluster. Pour en savoir plus, consultez [Politique de confiance relative aux rôles de service](cdc-iam.md#cdc-iam-trust-policy). Une fois que vous avez corrigé la politique de confiance, Aurora DSQL réessaie automatiquement. |
| KINESIS\_ACCESS\_DENIED | Le rôle assumé n'est pas autorisé à écrire dans le flux de données Kinesis. Kinesis est de retour. AccessDeniedException | Oui | Ajoutez kinesis:PutRecord et kinesis:PutRecords autorisez la politique du rôle pour le flux de données Kinesis cible Amazon Resource Name (ARN). Une fois que vous avez corrigé la politique, Aurora DSQL réessaie automatiquement. |
| KINESIS\_KMS\_ACCESS\_DENIED | Le rôle assumé n'est pas autorisé à utiliser la AWS KMS clé qui chiffre le flux de données Kinesis. Cette erreur concerne le refus AWS KMS d'accès et les états de clé non valides. | Oui | Vérifiez que le rôle dispose kms:GenerateDataKey d'une autorisation sur la AWS KMS clé utilisée par le flux de données Kinesis. Vérifiez également que l'état de la AWS KMS clé est activé et valide. Cette clé est la clé de chiffrement du flux de données Kinesis, et non la clé du AWS KMS cluster. Pour en savoir plus, consultez [Politique d'autorisation des rôles de service](cdc-iam.md#cdc-iam-permissions-policy). Une fois que vous avez corrigé les autorisations ou l'état de la clé, Aurora DSQL réessaie automatiquement. |
| KINESIS\_OVERSIZE\_RECORD | Un enregistrement CDC a dépassé la taille d'enregistrement maximale configurée sur le flux de données Kinesis. | Oui | Augmentez MaxRecordSizeInKiB le flux de données Kinesis à 10240 (10 MiB). Vous pouvez mettre à jour ce paramètre sur un flux de données Kinesis existant sans le supprimer. Après avoir augmenté la limite, Aurora DSQL réessaie automatiquement l'enregistrement surdimensionné et le flux revient à. ACTIVE |
| CLUSTER\_CMK\_INACCESSIBLE | La clé gérée par le AWS KMS client qui chiffre le cluster Aurora DSQL est inaccessible. | Oui | Vérifiez la politique AWS KMS clé et l'état de la clé. Re-enable ou restaurez l'accès à la clé. Une fois que la clé est de nouveau accessible, le stream revient àACTIVE. |
Le tableau précédent répertorie toutes les `StreamFailureErrorCode` valeurs. Pour en savoir plus sur le champ de `statusReason` réponse, consultez [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)le manuel [Amazon Aurora DSQL API Reference](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_api_reference.html).
## Récupération d'un flux altéré
La plupart des erreurs font d'abord passer le flux vers`IMPAIRED`. Un flux altéré continue de traiter les autres enregistrements et réessaie automatiquement l'enregistrement défaillant. Un `FAILED` flux n'est pas récupérable. Vous devez le supprimer et en créer un nouveau.
+ **Pour les erreurs récupérables :** corrigez le problème externe (politique IAM, clé AWS KMS , capacité Kinesis ou limite de taille d'enregistrement Kinesis). La prochaine tentative réussie efface l'état d'erreur et fait revenir le flux à. `ACTIVE`
+ **Pour `KINESIS_STREAM_NOT_FOUND` :** le stream passe directement à`FAILED`. Supprimez le flux défaillant et créez-en un nouveau pointant vers un flux de données Kinesis valide.
Pour tous les autres codes d'erreur, si le délai de réplication dépasse le seuil d'échec avant que vous ne résolviez le problème, le flux passe de `IMPAIRED` à`FAILED`. Un stream qui a échoué ne peut pas être redirigé vers`ACTIVE`. Supprimez le flux défaillant, résolvez le problème sous-jacent et créez-en un nouveau.
## Surveillance de l'état du flux
Utilisez CloudWatch les métriques et l'`GetStream`API pour surveiller l'état du stream. CloudWatchles métriques fournissent une visibilité continue sur les performances du pipeline CDC et `GetStream` fournissent le code d'erreur spécifique lorsqu'un flux est altéré ou échoue.
Pour la liste complète des indicateurs du CDC, y compris `IsImpaired``BehindSourceLag`,`PublishedBytes`, et`PublishedRecords`, voir[CloudWatch métriques pour les flux CDC](#cdc-cloudwatch-metrics). Pour plus de détails sur les champs de `GetStream` réponse, consultez le [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)manuel Amazon Aurora DSQL API Reference.
## CloudWatch métriques pour les flux CDC
Utilisez les CloudWatch mesures suivantes pour surveiller l'état et le débit de chaque flux CDC. Aurora DSQL publie ces métriques dans l'espace de `AWS/AuroraDSQL` noms avec les dimensions `ClusterId` et. `StreamId` La dernière métrique est une métrique Amazon Kinesis standard dans l'espace de `AWS/Kinesis` noms qui mesure le délai de lecture en aval.
**Note**
Aurora DSQL publie également les `StreamDPU` métriques `BytesStreamed` et dans l'espace de `AWS/AuroraDSQL` noms pour le suivi de l'utilisation et de la facturation. Pour les descriptions, voir[Métriques des flux du CDC](cloudwatch-monitoring.md#cdc-stream-metrics).
| Nom de la métrique | Statistique utile | Description |
| --- |--- |--- |
| IsImpaired | Maximum | Indique si le flux est altéré. La valeur est 1 lorsque le flux est dans l'IMPAIREDétat et 0 lorsqu'il est sain. Aurora DSQL émet cette métrique en continu pour chaque flux actif ou altéré. Utilisez cette métrique pour créer une CloudWatch alarme qui vous avertit lorsqu'un stream est perturbé. |
| BehindSourceLag | Moyenne | Délai, en millisecondes, entre le moment où une transaction est validée dans Aurora DSQL et le moment où le système CDC traite l'enregistrement obtenu. Une valeur croissante indique que le pipeline CDC est en retard par rapport à la charge de travail d'écriture. |
| PublishedBytes | Somme | Nombre total d'octets d'enregistrements CDC qu'Aurora DSQL a écrits sur la cible au cours de cette période. Utilisez cette métrique avec le nombre de partitions Kinesis pour déterminer si vous avez alloué une capacité d'écriture suffisante. |
| PublishedRecords | Somme | Nombre total d'enregistrements CDC qu'Aurora DSQL a écrits sur la cible au cours de la période. Chaque modification de ligne validée produit un enregistrement. |
| GetRecords.IteratorAgeMilliseconds (AWS/Kinesis) | Moyenne | Mesure Kinesis standard qui indique l'âge du dernier enregistrement lu à partir du flux de données Kinesis par votre application en aval, en millisecondes. Utilisez la StreamName dimension. Une valeur croissante indique que votre application en aval ne parvient pas à suivre le rythme auquel Aurora DSQL écrit des enregistrements CDC dans Kinesis. |
L'onglet **Surveillance** de la console Aurora DSQL affiche une valeur de latence **moyenne de bout en bout qui combine `BehindSourceLag` (latence** de la source CDC) et (retard du lecteur `GetRecords.IteratorAgeMilliseconds` Kinesis). Cette valeur combinée représente le délai total entre la validation de la base de données et la lecture en aval.
## Surveillance des meilleures pratiques
Utilisez les pratiques suivantes pour détecter et résoudre les problèmes de pipeline CDC avant qu'ils n'affectent vos systèmes en aval.
**Activez les alarmes `BehindSourceLag`**
Créez une CloudWatch alarme qui se déclenche lorsque vous `BehindSourceLag` dépassez un seuil important pour votre charge de travail. Par exemple, définissez 60 secondes pour un objectif de latence d'une minute. Une augmentation soutenue de cet indicateur signifie que le pipeline des CDC prend du retard. Si le décalage atteint le seuil d'échec, le flux passe en mode FAILED. Si vous suivez la tendance, vous avez le temps d'augmenter la capacité de Kinesis ou d'étudier les problèmes de débit avant que le flux ne se dégrade.
**Moniteur `GetRecords.IteratorAgeMilliseconds`côté Kinesis**
Même lorsqu'Aurora DSQL fournit les enregistrements à temps, votre application en aval peut prendre du retard. Créez une CloudWatch alarme activée `GetRecords.IteratorAgeMilliseconds` (dans l'espace de `AWS/Kinesis` noms, dans la dimension`StreamName`) pour détecter le décalage en aval de manière indépendante. Si cette métrique augmente et `BehindSourceLag` reste stable, le goulot d'étranglement se situe dans votre application en aval, et non dans Aurora DSQL.
**Effectuez le suivi `PublishedBytes`par rapport à la capacité de partage de Kinesis**
Chaque partition Kinesis prend en charge jusqu'à 1 MiB par seconde pour les écritures. Comparez la `PublishedBytes` somme par minute à la capacité d'écriture totale de votre partition (nombre de partitions × 60 MiB par minute). Si l'utilisation approche les 80 %, ajoutez des partitions ou passez en mode capacité à la demande avant de limiter les déclencheurs. `KINESIS_THROUGHPUT_EXCEEDED`
**Alarme activée `IsImpaired`pour une détection instantanée des déficiences**
Créez une CloudWatch alarme qui se déclenche lorsque le `IsImpaired` maximum est supérieur ou égal à `1` pendant une période d'évaluation. Cela vous donne un signal direct lorsqu'un flux entre dans l'`IMPAIRED`état, sans interroger l'API. Une fois l'alarme déclenchée, appelez `GetStream` pour lire le `statusReason.error` champ et suivez les étapes de correction. [Résolution des problèmes liés à un flux altéré ou défaillant](#cdc-troubleshooting)
**Sondage `GetStream`pour connaître le statut détaillé**
La `IsImpaired` métrique indique qu'un flux est altéré, mais l'`GetStream`API fournit le code d'erreur et l'horodatage spécifiques. `GetStream`Effectuez un sondage selon un calendrier (par exemple, toutes les cinq minutes) ou en réponse à une `IsImpaired` alarme. Le `statusReason.error` champ vous indique ce qui s'est mal passé. Associez-le aux étapes de dépannage [Résolution des problèmes liés à un flux altéré ou défaillant](#cdc-troubleshooting) pour une résolution rapide.
**Utilisez des tableaux de bord pour corréler les métriques**
Créez un CloudWatch tableau de bord qui affiche `IsImpaired``BehindSourceLag`,`PublishedRecords`,`PublishedBytes`, et `GetRecords.IteratorAgeMilliseconds` côte à côte. La corrélation de ces indicateurs vous permet de faire la distinction entre un problème de pipeline des CDC (en hausse`BehindSourceLag`) et un problème de lecture en aval (en hausse `IteratorAge` avec stable`BehindSourceLag`).