View a markdown version of this page

Supervisión de flujos - Amazon Aurora DSQL
Ciclo de vida del flujoSolución de problemas de un flujo dañado o con errorReferencia de códigos de errorRecuperación de un flujo dañadoSupervisión del estado el flujoMétricas de CloudWatch para los flujos de CDCPrácticas recomendadas de supervisión

Supervisión de flujos

importante

Esta característica se ofrece como versión preliminar de AWS y está sujeta a cambios. Para obtener más información, consulte la sección 2, Betas y versiones preliminares, del documento Términos de servicio de AWS. Para obtener más información acerca de los precios de los flujos de CDC, visite la página Precios de Amazon Aurora DSQL.

Antes de la disponibilidad general, añadiremos nuevos tipos de operaciones ("op": "u" para actualizaciones) a la carga útil de su flujo. Para garantizar que su aplicación gestione estos cambios sin necesidad de modificaciones, trate cualquier valor op no reconocido como una operación upsert aplicando la carga útil after. Para obtener más información, consulte Descripción de los registros de CDC.

Cuando Aurora DSQL detecta un error al entregar un registro de CDC, el flujo pasa al estado IMPAIRED. Un flujo dañado continúa procesando y entregando otros registros; Aurora DSQL reintenta solo el registro que ha fallado. Aurora DSQL mide el retardo de replicación a partir del registro más antiguo sin entregar, y dicho retardo aumenta hasta que se resuelva el problema. Aurora DSQL conserva internamente los cambios sin entregar durante una semana.

Si resuelve el problema subyacente en este plazo, el siguiente intento se realizará correctamente, el estado de error se borrará y el flujo volverá a ser ACTIVE. Solucione el problema externo (política de IAM, clave de AWS KMS, capacidad de Amazon Kinesis, etc.) y Aurora DSQL lo volverá a intentar automáticamente.

Si el retardo de replicación supera el umbral de error, el flujo pasa a FAILED.

importante

Un flujo con error no se puede recuperar. Debe eliminar el flujo con error y crear uno nuevo.

Ciclo de vida del flujo

Un flujo pasa por los siguientes estados durante su ciclo de vida:

  • CREATING: Aurora DSQL está configurando el flujo. Aurora DSQL aún no entrega los registros de CDC.

  • ACTIVE: el flujo está operativo y envía los registros de CDC al destino.

  • IMPAIRED: el flujo ha detectado un problema que requiere que tome medidas. Aurora DSQL vuelve a intentar el registro con error con un retroceso exponencial, aunque otros registros pueden seguir entregándose. Aurora DSQL mide el retardo de replicación a partir del registro más antiguo sin entregar, y dicho retardo aumenta hasta que se resuelva el problema. Aurora DSQL almacena en búfer los cambios sin entregar durante una semana. Consulte Referencia de códigos de error.

  • FAILED: el flujo ha detectado un error persistente y ya no entrega los registros de CDC. Un flujo con error no se puede recuperar y debe eliminarlo. Consulte Referencia de códigos de error para ver las condiciones que hacen que un flujo entre en este estado.

  • DELETING: Aurora DSQL está eliminando los recursos del flujo.

  • DELETED: Aurora DSQL ha eliminado el flujo. Una vez completada la eliminación, GetStream devuelve una ResourceNotFoundException.

Llame a GetStream para ver el estado del flujo en cualquier momento. Cuando el flujo es IMPAIRED o FAILED, la respuesta incluye un objeto statusReason con el código de error y la marca de tiempo. Para obtener más información sobre los campos de respuesta GetStream, consulte GetStream en la Referencia de la API de Amazon Aurora DSQL.

Solución de problemas de un flujo dañado o con error

Siga estos pasos cuando un flujo de CDC se dañe o produzca un error. Si el flujo tiene el estado FAILED, no podrá recuperarlo. Elimine el flujo, resuelva el problema subyacente y cree uno nuevo.

  1. Obtenga el estado del flujo. Llame a GetStream y verifique el campo status. Si el estado es ACTIVE, el flujo está en buen estado.

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

  2. Lea el código de error. Si el estado es IMPAIRED o FAILED, la respuesta incluye un objeto statusReason. El campo error contiene el código de error.

    {
    "status": "IMPAIRED",
    "statusReason": {
        "error": "KINESIS_THROUGHPUT_EXCEEDED",
        "updatedAt": "2025-01-15T14:30:00Z"
    }
}

  3. Siga el proceso de corrección. Si el flujo es IMPAIRED, busque el código de error en la siguiente tabla y aplique la solución recomendada. Aurora DSQL vuelve a intentarlo automáticamente después de resolver el problema subyacente. Si el flujo es FAILED, elimínelo, resuelva el problema y cree un nuevo flujo.

Referencia de códigos de error

En la siguiente tabla se explica cada código de error, su causa, si el flujo se puede recuperar y los pasos para resolverlo.

