View a markdown version of this page

Surveillance des flux - Amazon Aurora DSQL
Cycle de vie du streamRésolution des problèmes liés à un flux altéré ou défaillantRéférence du code d'erreurRécupération d'un flux altéréSurveillance de l'état du fluxCloudWatch métriques pour les flux CDCSurveillance des meilleures pratiques

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. Pour en savoir plus sur la tarification des flux CDC, consultez la page de tarification d'Aurora DSQL.

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 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.

  • 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 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 unResourceNotFoundException.

Appelez GetStream pour voir l'état de la diffusion à tout moment. Lorsque le flux est IMPAIRED ouFAILED, 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 GetStreammanuel 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 casFAILED, 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 casACTIVE, le flux est sain.

    aws dsql get-stream \
  --cluster-identifier cluster-id \
  --stream-identifier stream-id \
  --region region

  2. Lisez le code d'erreur. Si le statut est IMPAIRED ouFAILED, 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"
    }
}

  3. Suivez les mesures correctives. Si c'est le casIMPAIRED, 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 casFAILED, 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. 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. 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 GetStreamle manuel Amazon Aurora DSQL API Reference.

Récupération d'un flux altéré

La plupart des erreurs font d'abord passer le flux versIMPAIRED. 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é versACTIVE. 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'GetStreamAPI 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 IsImpairedBehindSourceLag,PublishedBytes, etPublishedRecords, voirCloudWatch métriques pour les flux CDC. Pour plus de détails sur les champs de GetStream réponse, consultez le GetStreammanuel 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, voirMétriques des flux du CDC.

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.IteratorAgeMillisecondscô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 dimensionStreamName) 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 PublishedBytespar 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 IsImpairedpour 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

Sondage GetStreampour connaître le statut détaillé

La IsImpaired métrique indique qu'un flux est altéré, mais l'GetStreamAPI fournit le code d'erreur et l'horodatage spécifiques. GetStreamEffectuez 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 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 IsImpairedBehindSourceLag,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 hausseBehindSourceLag) et un problème de lecture en aval (en hausse IteratorAge avec stableBehindSourceLag).