Código de error Causa ¿Es recuperable? Cómo resolverlo
KINESIS_THROUGHPUT_EXCEEDED Your Kinesis data stream exceeded its throughput limit, or AWS KMS throttled encryption operations on the Kinesis data stream, and the replication lag has grown. Yes Increase the number of shards on your Kinesis data stream, or switch to on-demand capacity mode. If the Kinesis data stream uses an AWS KMS customer managed key, verify that the key's request quota is large enough. After you increase capacity, Aurora DSQL retries automatically.
KINESIS_STREAM_NOT_FOUND The target Kinesis data stream no longer exists. No The stream transitions directly to ERROR. Delete the CDC stream and create a new one pointing to a valid Kinesis data stream.
ROLE_ACCESS_DENIED Aurora DSQL can't assume the IAM role specified in the target definition. The AWS STS AssumeRole call returned AccessDenied. Yes Verify the role's trust policy allows the Aurora DSQL service principal (dsql.amazonaws.com) to assume it. Verify the aws:SourceAccount and aws:SourceArn conditions match your cluster. For details, see Política de confianza del rol de servicio. After you fix the trust policy, Aurora DSQL retries automatically.
KINESIS_ACCESS_DENIED The assumed role doesn't have permission to write to the Kinesis data stream. Kinesis returned AccessDeniedException. Yes Add kinesis:PutRecord and kinesis:PutRecords permissions to the role's policy for the target Kinesis data stream Amazon Resource Name (ARN). After you fix the policy, Aurora DSQL retries automatically.
KINESIS_KMS_ACCESS_DENIED The assumed role doesn't have permission to use the AWS KMS key that encrypts the Kinesis data stream. This error covers AWS KMS access denial and invalid key states. Yes Verify the role has kms:GenerateDataKey permission on the AWS KMS key that the Kinesis data stream uses. Also verify that the AWS KMS key is in an enabled and valid state. This key is the encryption key on the Kinesis data stream, not the cluster's AWS KMS key. For details, see Política de permisos de roles de servicio. After you fix the permissions or key state, Aurora DSQL retries automatically.
KINESIS_OVERSIZE_RECORD A CDC record exceeded the maximum record size configured on the Kinesis data stream. Yes Increase MaxRecordSizeInKiB on the Kinesis data stream to 10240 (10 MiB). You can update this setting on an existing Kinesis data stream without deleting it. After you increase the limit, Aurora DSQL retries the oversized record automatically and the stream transitions back to ACTIVE.
CLUSTER_CMK_INACCESSIBLE The AWS KMS customer managed key that encrypts the Aurora DSQL cluster is inaccessible. Yes Verify the AWS KMS key policy and key state. Re-enable or restore access to the key. After the key becomes accessible again, the stream transitions back to ACTIVE.

La tabla anterior muestra todos los valores de StreamFailureErrorCode. Para obtener más información sobre el campo de respuesta statusReason, consulte GetStream en la Referencia de la API de Amazon Aurora DSQL.

Recuperación de un flujo dañado

La mayoría de los errores primero pasan el flujo al estado IMPAIRED. Un flujo dañado continúa procesando otros registros y reintenta automáticamente el registro que ha fallado. Un flujo FAILED no se puede recuperar; debe eliminarlo y crear uno nuevo.

  • En el caso de errores recuperables: corrija el problema externo (política de IAM, clave de AWS KMS, capacidad de Kinesis o límite de tamaño de registro de Kinesis). El siguiente intento que tenga éxito borra el estado de error y devuelve el flujo al estado ACTIVE.

  • En el caso de KINESIS_STREAM_NOT_FOUND: el flujo pasa directamente a FAILED. Elimine el flujo con error y cree uno nuevo que apunte a una flujo de datos de Kinesis válido.

En el caso de los demás códigos de error, si el retardo en la replicación supera el umbral de error antes de resolver el problema, el flujo pasa de IMPAIRED a FAILED. Un flujo con error no puede volver al estado ACTIVE. En este caso, debe eliminar el flujo con error, resolver el problema subyacente y crear uno nuevo.

Supervisión del estado el flujo

Utilice las métricas de CloudWatch y la API GetStream para supervisar el estado de los flujos. Las métricas de CloudWatch proporcionan una visibilidad continua del rendimiento de las canalizaciones de los CDC y GetStream proporciona el código de error específico cuando un flujo se interrumpe o produce un error.

Para ver la lista completa de las métricas de CDC, como IsImpaired, BehindSourceLag, PublishedBytes y PublishedRecords, consulte Métricas de CloudWatch para los flujos de CDC. Para obtener más información sobre los campos de respuesta GetStream, consulte GetStream en la Referencia de la API de Amazon Aurora DSQL.

Métricas de CloudWatch para los flujos de CDC

Utilice las métricas de CloudWatch siguientes para supervisar el estado y el rendimiento de cada flujo de CDC. Aurora DSQL publica estas métricas en el espacio de nombres AWS/AuroraDSQL con las dimensiones ClusterId y StreamId. La última métrica es una métrica estándar de Amazon Kinesis en el espacio de nombres AWS/Kinesis que mide el retardo de lectura descendente.

nota

Aurora DSQL también publica las métricas BytesStreamed y StreamDPU en el espacio de nombres AWS/AuroraDSQL para el seguimiento del uso y la facturación. Para ver las descripciones, consulte Métricas de flujos de CDC.

Nombre de métrica Estadísticas útiles Descripción
IsImpaired Maximum Indicates whether the stream is impaired. The value is 1 when the stream is in the IMPAIRED state, and 0 when the stream is healthy. Aurora DSQL emits this metric continuously for each active or impaired stream. Use this metric to create a CloudWatch alarm that notifies you when a stream becomes impaired.
BehindSourceLag Average The delay, in milliseconds, between when a transaction commits in Aurora DSQL and when the CDC system processes the resulting record. A rising value indicates that the CDC pipeline is falling behind the write workload.
PublishedBytes Sum The total bytes of CDC records that Aurora DSQL wrote to the target during the period. Use this metric together with your Kinesis shard count to determine whether you've provisioned enough write capacity.
PublishedRecords Sum The total number of CDC records that Aurora DSQL wrote to the target during the period. Each committed row change produces one record.
GetRecords.IteratorAgeMilliseconds (AWS/Kinesis) Average A standard Kinesis metric that reports the age of the last record read from the Kinesis data stream by your downstream app, in milliseconds. Use the StreamName dimension. A rising value indicates that your downstream app can't keep up with the rate at which Aurora DSQL writes CDC records to Kinesis.

La pestaña Supervisión de la consola de Aurora DSQL muestra un valor de Latencia promedio integral que combina BehindSourceLag (latencia de origen de CDC) y GetRecords.IteratorAgeMilliseconds (retardo del lector de Kinesis). Este valor combinado representa el retardo total desde la confirmación de la base de datos hasta la lectura descendente.

Prácticas recomendadas de supervisión

Siga estas prácticas para detectar y resolver los problemas de canalización de CDC antes de que afecten a sus sistemas descendentes.

Establecimiento de alarmas en BehindSourceLag

Cree una alarma de CloudWatch que se active cuando BehindSourceLag supere un umbral importante para su carga de trabajo. Por ejemplo, establezca 60 segundos para un objetivo de latencia de un minuto. Un aumento constante de esta métrica significa que la canalización CDC se está retrasando. Si el retardo alcanza el umbral de error, el flujo pasa al estado FAILED. Si se anticipa a esta tendencia, dispondrá de tiempo para aumentar la capacidad de Kinesis o investigar los cuellos de botella en el rendimiento antes de que se produzca una degradación del flujo.

Supervisión de GetRecords.IteratorAgeMilliseconds en Kinesis

Incluso cuando Aurora DSQL entrega los registros a tiempo, su aplicación descendente podría retrasarse. Cree una alarma de CloudWatch en GetRecords.IteratorAgeMilliseconds (en el espacio de nombres AWS/Kinesis, dimensión StreamName) para detectar el retardo descendente de forma independiente. Si esta métrica aumenta y BehindSourceLag se mantiene estable, el cuello de botella se encuentra en la aplicación descendente, no en Aurora DSQL.

Seguimiento de PublishedBytes con respecto a la capacidad de particiones de Kinesis

Cada partición de Kinesis admite hasta 1 MiB por segundo para escrituras. Compare la suma de PublishedBytes por minuto con la capacidad total de escritura de la partición (número de partición × 60 MiB por minuto). Si el uso se acerca al 80 %, añada particiones o cambie al modo de capacidad bajo demanda antes de que la limitación active KINESIS_THROUGHPUT_EXCEEDED.

La alarma en IsImpaired para detectar el deterioro al instante

Cree una alarma de CloudWatch que se active cuando el valor máximo de IsImpaired sea superior o igual a 1 para un solo periodo de evaluación. Esto le permite recibir una señal directa cuando un flujo entra en el estado IMPAIRED, sin necesidad de sondear la API. Cuando se active la alarma, llame a GetStream para leer el campo statusReason.error y siga los pasos de corrección que se indican en Solución de problemas de un flujo dañado o con error.

Sondeo de GetStream para obtener información detallada sobre el estado

La métrica IsImpaired indica que un flujo está dañado, pero la API GetStream proporciona el código de error y la marca de tiempo específicos. Sondee GetStream de forma programada (por ejemplo, cada cinco minutos) o en respuesta a una alarma IsImpaired. El campo statusReason.error te indica qué es lo que ha ocurrido. Combínelo con los pasos de solución de problemas que se indican en Solución de problemas de un flujo dañado o con error para conseguir una resolución rápida.

Utilice los paneles para correlacionar las métricas

Cree un panel de CloudWatch que muestre IsImpaired, BehindSourceLag, PublishedRecords, PublishedBytes y GetRecords.IteratorAgeMilliseconds en paralelo. La correlación de estas métricas le ayuda a distinguir entre un problema en la canalización de CDC (aumento de BehindSourceLag) y un problema de lectura descendente (aumento de IteratorAge con BehindSourceLag estable).