Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Resolución de problemas de Managed Service para Apache Flink
Los temas siguientes puede ayudar a solucionar los problemas que puedan presentarse con Amazon Managed Service para Apache Flink.
Elija el tema apropiado para revisar las soluciones.
**Topics**
+ [Solución de problemas de implementación](troubleshooting-development.md)
+ [Solución de problemas de tiempo de ejecución](troubleshooting-runtime.md)
# Solución de problemas de implementación
Esta sección contiene información sobre el diagnóstico y la solución de problemas de implementación con su aplicación Managed Service para Apache Flink.
**Topics**
+ [Prácticas recomendadas de reversión del sistema](troubleshooting-system-rollback.md)
+ [Prácticas recomendadas de configuración de Hudi](troubleshooting-hudi.md)
+ [Gráficos de Apache Flink Flame](troubleshooting-update-flamegraphs.md)
+ [Problema del proveedor de credenciales con el conector EFO 1.15.2](troubleshooting-credential-provider.md)
+ [Aplicaciones con conectores Kinesis no compatibles](troubleshooting-unsupported-kinesis-connectors.md)
+ [Error de compilación: “Could not resolve dependencies for project”](troubleshooting-compile.md)
+ [Opción no válida: “kinesisanalyticsv2”](troubleshooting-cli-update.md)
+ [UpdateApplication la acción no es volver a cargar el código de la aplicación](troubleshooting-update.md)
+ [S3 StreamingFileSink FileNotFoundExceptions](troubleshooting-s3sink.md)
+ [FlinkKafkaConsumer problema con stop with savepoint](troubleshooting-FlinkKafkaConsumer.md)
+ [Bloqueo de Flink 1.15 Async Sink](troubleshooting-async-deadlock.md)
+ [El procesamiento del origen de Amazon Kinesis Data Streams no funciona durante la partición nueva.](troubleshooting-kinesis-data-streams-processing-out-of-order.md)
+ [Preguntas frecuentes y solución de problemas de esquemas de incrustación vectorial en tiempo real](troubleshooting-blueprints.md)
# Prácticas recomendadas de reversión del sistema
Con las funciones de reversión automática del sistema y visibilidad de las operaciones de Amazon Managed Service para Apache Flink, se pueden identificar y resolver problemas con sus aplicaciones.
## Restauraciones del sistema
Si la operación de actualización o escalado de la aplicación falla debido a un error del cliente, como un error de código o un problema de permisos, Amazon Managed Service para Apache Flink intentará volver de manera automática a la versión anterior en ejecución si ha optado por esta funcionalidad. Para obtener más información, consulte [Habilitación de las restauraciones del sistema para la aplicación Amazon Managed Service para Apache Flink](how-system-rollbacks.md). Si esta reversión automática no se realiza correctamente o si no se ha optado por activarla, su solicitud se colocará en el estado `READY`. Complete los pasos que se indican a continuación para actualizar la aplicación: Consulte la consola de Amazon Managed Service para Apache Flink o utilice la API de `DescribeApplicationOperation` para ver la descripción del error que explica por qué se ha producido un error en la operación. Para ver la pila de errores completa, use los [registros de Cloudwatch](https://docs.aws.amazon.com/managed-flink/latest/java/logging.html). Los problemas más comunes son la falta de permisos, los cambios de código incompatibles o las configuraciones incorrectas de la infraestructura. Resuelva el problema de fondo. Use la API de `UpdateApplicaton` para volver a implementar la nueva versión de la aplicación.
## Restauraciones manuales
Si la aplicación no progresa y permanece en un estado transitorio durante mucho tiempo, o si la aplicación ha realizado la transición a `Running` correctamente, pero observa problemas posteriores, como errores de procesamiento, en una aplicación de Flink que se ha actualizado correctamente, se puede revertir manualmente mediante la API de `RollbackApplication`.
1. Llamada `RollbackApplication`: se revertirá a la versión anterior en ejecución y se restaurará el estado anterior.
1. Monitoree la operación de reversión mediante la API de `DescribeApplicationOperation`.
1. Si la reversión falla, siga los pasos anteriores de reversión del sistema.
## Visibilidad de las operaciones
La API de `ListApplicationOperations` muestra el historial de todas las operaciones de los clientes y del sistema en su aplicación.
1. Obtenga el *ID de operación* de la operación fallida de la lista.
1. Llame `DescribeApplicationOperation` y compruebe el estado y *statusDescription*.
1. Si una operación ha fallado, la descripción apunta a un posible error que hay que investigar.
**Errores comunes en los códigos de error:** utilice las funciones de reversión para volver a la última versión en funcionamiento. Resuelva los errores y vuelva a intentar la actualización.
**Problemas con los permisos:** utilice la `DescribeApplicationOperation` para ver los permisos necesarios. Actualice los permisos de la aplicación y vuelva a intentarlo.
**Problemas con el servicio Amazon Managed Service para Apache Flink:** consulta Panel de AWS Health o abre un caso de soporte.
# Prácticas recomendadas de configuración de Hudi
Para ejecutar los conectores Hudi en Managed Service para Apache Flink, recomendamos los siguientes cambios de configuración.
Deshabilitar `hoodie.embed.timeline.server`
El conector Hudi de Flink configura un servidor de cronograma (TM) integrado en el gestor de tareas (JM) de Flink para almacenar en caché los metadatos y mejorar el rendimiento cuando el paralelismo de las tareas es elevado. Se recomienda que desactive este servidor integrado en Managed Service para Apache Flink, ya que deshabilitamos la comunicación que no es de Flink entre JM y TM.
Si este servidor está activado, las escrituras de Hudi primero intentarán conectarse al servidor integrado en JM y, a continuación, volverán a leer los metadatos de Amazon S3. Esto significa que Hudi tiene un tiempo de espera de conexión, lo que retrasa las escrituras de Hudi y repercute en el rendimiento de Managed Service para Apache Flink.
# Gráficos de Apache Flink Flame
Los gráficos de Flame están habilitados de forma predeterminada en las aplicaciones de las versiones compatibles de Managed Service para Apache Flink. Los gráficos de Flame pueden afectar el rendimiento de la aplicación si se mantiene el gráfico abierto, como se menciona en la [documentación de Flink](https://nightlies.apache.org/flink/flink-docs-release-1.15//docs/ops/debugging/flame_graphs/).
Si desea deshabilitar los gráficos de Flame para la aplicación, genere un caso para solicitar que se los deshabilite para el ARN de la aplicación. Para obtener más información, consulte el [Centro de soporte de AWS](https://console.aws.amazon.com/support/home#/).
# Problema del proveedor de credenciales con el conector EFO 1.15.2
Existe un [problema conocido](https://issues.apache.org/jira/browse/FLINK-29205) con las versiones del conector EFO de Kinesis Data Streams anteriores a la 1.15.2, en donde `FlinkKinesisConsumer` no respeta la configuración del `Credential Provider`. Debido a este problema, se descartan configuraciones válidas, lo que provoca que se utilice el proveedor de credenciales `AUTO`. Esto puede provocar un problema al utilizar el acceso entre cuentas a Kinesis mediante el conector EFO.
Para resolver este error, utilice la versión 1.15.3 o superior del conector EFO.
# Aplicaciones con conectores Kinesis no compatibles
Managed Service for Apache Flink for Apache Flink versión 1.15 o posterior [rechazará automáticamente el inicio o la actualización de las aplicaciones si utilizan versiones no compatibles de](https://docs.aws.amazon.com/managed-flink/latest/java/flink-1-15-2.html) Kinesis Connector (anteriores a la versión 1.15.2) incluidas en la aplicación o en los archivos (ZIP). JARs
## Error de rechazo
Aparecerá el siguiente error al enviar las llamadas de creación o actualización de la aplicación:
```
An error occurred (InvalidArgumentException) when calling the CreateApplication operation: An unsupported Kinesis connector version has been detected in the application. Please update flink-connector-kinesis to any version equal to or newer than 1.15.2.
For more information refer to connector fix: https://issues.apache.org/jira/browse/FLINK-23528
```
## Pasos para solucionarlo
+ Actualice la dependencia de la aplicación en `flink-connector-kinesis`. Si se utiliza Maven como la herramienta de creación de su proyecto, siga [Actualización de una dependencia de Maven](#troubleshooting-unsupported-kinesis-connectors-update-maven-dependency). Si usa Gradle, siga [Actualización de una dependencia de Gradle](#troubleshooting-unsupported-kinesis-connectors-update-gradle-dependency).
+ Vuelva a empaquetar la aplicación.
+ Cargue en un bucket de Amazon S3.
+ Vuelva a enviar la solicitud de creación o actualización de la aplicación con la aplicación modificada que se acaba de cargar en el bucket de Amazon S3.
+ Si sigue apareciendo el mismo mensaje de error, vuelva a comprobar las dependencias de la aplicación. Si el problema persiste, cree una inidencia de soporte técnicio.
### Actualización de una dependencia de Maven
1. Abra el `pom.xml` del proyecto.
1. Encuentre las dependencias del proyecto. Aparecen así:
```
...
...
org.apache.flink
flink-connector-kinesis
...
...
```
1. Actualice `flink-connector-kinesis` a una versión igual o posterior a la 1.15.2. Por ejemplo:
```
...
...
org.apache.flink
flink-connector-kinesis
1.15.2
...
...
```
### Actualización de una dependencia de Gradle
1. Abra el `build.gradle` del proyecto (o `build.gradle.kts` para las aplicaciones de Kotlin).
1. Encuentre las dependencias del proyecto. Aparecen así:
```
...
dependencies {
...
implementation("org.apache.flink:flink-connector-kinesis")
...
}
...
```
1. Actualice `flink-connector-kinesis` a una versión igual o posterior a la 1.15.2. Por ejemplo:
```
...
dependencies {
...
implementation("org.apache.flink:flink-connector-kinesis:1.15.2")
...
}
...
```
# Error de compilación: “Could not resolve dependencies for project”
Para compilar las aplicaciones de ejemplo de Managed Service para Apache Flink, primero debe descargar y compilar el conector Apache Flink Kinesis y añadirlo a su repositorio local de Maven. Si el conector no se ha agregado a su repositorio, aparece un error de compilación similar al siguiente:
```
Could not resolve dependencies for project your project name: Failure to find org.apache.flink:flink-connector-kinesis_2.11:jar:1.8.2 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced
```
Para resolver este error, debe descargar el código fuente de Apache Flink (desde la versión 1.8.2) para el conector. [https://flink.apache.org/downloads.html](https://flink.apache.org/downloads.html) Para obtener instrucciones sobre cómo descargar, compilar e instalar el código fuente de Apache Flink, consulte [Uso del conector Apache Flink Kinesis Streams con versiones anteriores de Apache Flink](earlier.md#how-creating-apps-building-kinesis).
# Opción no válida: “kinesisanalyticsv2”
Para usar la versión 2 de la API de Managed Service para Apache Flink, necesita la última versión de AWS Command Line Interface (AWS CLI).
Para obtener información sobre cómo actualizar el AWS CLI, consulte [Instalación del AWS Command Line Interface en la](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) Guía del *AWS Command Line Interface usuario*.
# UpdateApplication la acción no es volver a cargar el código de la aplicación
La [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)acción no volverá a cargar el código de la aplicación con el mismo nombre de archivo si no se especifica ninguna versión del objeto S3. Para volver a cargar el código de la aplicación con el mismo nombre de archivo, habilite el control de versiones en el bucket de S3 y especifique la versión del nuevo objeto mediante el parámetro `ObjectVersionUpdate`. Para obtener más información sobre la habilitación del control de versiones de objetos en un bucket de S3, consulte [Enabling or Disabling Versioning](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-versioning.html).
# S3 StreamingFileSink FileNotFoundExceptions
Las aplicaciones de Managed Service para Apache Flink pueden ejecutarse en un archivo `FileNotFoundException` parcial en curso cuando se parte de instantáneas si falta un archivo parcial en curso al que se hace referencia por su punto de guardado. Cuando se produce este modo de error, el estado de operador de la aplicación Managed Service para Apache Flink no suele ser recuperable y debe reiniciarse sin instantánea mediante `SKIP_RESTORE_FROM_SNAPSHOT`. Consulte el siguiente ejemplo de stacktrace:
```
java.io.FileNotFoundException: No such file or directory: s3://amzn-s3-demo-bucket/pathj/INSERT/2023/4/19/7/_part-2-1234_tmp_12345678-1234-1234-1234-123456789012
at org.apache.hadoop.fs.s3a.S3AFileSystem.s3GetFileStatus(S3AFileSystem.java:2231)
at org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2149)
at org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2088)
at org.apache.hadoop.fs.s3a.S3AFileSystem.open(S3AFileSystem.java:699)
at org.apache.hadoop.fs.FileSystem.open(FileSystem.java:950)
at org.apache.flink.fs.s3hadoop.HadoopS3AccessHelper.getObject(HadoopS3AccessHelper.java:98)
at org.apache.flink.fs.s3.common.writer.S3RecoverableMultipartUploadFactory.recoverInProgressPart(S3RecoverableMultipartUploadFactory.java:97)
...
```
`StreamingFileSink` de Flink escribe registros en sistemas de archivos compatibles con [File Systems](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/deployment/filesystems/overview/). Dado que los flujos entrantes pueden ser ilimitados, los datos se organizan en archivos parciales de tamaño finito y se añaden nuevos archivos a medida que se escriben los datos. El ciclo de vida parcial y la política de renovación determinan el momento, el tamaño y la denominación de los archivos parciales.
Durante los puntos de control y los puntos de guardado (creación de instantáneas), se cambia el nombre de todos los archivos pendientes y se los confirma. Sin embargo, los archivos parciales en curso no se confirman, sino que se les cambia el nombre, y se guarda su referencia en los metadatos de los puntos de control o de guardado para utilizarlos cuando se restauren los trabajos. Con el tiempo, estos archivos parciales en curso pasarán a estar Pendientes, se les cambiará el nombre y se los confirmará en un punto de control o guardado posterior.
A continuación se indican las causas principales y las medidas correctoras de la falta de un archivo parcial en curso:
+ Instantánea obsoleta utilizada para iniciar la aplicación Managed Service for Apache Flink: solo la última instantánea del sistema tomada cuando se detiene o actualiza una aplicación se puede usar para iniciar una aplicación Managed Service for Apache Flink con Amazon S3. StreamingFileSink Para evitar este tipo de error, utilice la última instantánea del sistema.
+ Esto ocurre, por ejemplo, cuando se selecciona una instantánea creada con `CreateSnapshot` en lugar de una instantánea activada por el sistema durante la detención o la actualización. El punto de guardado de la instantánea anterior guarda una out-of-date referencia a un archivo de pieza en curso al que se le ha cambiado el nombre y al que se ha asignado el siguiente punto de control o punto de guardado.
+ Esto también puede ocurrir cuando se selecciona una instantánea activada por el sistema a partir de un evento que no es el más reciente. Stop/Update Un ejemplo es una aplicación con la instantánea del sistema deshabilitada pero con configuración `RESTORE_FROM_LATEST_SNAPSHOT`. Por lo general, las aplicaciones de Managed Service for Apache Flink con Amazon S3 siempre StreamingFileSink deben tener habilitada y `RESTORE_FROM_LATEST_SNAPSHOT` configurada la instantánea del sistema.
+ Se elimina el archivo parcial en curso: dado que el archivo parcial en curso se encuentra en un bucket de S3, pueden eliminarlo otros componentes o actores que tengan acceso al bucket.
+ Esto puede suceder si ha detenido la aplicación durante demasiado tiempo y la política de ciclo de vida de los buckets de [S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpu-abort-incomplete-mpu-lifecycle-config.html) ha eliminado el archivo de parte en curso al que hace referencia el punto de almacenamiento de la aplicación. MultiPartUpload Para evitar este tipo de errores, asegúrese de que la política de ciclo de vida de S3 Bucket MPU abarque un período lo suficientemente amplio para su caso de uso.
+ Esto también puede ocurrir cuando el archivo parcial en curso se elimina manualmente o mediante otro de los componentes del sistema. Para evitar este tipo de errores, asegúrese de que otros actores o componentes no eliminen los archivos parciales en curso.
+ Condición de carrera en la que se activa un punto de control automático después del punto de guardado: esto afecta a las versiones de Managed Service para Apache Flink hasta la 1.13, inclusive. Este problema está solucionado en Managed Service para Apache Flink, versión 1.15. Migre la aplicación a la versión más reciente de Managed Service para Apache Flink para evitar la reaparición. También te sugerimos migrar de a. StreamingFileSink [FileSink](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/connectors/datastream/filesystem/#file-sink)
+ Cuando las aplicaciones se detienen o actualizan, Managed Service para Apache Flink activa un punto de guardado y detiene la aplicación en dos pasos. Si se activa un punto de control automático entre los dos pasos, el punto de guardado quedará inutilizable, ya que se cambiará el nombre del archivo parcial en curso y, posiblemente, se lo confirmará.
# FlinkKafkaConsumer problema con stop with savepoint
Al utilizar la versión antigua, FlinkKafkaConsumer existe la posibilidad de que la aplicación se bloquee al actualizar, detener o escalar si tiene habilitadas las instantáneas del sistema. No hay ninguna solución publicada disponible para este [problema](https://issues.apache.org/jira/browse/FLINK-28758), por lo que le recomendamos que actualice a la nueva [KafkaSource](https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/datastream/kafka/#kafka-source)para mitigar este problema.
Si se utiliza `FlinkKafkaConsumer` con las instantáneas habilitadas, existe la posibilidad de que, cuando el trabajo de Flink procese una detención con una solicitud de API de punto de guardado, `FlinkKafkaConsumer` falle con un error de tiempo de ejecución que indique `ClosedException`. En estas condiciones, la aplicación Flink se bloquea y se manifiesta como puntos de control fallidos.
# Bloqueo de Flink 1.15 Async Sink
Existe un [problema conocido](https://issues.apache.org/jira/browse/FLINK-32230) con los AWS conectores de la AsyncSink interfaz de implementación de Apache Flink. Esto afecta a las aplicaciones que utilizan Flink 1.15 con los siguientes conectores:
+ Para aplicaciones Java:
+ KinesisStreamsSink – `org.apache.flink:flink-connector-kinesis`
+ KinesisStreamsSink – `org.apache.flink:flink-connector-aws-kinesis-streams`
+ KinesisFirehoseSink – `org.apache.flink:flink-connector-aws-kinesis-firehose`
+ DynamoDbSink – `org.apache.flink:flink-connector-dynamodb`
+ Aplicaciones FlinkSQL/TableAPI/Python:
+ kinesis:`org.apache.flink:flink-sql-connector-kinesis`
+ kinesis: `org.apache.flink:flink-sql-connector-aws-kinesis-streams`
+ firehose: `org.apache.flink:flink-sql-connector-aws-kinesis-firehose`
+ dynamodb: `org.apache.flink:flink-sql-connector-dynamodb`
Las aplicaciones afectadas experimentarán los siguientes síntomas:
+ El trabajo de Flink está en estado de `RUNNING`, pero no está procesando datos.
+ No se reinicia ningún trabajo.
+ Se agota el tiempo de espera de los puntos de control.
El problema se debe a un [error](https://github.com/aws/aws-sdk-java-v2/issues/4354) en el AWS SDK que hace que la persona que llama no muestre ciertos errores cuando utiliza el cliente HTTP asíncrono. Esto hace que el receptor espere indefinidamente a que se complete una “solicitud en tránsito” durante una operación de vaciado de puntos de control.
**Este problema se solucionó en el AWS SDK a partir de la versión 2.20.144.**
A continuación, se incluyen instrucciones sobre cómo actualizar los conectores afectados para usar la nueva versión del AWS SDK en sus aplicaciones:
**Topics**
+ [Actualización de las aplicaciones Java](troubleshooting-async-deadlock-update-java-apps.md)
+ [Actualizar aplicaciones de Python](troubleshooting-async-deadlock-update-python-apps.md)
# Actualización de las aplicaciones Java
Siga los procedimientos que se indican a continuación para actualizar las aplicaciones Java:
## flink-connector-kinesis
Si la aplicación utiliza `flink-connector-kinesis`:
El conector de Kinesis usa el sombreado para empaquetar algunas dependencias, incluido el AWS SDK, en la jarra del conector. Para actualizar la versión del AWS SDK, utilice el siguiente procedimiento para reemplazar estas clases sombreadas:
------
#### [ Maven ]
1. Agregue el conector de Kinesis y los módulos del AWS SDK necesarios como dependencias del proyecto.
1. Configure `maven-shade-plugin`:
1. Añada un filtro para excluir las clases de AWS SDK sombreadas al copiar el contenido del tarro del conector de Kinesis.
1. Añada una regla de reubicación para mover las clases de AWS SDK actualizadas al paquete, según lo previsto por el conector de Kinesis.
**pom.xml**
```
...
...
org.apache.flink
flink-connector-kinesis
1.15.4
software.amazon.awssdk
kinesis
2.20.144
software.amazon.awssdk
netty-nio-client
2.20.144
software.amazon.awssdk
sts
2.20.144
...
...
...
...
org.apache.maven.plugins
maven-shade-plugin
3.1.1
package
shade
...
...
org.apache.flink:flink-connector-kinesis
org/apache/flink/kinesis/shaded/software/amazon/awssdk/**
org/apache/flink/kinesis/shaded/org/reactivestreams/**
org/apache/flink/kinesis/shaded/io/netty/**
org/apache/flink/kinesis/shaded/com/typesafe/netty/**
...
...
software.amazon.awssdk
org.apache.flink.kinesis.shaded.software.amazon.awssdk
org.reactivestreams
org.apache.flink.kinesis.shaded.org.reactivestreams
io.netty
org.apache.flink.kinesis.shaded.io.netty
com.typesafe.netty
org.apache.flink.kinesis.shaded.com.typesafe.netty
...
...
...
...
```
------
#### [ Gradle ]
1. Agregue el conector de Kinesis y los módulos del AWS SDK necesarios como dependencias del proyecto.
1. Ajuste la configuración de ShadowJar:
1. Excluya las clases de AWS SDK sombreadas al copiar el contenido del tarro del conector de Kinesis.
1. Reubique las clases de AWS SDK actualizadas en un paquete esperado por el conector de Kinesis.
**build.gradle**
```
...
dependencies {
...
flinkShadowJar("org.apache.flink:flink-connector-kinesis:1.15.4")
flinkShadowJar("software.amazon.awssdk:kinesis:2.20.144")
flinkShadowJar("software.amazon.awssdk:sts:2.20.144")
flinkShadowJar("software.amazon.awssdk:netty-nio-client:2.20.144")
...
}
...
shadowJar {
configurations = [project.configurations.flinkShadowJar]
exclude("software/amazon/kinesis/shaded/software/amazon/awssdk/**/*")
exclude("org/apache/flink/kinesis/shaded/org/reactivestreams/**/*.class")
exclude("org/apache/flink/kinesis/shaded/io/netty/**/*.class")
exclude("org/apache/flink/kinesis/shaded/com/typesafe/netty/**/*.class")
relocate("software.amazon.awssdk", "org.apache.flink.kinesis.shaded.software.amazon.awssdk")
relocate("org.reactivestreams", "org.apache.flink.kinesis.shaded.org.reactivestreams")
relocate("io.netty", "org.apache.flink.kinesis.shaded.io.netty")
relocate("com.typesafe.netty", "org.apache.flink.kinesis.shaded.com.typesafe.netty")
}
...
```
------
## Otros conectores afectados
Si la aplicación utiliza otro conector afectado:
Para actualizar la versión del AWS SDK, se debe aplicar la versión del SDK en la configuración de compilación del proyecto.
------
#### [ Maven ]
Agrega la lista de materiales (BOM) del AWS SDK a la sección de administración de dependencias del `pom.xml` archivo para aplicar la versión del SDK al proyecto.
**pom.xml**
```
...
...
software.amazon.awssdk
bom
2.20.144
import
pom
...
...
```
------
#### [ Gradle ]
Agregue la dependencia de la plataforma a la lista de materiales (BOM) del AWS SDK para aplicar la versión del SDK al proyecto. Esto requiere Gradle 5.0 o una versión más reciente:
**build.gradle**
```
...
dependencies {
...
flinkShadowJar(platform("software.amazon.awssdk:bom:2.20.144"))
...
}
...
```
------
# Actualizar aplicaciones de Python
Las aplicaciones de Python pueden usar conectores de dos maneras diferentes: empaquetando conectores y otras dependencias de Java como parte de un único uber-jar, o usar el archivo jar del conector directamente. Cómo corregir las aplicaciones afectadas por el bloqueo de Async Sink:
+ Si la aplicación usa un uber jar, siga las instrucciones de [Actualización de las aplicaciones Java](troubleshooting-async-deadlock-update-java-apps.md).
+ Para reconstruir los archivos jar del conector desde el origen, siga estos pasos:
**Construcción de conectores desde el origen:**
Requisitos previos, similares a los [requisitos de construcción](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/flinkdev/building/#build-flink) de Flink:
+ Java 11
+ Maven 3.2.5
## flink-sql-connector-kinesis
1. Descargue el código fuente de Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Descomprima el código fuente:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Navegación hasta el directorio de conectores de Kinesis
```
cd flink-1.15.4/flink-connectors/flink-connector-kinesis/
```
1. Compila e instala el tarro de conectores, especificando la versión AWS del SDK requerida. Para acelerar la construcción, utilice `-DskipTests` para omitir la ejecución de las pruebas y `-Dfast` para omitir las comprobaciones adicionales del código fuente:
```
mvn clean install -DskipTests -Dfast -Daws.sdkv2.version=2.20.144
```
1. Navegación hasta el directorio de conectores de Kinesis
```
cd ../flink-sql-connector-kinesis
```
1. Compile e instale el archivo jar del conector sql:
```
mvn clean install -DskipTests -Dfast
```
1. El jar resultante estará disponible en:
```
target/flink-sql-connector-kinesis-1.15.4.jar
```
## flink-sql-connector-aws-kinesis-streams
1. Descargue el código fuente de Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Descomprima el código fuente:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Navegación hasta el directorio de conectores de Kinesis
```
cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-streams/
```
1. Compila e instala el conector jar, especificando la versión del SDK requerida. AWS Para acelerar la construcción, utilice `-DskipTests` para omitir la ejecución de las pruebas y `-Dfast` para omitir las comprobaciones adicionales del código fuente:
```
mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144
```
1. Navegación hasta el directorio de conectores de Kinesis
```
cd ../flink-sql-connector-aws-kinesis-streams
```
1. Compile e instale el archivo jar del conector sql:
```
mvn clean install -DskipTests -Dfast
```
1. El jar resultante estará disponible en:
```
target/flink-sql-connector-aws-kinesis-streams-1.15.4.jar
```
## flink-sql-connector-aws-kinesis-firehose
1. Descargue el código fuente de Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Descomprima el código fuente:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Navegación hasta el directorio de conectores
```
cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-firehose/
```
1. Compila e instala el conector jar, especificando la versión del SDK requerida. AWS Para acelerar la construcción, utilice `-DskipTests` para omitir la ejecución de las pruebas y `-Dfast` para omitir las comprobaciones adicionales del código fuente:
```
mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144
```
1. Navegación hasta el directorio de conectores sql
```
cd ../flink-sql-connector-aws-kinesis-firehose
```
1. Compile e instale el archivo jar del conector sql:
```
mvn clean install -DskipTests -Dfast
```
1. El jar resultante estará disponible en:
```
target/flink-sql-connector-aws-kinesis-firehose-1.15.4.jar
```
## flink-sql-connector-dynamodb
1. Descargue el código fuente de Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-connector-aws-3.0.0/flink-connector-aws-3.0.0-src.tgz
```
1. Descomprima el código fuente:
```
tar -xvf flink-connector-aws-3.0.0-src.tgz
```
1. Navegación hasta el directorio de conectores
```
cd flink-connector-aws-3.0.0
```
1. Compila e instala el contenedor de conectores, especificando la versión AWS del SDK requerida. Para acelerar la construcción, utilice `-DskipTests` para omitir la ejecución de las pruebas y `-Dfast` para omitir las comprobaciones adicionales del código fuente:
```
mvn clean install -DskipTests -Dfast -Dflink.version=1.15.4 -Daws.sdk.version=2.20.144
```
1. El jar resultante estará disponible en:
```
flink-sql-connector-dynamodb/target/flink-sql-connector-dynamodb-3.0.0.jar
```
# El procesamiento del origen de Amazon Kinesis Data Streams no funciona durante la partición nueva.
La FlinkKinesisConsumer implementación actual no ofrece garantías sólidas de ordenamiento entre las particiones de Kinesis. Esto puede provocar que se procese durante la refragmentación de Kinesis Stream, en particular en el caso de las aplicaciones de Flink que sufren retrasos en el out-of-order procesamiento. En algunas circunstancias, por ejemplo, los operadores de Windows basados en la hora de los eventos, es posible que los eventos se desechen debido a la demora resultante.
![\[Diagram showing shards and shard consumers with time progression and trim horizon.\]](http://docs.aws.amazon.com/es_es/managed-flink/latest/java/images/flink-ts.png)
Este es un [problema conocido](https://issues.apache.org/jira/browse/FLINK-6349) en Open Source Flink. Hasta que se cuente con una corrección de conector, asegúrese de que sus aplicaciones de Flink no se queden atrás de las de Kinesis Data Streams al realizar la partición de nuevo. Al asegurarse de que sus aplicaciones de Flink toleran el retraso en el procesamiento, puede minimizar el impacto del out-of-order procesamiento y el riesgo de pérdida de datos.
# Preguntas frecuentes y solución de problemas de esquemas de incrustación vectorial en tiempo real
Consulte las siguientes secciones de preguntas frecuentes y solución de problemas para resolver problemas con los esquemas de incrustación vectorial en tiempo real. Para obtener más información sobre los esquemas de incrustación vectorial en tiempo real, consulte [Real-time vector embedding blueprints](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html).
Para obtener información general sobre la solución de problemas de la aplicación Managed Service for Apache Flink, consulte [https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html).
**Topics**
+ [Preguntas frecuentes de esquemas de incrustación vectorial en tiempo real](troubleshooting-blueprints-FAQ.md)
+ [Solución de problemas de esquemas de incrustación vectorial en tiempo real](troubleshooting-blueprints-TS.md)
# Preguntas frecuentes de esquemas de incrustación vectorial en tiempo real
Consulte las siguientes preguntas frecuentes sobre los esquemas de incrustación vectorial en tiempo real. Para obtener más información sobre los esquemas de incrustación vectorial en tiempo real, consulte [Real-time vector embedding blueprints](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html).
**Topics**
+ [¿Qué AWS recursos crea este plan?](#troubleshooting-blueprints-1)
+ [¿Cuáles son mis acciones una vez finalizada la implementación de la AWS CloudFormation pila?](#troubleshooting-blueprints-2)
+ [¿Cuál debe ser la estructura de los datos en los temas de Amazon MSK de origen?](#troubleshooting-blueprints-3)
+ [¿Puedo especificar partes de un mensaje para incrustarlas?](#troubleshooting-blueprints-4)
+ [¿Puedo leer datos de varios temas de Amazon MSK?](#troubleshooting-blueprints-5)
+ [¿Puedo usar expresiones regulares para configurar los nombres de los temas de Amazon MSK?](#troubleshooting-blueprints-6)
+ [¿Cuál es el tamaño máximo de un mensaje que se puede leer de un tema de Amazon MSK?](#troubleshooting-blueprints-7)
+ [¿Qué tipo de es compatible OpenSearch ?](#troubleshooting-blueprints-8)
+ [¿Por qué necesito usar una colección de búsqueda vectorial, un índice vectorial y añadir un campo vectorial a mi colección OpenSearch Serverless?](#troubleshooting-blueprints-9)
+ [¿Qué se debe establecer como dimensión para mi campo vectorial?](#troubleshooting-blueprints-10)
+ [¿Qué aspecto tiene el resultado en el índice configurado? OpenSearch](#troubleshooting-blueprints-11)
+ [¿Puedo especificar campos de metadatos para añadirlos al documento almacenado en el índice? OpenSearch](#troubleshooting-blueprints-12)
+ [¿Debo esperar entradas duplicadas en el OpenSearch índice?](#troubleshooting-blueprints-13)
+ [¿ OpenSearch Puedo enviar datos a varios índices?](#troubleshooting-blueprints-14)
+ [¿Puedo implementar varias aplicaciones de incrustación vectorial en tiempo real en una sola Cuenta de AWS¿](#troubleshooting-blueprints-15)
+ [¿Pueden varias aplicaciones de incrustación vectorial en tiempo real utilizar el mismo origen o receptor de datos?](#troubleshooting-blueprints-16)
+ [¿La aplicación admite la conectividad entre cuentas?](#troubleshooting-blueprints-17)
+ [¿La aplicación admite la conectividad entre regiones?](#troubleshooting-blueprints-18)
+ [¿El clúster y la OpenSearch colección de Amazon MSK pueden estar en redes diferentes VPCs o en subredes?](#troubleshooting-blueprints-19)
+ [¿Qué modelos de incrustación admite la aplicación?](#troubleshooting-blueprints-20)
+ [¿Puedo refinar el rendimiento de mi aplicación en función de mi carga de trabajo?](#troubleshooting-blueprints-21)
+ [¿Qué tipos de autenticación de Amazon MSK son compatibles?](#troubleshooting-blueprints-22)
+ [¿Qué es `sink.os.bulkFlushIntervalMillis` y cómo se configura?](#troubleshooting-blueprints-23)
+ [Cuando despliegue mi aplicación Managed Service para Apache Flink, ¿a partir de qué punto del tema Amazon MSK empezará a leer los mensajes?](#troubleshooting-blueprints-24)
+ [¿Cómo uso `source.msk.starting.offset`?](#troubleshooting-blueprints-25)
+ [¿Qué estrategias de fragmentación se admiten?](#troubleshooting-blueprints-26)
+ [¿Cómo leo los registros de mi almacén de datos de vectores?](#troubleshooting-blueprints-27)
+ [¿Dónde puedo encontrar nuevas actualizaciones del código fuente?](#troubleshooting-blueprints-28)
+ [¿Puedo realizar un cambio en la AWS CloudFormation plantilla y actualizar la aplicación Managed Service for Apache Flink?](#troubleshooting-blueprints-29)
+ [¿ AWS Supervisará y mantendrá la aplicación en mi nombre?](#troubleshooting-blueprints-30)
+ [¿Esta aplicación mueve mis datos fuera de mi Cuenta de AWS?](#troubleshooting-blueprints-31)
## ¿Qué AWS recursos crea este plan?
Para encontrar los recursos desplegados en su cuenta, vaya a la AWS CloudFormation consola e identifique el nombre de la pila que comienza con el nombre que proporcionó para la aplicación Managed Service for Apache Flink. Elija la pestaña **Recursos** para comprobar los recursos que se crearon como parte de la pila. Los recursos clave que crea la pila son los siguientes:
+ Servicio administrado de incrustación vectorial en tiempo real para la aplicación Apache Flink
+ Bucket Amazon S3 para almacenar el código fuente de la aplicación de incrustación vectorial en tiempo real
+ CloudWatch grupo de registros y flujo de registros para almacenar registros
+ Funciones de Lambda para obtener y crear recursos
+ Funciones y políticas de IAM para Lambdas, servicio gestionado para la aplicación Apache Flink y acceso a Amazon Bedrock y Amazon Service OpenSearch
+ Política de acceso a datos para Amazon OpenSearch Service
+ Puntos de enlace de VPC para acceder a Amazon Bedrock y Amazon Service OpenSearch
## ¿Cuáles son mis acciones una vez finalizada la implementación de la AWS CloudFormation pila?
Una vez completada la implementación de la AWS CloudFormation pila, acceda a la consola de Managed Service for Apache Flink y busque su modelo de aplicación Managed Service for Apache Flink. Seleccione la pestaña **Configurar** y confirme que todas las propiedades del tiempo de ejecución estén configuradas correctamente. Es posible que pasen a la página siguiente. Cuando esté seguro de la configuración, elija **Ejecutar**. La aplicación empezará a ingerir los mensajes de du tema.
[Para comprobar si hay nuevas versiones, consulte -streaming-data/releases. https://github.com/awslabs/ real-time-vectorization-of](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases)
## ¿Cuál debe ser la estructura de los datos en los temas de Amazon MSK de origen?
Actualmente, se admiten datos de origen estructurados y no estructurados.
+ Los datos no estructurados se indican con `STRING` en `source.msk.data.type`. Los datos se leen tal como están en el mensaje entrante.
+ Actualmente, se admiten datos JSON estructurados, indicados con `JSON` en`source.msk.data.type`. Los datos siempre deben estar en formato JSON. Si la aplicación recibe un JSON con formato incorrecto, esta fallará.
+ Cuando se utilice JSON como tipo de datos de origen, asegúrese de que todos los mensajes de todos los temas de origen sean un JSON válido. Si se suscribe a uno o más temas que no contienen objetos JSON con esta configuración, la aplicación fallará. Si uno o más temas contienen una combinación de datos estructurados y no estructurados, se recomienda configurar los datos de origen como no estructurados en la aplicación Managed Service para Apache Flink.
## ¿Puedo especificar partes de un mensaje para incrustarlas?
+ En el caso de los datos de entrada no estructurados, donde `source.msk.data.type` `STRING` estén, la aplicación siempre incrustará el mensaje completo y lo almacenará en el índice configurado. OpenSearch
+ En el caso de los datos de entrada estructurados donde `source.msk.data.type` es `JSON`, se puede configurar `embed.input.config.json.fieldsToEmbed` para especificar qué campo del objeto JSON debe seleccionarse para su incrustación. Esto solo funciona para los campos JSON de nivel superior y no funciona con mensajes anidados JSONs o que contengan una matriz JSON. Use .\$1 para incrustar la totalidad del JSON.
## ¿Puedo leer datos de varios temas de Amazon MSK?
Sí, se pueden leer datos de varios temas de Amazon MSK con esta aplicación. Los datos de todos los temas deben ser del mismo tipo (STRING o JSON) o podrían provocar un error en la aplicación. Los datos de todos los temas se almacenan siempre en un único OpenSearch índice.
## ¿Puedo usar expresiones regulares para configurar los nombres de los temas de Amazon MSK?
`source.msk.topic.names` no admite una lista de expresiones regulares. Se admiten listas de nombres de temas separados por comas o expresiones regulares `.*` para incluir todos los temas.
## ¿Cuál es el tamaño máximo de un mensaje que se puede leer de un tema de Amazon MSK?
El tamaño máximo de un mensaje que se puede procesar está limitado por el límite de InvokeModel cuerpo de Amazon Bedrock, que actualmente está establecido en 25 000 000 000. Para obtener más información, consulte [InvokeModel](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html#API_runtime_InvokeModel_RequestBody).
## ¿Qué tipo de es compatible OpenSearch ?
Admitimos tanto OpenSearch dominios como colecciones. Si usa una OpenSearch colección, asegúrese de usar una colección vectorial y cree un índice vectorial para usarlo en esta aplicación. Esto le permitirá utilizar las capacidades de la base de datos OpenSearch vectorial para consultar sus datos. Para obtener más información, consulta la [explicación de las capacidades de las bases de datos vectoriales de Amazon OpenSearch Service](https://aws.amazon.com/blogs/big-data/amazon-opensearch-services-vector-database-capabilities-explained/).
## ¿Por qué necesito usar una colección de búsqueda vectorial, un índice vectorial y añadir un campo vectorial a mi colección OpenSearch Serverless?
El tipo de colección *de búsqueda vectorial* de OpenSearch Serverless proporciona una capacidad de búsqueda por similitud que es escalable y de alto rendimiento. Agiliza la creación de experiencias de búsqueda aumentada de machine learning (ML) modernas y aplicaciones de la inteligencia artificial (IA) generativa. Para obtener más información, consulte [Working with vector search collections](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html?icmpid=docs_console_unmapped).
## ¿Qué se debe establecer como dimensión para mi campo vectorial?
Establezca la dimensión del campo vectorial en función del modelo de incrustación que se desee utilizar. Consulte la siguiente tabla y confirme estos valores en la documentación correspondiente.
**Dimensiones del campo vectorial**
| Nombre del modelo de incrustación vectorial de Amazon Bedrock | El modelo ofrece compatibilidad para dimensiones de salida |
| --- | --- |
| Incrustaciones de texto Amazon Titan V1 | 1536 |
| Amazon Titan Text Embeddings V2 | 1024 (predeterminado), 384, 256 |
| Amazon Titan Multimodal Embeddings G1 | 1024 (predeterminado), 384, 256 |
| Cohere Embed inglés | 1 024 |
| Cohere Embed multilingüe | 1 024 |
## ¿Qué aspecto tiene el resultado en el índice configurado? OpenSearch
Todos los documentos del OpenSearch índice contienen los siguientes campos:
+ **original\$1data:** los datos que se utilizaron para generar incrustaciones. En el caso del tipo STRING, es el mensaje completo. En el caso del objeto JSON, es el objeto JSON que se utilizó para las incrustaciones. Puede ser el JSON completo del mensaje o los campos específicos del JSON. Por ejemplo, si se seleccionó un nombre para incrustarlo en los mensajes entrantes, el resultado tendría el siguiente aspecto:
```
"original_data": "{\"name\":\"John Doe\"}"
```
+ **embedded\$1data**: matriz flotante vectorial de incrustaciones generada por Amazon Bedrock
+ **fecha**: marca horaria UTC en la que se almacenó el documento OpenSearch
## ¿Puedo especificar campos de metadatos para añadirlos al documento almacenado en el índice? OpenSearch
No, actualmente no admitimos la adición de campos adicionales al documento final almacenado en el OpenSearch índice.
## ¿Debo esperar entradas duplicadas en el OpenSearch índice?
Según cómo se haya configurado la aplicación, es posible que vea mensajes duplicados en el índice. Un motivo habitual es el reinicio de la aplicación. La aplicación está configurada de forma predeterminada para empezar a leer desde el primer mensaje del tema de origen. Al cambiar la configuración, la aplicación se reinicia y vuelve a procesar todos los mensajes del tema. Para evitar el reprocesamiento, consulte la documentación sobre cómo usar source.msk.starting.offset y configurar correctamente el desplazamiento inicial de su aplicación.
## ¿ OpenSearch Puedo enviar datos a varios índices?
No, la aplicación admite el almacenamiento de datos en un único OpenSearch índice. Para configurar el resultado de la vectorización en varios índices, debe implementar un servicio administrado independiente para las aplicaciones de Apache Flink.
## ¿Puedo implementar varias aplicaciones de incrustación vectorial en tiempo real en una sola Cuenta de AWS¿
Sí, se pueden implementar varias aplicaciones del Servicio gestionado de incrustación vectorial para Apache Flink en tiempo real en una sola Cuenta de AWS si cada aplicación tiene un nombre único.
## ¿Pueden varias aplicaciones de incrustación vectorial en tiempo real utilizar el mismo origen o receptor de datos?
Sí, se pueden crear varios servicios gestionados de incrustación vectorial en tiempo real para aplicaciones de Apache Flink que lean datos de los mismos temas o almacenen datos en el mismo índice.
## ¿La aplicación admite la conectividad entre cuentas?
No, para que la aplicación se ejecute correctamente, el clúster de Amazon MSK y la OpenSearch colección deben estar en el mismo Cuenta de AWS lugar en el que intenta configurar la aplicación Managed Service for Apache Flink.
## ¿La aplicación admite la conectividad entre regiones?
No, la aplicación solo le permite implementar una aplicación de Managed Service for Apache Flink con un clúster de Amazon MSK y una OpenSearch colección en la misma región de la aplicación Managed Service for Apache Flink.
## ¿El clúster y la OpenSearch colección de Amazon MSK pueden estar en redes diferentes VPCs o en subredes?
Sí, admitimos el clúster y la OpenSearch recopilación de Amazon MSK en diferentes subredes VPCs y subredes siempre que estén en la misma. Cuenta de AWS Consulte (Solución de problemas generales de MSF) para asegurarse de que la configuración es la correcta.
## ¿Qué modelos de incrustación admite la aplicación?
Actualmente, la aplicación admite todos los modelos compatibles con Bedrock. Entre ellos se incluyen:
+ Amazon Titan Embeddings G1 - Text
+ Amazon Titan Text Embeddings V2
+ Amazon Titan Multimodal Embeddings G1
+ Cohere Embed inglés
+ Cohere Embed multilingüe
## ¿Puedo refinar el rendimiento de mi aplicación en función de mi carga de trabajo?
Sí. El rendimiento de la aplicación depende de varios factores, todos los cuales pueden ser controlados por los clientes:
1. **AWS MSF KPUs**: La aplicación se implementa con un factor de paralelismo predeterminado de 2 y un paralelismo por KPU 1, con el escalado automático activado. Sin embargo, se recomienda que configure el escalado de la aplicación de Managed Service para Apache Flink según sus cargas de trabajo. Para obtener más información, consulte [Revise los recursos de aplicaciones de Managed Service for Apache Flink.](https://docs.aws.amazon.com/managed-flink/latest/java/how-resources.html)
1. **Amazon Bedrock**: según el modelo bajo demanda de Amazon Bedrock seleccionado, es posible que se apliquen cuotas diferentes. Revise las cuotas de servicio en Bedrock para ver la carga de trabajo que el servicio podrá gestionar. Para obtener más información, consulte [Quotas for Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html).
1. **Amazon OpenSearch Service**: Además, en algunas situaciones, es posible que notes que OpenSearch se trata de un cuello de botella en tu cartera de proyectos. Para obtener información sobre el escalado, consulte OpenSearch Escalar el [tamaño de los dominios OpenSearch de Amazon Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/sizing-domains.html).
## ¿Qué tipos de autenticación de Amazon MSK son compatibles?
IAM MSK es el único tipo de autenticación admitido.
## ¿Qué es `sink.os.bulkFlushIntervalMillis` y cómo se configura?
Al enviar datos a Amazon OpenSearch Service, el intervalo de descarga masiva es el intervalo en el que se ejecuta la solicitud masiva, independientemente del número de acciones o del tamaño de la solicitud. El valor predeterminado es de 1 milisegundo.
Si bien establecer un intervalo de vaciado puede ayudar a garantizar que los datos se indexen a tiempo, también puede generar un aumento de la sobrecarga si se establece un intervalo demasiado bajo. Tenga en cuenta su caso de uso y la importancia de una indexación puntual cuando se deba elegir un intervalo de vaciado.
## Cuando despliegue mi aplicación Managed Service para Apache Flink, ¿a partir de qué punto del tema Amazon MSK empezará a leer los mensajes?
La aplicación empezará a leer los mensajes del tema Amazon MSK con el desfase especificado por la configuración`source.msk.starting.offset` establecida en la configuración de tiempo de ejecución de la aplicación. Si `source.msk.starting.offset` no se establece de forma explícita, el comportamiento predeterminado de la aplicación es empezar a leer desde el primer mensaje disponible del tema.
## ¿Cómo uso `source.msk.starting.offset`?
Establezca `ource.msk.starting.offset` de forma explícita en uno de los siguientes valores, según el comportamiento deseado:
+ EARLY: la configuración predeterminada, que se lee desde el desplazamiento más antiguo de la partición. Es una buena opción, especialmente si:
+ Acaba de crear temas y aplicaciones para consumidores de Amazon MSK.
+ Necesita reproducir los datos para poder generar o reconstruir el estado. Esto es pertinente cuando se implementa el patrón de abastecimiento de eventos o cuando se inicializa un nuevo servicio que requiere una vista completa del historial de datos.
+ LATEST: la aplicación de Managed Service para Apache Flink leerá los mensajes del final de la partición. Se recomienda esta opción si solo importa que se generen nuevos mensajes y no se necesita procesar datos históricos. En esta configuración, el consumidor ignorará los mensajes existentes y solo leerá los nuevos publicados por el productor original.
+ COMMITTED: la aplicación Managed Service para Apache Flink empezará a consumir los mensajes que procedan de la misma cantidad de mensajes confirmados por el grupo consumidor. Si la compensación comprometida no existe, se utilizará la estrategia de restablecimiento EARLIEST.
## ¿Qué estrategias de fragmentación se admiten?
Estamos usando la biblioteca [langchain](https://js.langchain.com/v0.1/docs/get_started/introduction/) ara fragmentar las entradas. La fragmentación solo se aplica si la longitud de la entrada es mayor que el `maxSegmentSizeInChars` elegido. Se admiten los siguientes cinco tipos de fragmentación:
+ `SPLIT_BY_CHARACTER`: Cabrá tantos caracteres como sea posible en cada bloque donde la longitud de cada fragmento no sea superior a. maxSegmentSize InChars No importan los espacios en blanco, por lo que puede cortar palabras.
+ `SPLIT_BY_WORD`: encontrará espacios en blanco para fragmentarlos. No se corta ninguna palabra.
+ `SPLIT_BY_SENTENCE`: los límites de las oraciones se detectan con la biblioteca Apache OpenNLP con el modelo de oraciones en inglés.
+ `SPLIT_BY_LINE`: encontrará nuevos caracteres de línea para fragmentarlos.
+ `SPLIT_BY_PARAGRAPH`: encontrará nuevos caracteres de línea consecutivos para fragmentarlos.
Las estrategias de división recurren al orden anterior, donde las estrategias de segmentación más grandes como `SPLIT_BY_PARAGRAPH` recurren al orden anterior `SPLIT_BY_CHARACTER`. Por ejemplo, cuando se usa `SPLIT_BY_LINE`, si una línea es demasiado larga, se la subdivide por oración, y cada fragmento cabe en tantas oraciones como sea posible. Si alguna oración es demasiado larga, se fragmentarán las palabras. Si una palabra es demasiado larga, se dividirá por caracteres.
## ¿Cómo leo los registros de mi almacén de datos de vectores?
1. Cuando `source.msk.data.type` es `STRING`
+ **original\$1data**: la cadena original completa del mensaje de Amazon MSK.
+ **embedded\$1data**: vector de incrustación creado a partir de `chunk_data` si no está vacío (se aplica la fragmentación) o creado a partir de `original_data` si no se ha aplicado ninguna fragmentación.
+ **chunk\$1data**: solo está presente cuando los datos originales se fragmentaron. Contiene el fragmento del mensaje original que se utilizó para crear la incrustación en `embedded_data`.
1. Cuando `source.msk.data.type` es `JSON`
+ **original\$1data**: todo el JSON original del mensaje de Amazon MSK *después* de aplicar el filtrado de claves JSON.
+ **embedded\$1data**: vector de incrustación creado a partir de `chunk_data` si no está vacío (se aplica la fragmentación) o creado a partir de `original_data` si no se ha aplicado ninguna fragmentación.
+ **chunk\$1key**: solo está presente cuando los datos originales se fragmentaron. Contiene la clave JSON de la que proviene el fragmento en `original_data`. Por ejemplo, puede tener el mismo aspecto que `jsonKey1.nestedJsonKeyA` en el caso de las claves anidadas o de *metadatos* en el ejemplo de los `original_data`.
+ **chunk\$1data**: solo está presente cuando los datos originales se fragmentaron. Contiene el fragmento del mensaje original que se utilizó para crear la incrustación en `embedded_data`.
Sí, se pueden leer datos de varios temas de Amazon MSK con esta aplicación. Los datos de todos los temas deben ser del mismo tipo (STRING o JSON) o podrían provocar un error en la aplicación. Los datos de todos los temas se almacenan siempre en un único OpenSearch índice.
## ¿Dónde puedo encontrar nuevas actualizaciones del código fuente?
Ve a [https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases para comprobar si hay nuevos lanzamientos](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases).
## ¿Puedo realizar un cambio en la AWS CloudFormation plantilla y actualizar la aplicación Managed Service for Apache Flink?
No, al realizar un cambio en la AWS CloudFormation plantilla no se actualiza la aplicación Managed Service for Apache Flink. Cualquier cambio nuevo AWS CloudFormation implica la necesidad de implementar una nueva pila.
## ¿ AWS Supervisará y mantendrá la aplicación en mi nombre?
No, no supervisará, AWS escalará, actualizará ni parcheará esta aplicación en su nombre.
## ¿Esta aplicación mueve mis datos fuera de mi Cuenta de AWS?
Todos los datos leídos y almacenados por la aplicación Managed Service for Apache Flink permanecen en su cuenta Cuenta de AWS y nunca salen de su cuenta.
# Solución de problemas de esquemas de incrustación vectorial en tiempo real
Revise los siguientes temas de solución de problemas relacionados con los esquemas de incrustación vectorial en tiempo real. Para obtener más información sobre los esquemas de incrustación vectorial en tiempo real, consulte [Real-time vector embedding blueprints](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html).
**Topics**
+ [La implementación de mi CloudFormation pila ha fallado o se ha revertido. ¿Qué puedo hacer para solucionarlo?](#troubleshooting-blueprints-deployment)
+ [No deseo que mi aplicación empiece a leer los mensajes desde el principio de los temas de Amazon MSK. ¿Qué tengo que hacer?](#troubleshooting-blueprints-beginning)
+ [¿Cómo sé si hay un problema con mi aplicación Managed Service para Apache Flink y cómo puedo depurarlo?](#troubleshooting-blueprints-debug)
+ [¿Cuáles son las métricas clave que debo monitorear para mi aplicación Managed Service para Apache Flink?](#troubleshooting-blueprints-metrics)
## La implementación de mi CloudFormation pila ha fallado o se ha revertido. ¿Qué puedo hacer para solucionarlo?
+ Vaya a la pila de CFN y encuentre el motivo del fallo de la pila. Podría estar relacionado con la falta de permisos o con colisiones de nombres de recursos de AWS , entre otras causas. Corrija la causa principal del error de implementación. Para obtener más información, consulta la [guía CloudWatch de solución de problemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#basic-ts-guide).
+ [Opcional] Solo puede haber un punto de conexión de VPC por servicio y por VPC. Si implementaste varios planos de incrustación vectorial en tiempo real para escribirlos en las colecciones de Amazon OpenSearch Service de la misma VPC, es posible que compartan puntos de enlace de la VPC. Es posible que ya estén presentes en su cuenta de la VPC o que la primera pila de planos de incrustación vectorial en tiempo real cree puntos de enlace de VPC para Amazon Bedrock y Amazon OpenSearch Service que se utilizarán en todas las demás pilas implementadas en su cuenta. Si se produce un error en una pila, compruebe si esa pila creó puntos de enlace de VPC para Amazon Bedrock y OpenSearch Amazon Service y elimínelos si no se utilizan en ningún otro lugar de su cuenta. Para conocer los pasos para eliminar los puntos finales de la VPC, consulte la documentación sobre cómo eliminar la aplicación de forma segura.
+ Es posible que haya otros servicios o aplicaciones en su cuenta que utilicen el punto de conexión de VPC. Si se elimina, es posible que se produzcan interrupciones en la red de otros servicios. Tenga cuidado al eliminar estos puntos de conexión.
## No deseo que mi aplicación empiece a leer los mensajes desde el principio de los temas de Amazon MSK. ¿Qué tengo que hacer?
Debe establecer `source.msk.starting.offset` de forma explícita en uno de los siguientes valores, en función del comportamiento deseado:
+ **Desplazamiento más temprano**: el desplazamiento más antiguo de la partición.
+ **Último desplazamiento**: los consumidores leerán los mensajes del final de la partición.
+ **Desplazamiento confirmado**: lee el último mensaje que el consumidor procesó dentro de una partición.
## ¿Cómo sé si hay un problema con mi aplicación Managed Service para Apache Flink y cómo puedo depurarlo?
Utilice la [guía de solución de problemas de Managed Service para Apache Flink](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html) para depurar los problemas relacionados con Managed Service para Apache Flink en su aplicación.
## ¿Cuáles son las métricas clave que debo monitorear para mi aplicación Managed Service para Apache Flink?
+ Todas las métricas disponibles para una aplicación de Managed Service para Apache Flink normal pueden ayudarlo a monitorear la aplicación. Para más información, consulte [Metrics and dimensions in Managed Service for Apache Flink](https://docs.aws.amazon.com/managed-flink/latest/java/metrics-dimensions.html).
+ Para supervisar las métricas de Amazon Bedrock, consulte [ CloudWatch las métricas de Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html#runtime-cloudwatch-metrics).
+ Se han agregado dos métricas nuevas para monitorear el rendimiento de la generación de incrustaciones. Búscalas bajo el nombre de la `EmbeddingGeneration` operación en. CloudWatch Las dos métricas son:
+ **BedrockTitanEmbeddingTokenCount**: Número de fichas presentes en una sola solicitud a Amazon Bedrock.
+ **BedrockEmbeddingGenerationLatencyMs**: Indica el tiempo que se tarda en enviar y recibir una respuesta de Amazon Bedrock para generar incrustaciones, en milisegundos.
+ Para las colecciones sin servidor de Amazon OpenSearch Service, puedes usar métricas como`IngestionDataRate`, entre `IngestionDocumentErrors` otras. Para obtener más información, consulte [Supervisión de OpenSearch Serverless con Amazon CloudWatch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/monitoring-cloudwatch.html).
+ Para ver las métricas OpenSearch aprovisionadas, consulta [Supervisar las métricas OpenSearch del clúster con Amazon CloudWatch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-cloudwatchmetrics.html).
# Solución de problemas de tiempo de ejecución
Esta sección contiene información sobre el diagnóstico y la solución de problemas de tiempo de ejecución con su aplicación Managed Service para Apache Flink.
**Topics**
+ [Herramientas de solución de problemas](#troubleshooting-tools)
+ [Problemas con las aplicaciones](troubleshooting-symptoms.md)
+ [La aplicación se está reiniciando](troubleshooting-rt-restarts.md)
+ [El rendimiento es demasiado lento](troubleshooting-rt-throughput.md)
+ [Crecimiento de estado ilimitado](troubleshooting-rt-stateleaks.md)
+ [Operadores vinculados a E/S](troubleshooting-io-bound-operators.md)
+ [Limitación ascendente o de origen desde un flujo de datos de Kinesis](troubleshooting-source-throttling.md)
+ [Puntos de control](troubleshooting-checkpoints.md)
+ [Agotamiento del tiempo para llegar al punto de control](troubleshooting-chk-timeout.md)
+ [Fallo en el punto de control de la aplicación Apache Beam](troubleshooting-chk-failure-beam.md)
+ [Resistencia](troubleshooting-backpressure.md)
+ [Sesgo de datos](troubleshooting-data-skew.md)
+ [Sesgo de estado](troubleshooting-state-skew.md)
+ [Integración con recursos en diferentes regiones](troubleshooting-resources-in-different-regions.md)
## Herramientas de solución de problemas
La herramienta principal para detectar problemas en las aplicaciones son CloudWatch las alarmas. Con CloudWatch las alarmas, puede establecer umbrales para CloudWatch las métricas que indiquen las condiciones de error o embotellamiento en su aplicación. Para obtener información sobre las CloudWatch alarmas recomendadas, consulte. [Usa CloudWatch alarmas con Amazon Managed Service para Apache Flink](monitoring-metrics-alarms.md)
# Problemas con las aplicaciones
Esta sección contiene soluciones para las condiciones de error que puede encontrar en su aplicación Managed Service para Apache Flink.
**Topics**
+ [La aplicación está atascada en un estado transitorio](#troubleshooting-rt-stuck)
+ [Fallo en la creación de la instantánea](#troubleshooting-rt-snapshots)
+ [No puedo obtener acceso a los recursos de una VPC](#troubleshooting-rt-vpc)
+ [Los datos se pierden al escribir en un bucket de Amazon S3](#troubleshooting-rt-s3)
+ [La aplicación está en estado EJECUCIÓN pero no está procesando datos](#troubleshooting-rt-processing)
+ [Error de instantánea, actualización de la aplicación o parada de la aplicación: InvalidApplicationConfigurationException](#troubleshooting-rt-appconfigexception)
+ [java.nio.file. NoSuchFileException:/usr/local/openjdk-8/lib/security/cacerts](#troubleshooting-rt-fnf)
## La aplicación está atascada en un estado transitorio
Si la aplicación permanece en un estado transitorio (`STARTING``UPDATING`,`STOPPING`, o`AUTOSCALING`), puede detenerla mediante la [StopApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_StopApplication.html)acción con el `Force` parámetro establecido en. `true` No puede forzar la detención de una aplicación en el estado `DELETING`. Como alternativa, si la aplicación está en el estado `UPDATING` o `AUTOSCALING`, puede revertirla a la versión anterior en ejecución. Cuando se revierte una aplicación, se cargan los datos de estado de la última instantánea correcta. Si la aplicación no tiene instantáneas, Managed Service para Apache Flink rechaza la solicitud de reversión. Para obtener más información sobre cómo anular una aplicación, consulte la [RollbackApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_RollbackApplication.html)acción.
**nota**
La detención forzosa de la aplicación puede provocar la pérdida o la duplicación de datos. Para evitar la pérdida de datos o el procesamiento duplicado de los datos durante los reinicios de la aplicación, se recomienda que tome instantáneas frecuentes de la aplicación.
Algunas causas para las aplicaciones atascadas incluyen las siguientes:
+ **El estado de la aplicación es demasiado grande:** tener un estado de aplicación demasiado grande o demasiado persistente puede provocar que la aplicación se bloquee durante un punto de comprobación o una operación de captura de pantalla. Compruebe el `lastCheckpointDuration` de su aplicación y las métricas `lastCheckpointSize` para valores que aumentan de forma constante o valores anormalmente altos.
+ **El código de la aplicación es demasiado grande:** compruebe que el archivo JAR de la aplicación tenga un tamaño inferior a 512 MB. No se admiten archivos JAR de más de 512 MB.
+ **Falla la creación de la instantánea de la aplicación:** Managed Service para Apache Flink toma una instantánea de la aplicación durante una solicitud de [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_UpdateApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_UpdateApplication.html) o [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_StopApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_StopApplication.html). Luego, el servicio utiliza este estado de instantánea y restaura la aplicación con la configuración de la aplicación actualizada para proporcionar una semántica de procesamiento *exactamente una vez*. Si falla la creación automática de instantáneas, consulte [Fallo en la creación de la instantánea](#troubleshooting-rt-snapshots).
+ **Falla la restauración a partir de una instantánea:** si elimina o cambia un operador de una actualización de la aplicación e intenta realizar la restauración a partir de una instantánea, la restauración fallará de forma predeterminada si la instantánea contiene datos de estado del operador que falta. Además, la aplicación quedará bloqueada en el estado `STOPPED` o `UPDATING`. Para cambiar este comportamiento y permitir que la restauración se realice correctamente, cambie el *AllowNonRestoredState*parámetro de la aplicación [FlinkRunConfiguration](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_FlinkRunConfiguration.html)a`true`. Esto permitirá que la operación de reanudación omita los datos de estado que no se pueden asignar al nuevo programa.
+ **La inicialización de la aplicación está tardando más tiempo:** Managed Service para Apache Flink utiliza un tiempo de espera interno de 5 minutos (configuración predeterminada) mientras se espera a que se inicie un trabajo de Flink. Si su trabajo no puede comenzar dentro de este tiempo de espera, verá el siguiente CloudWatch registro:
```
Flink job did not start within a total timeout of 5 minutes for application: %s under account: %s
```
Si aparece el error anterior, significa que las operaciones definidas en el método del trabajo de Flink `main` están tardando más de 5 minutos, lo que provoca que se agote el tiempo de espera para la creación del trabajo de Flink en el extremo de Managed Service para Apache Flink. Te sugerimos que consultes los **JobManager**registros de Flink y el código de tu aplicación para comprobar si se espera este retraso en el `main` método. De lo contrario, debe tomar medidas para solucionar el problema de modo que se complete en menos de 5 minutos.
Se puede comprobar el estado de su aplicación mediante [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html) o las acciones de [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html).
## Fallo en la creación de la instantánea
El servicio Managed Service para Apache Flink no puede tomar una instantánea en las siguientes circunstancias:
+ La aplicación ha superado el límite de instantáneas. El límite de instantáneas es 1000. Para obtener más información, consulte [Administración de copias de seguridad de aplicaciones con instantáneas](how-snapshots.md).
+ La aplicación no tiene permisos para acceder a su fuente o receptor.
+ El código de la aplicación no funciona correctamente.
+ La aplicación tiene otros problemas de configuración.
Si se produce una excepción al tomar una instantánea durante una actualización de la aplicación o al detener la aplicación, defina la propiedad `SnapshotsEnabled` de la aplicación [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ApplicationSnapshotConfiguration.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ApplicationSnapshotConfiguration.html) a `false` y vuelva a intentar la solicitud.
Las instantáneas pueden fallar si los operadores de la aplicación no están debidamente aprovisionados. Para obtener información sobre cómo ajustar el rendimiento de los operadores, consulte [Escalado de operadores](performance-improving.md#performance-improving-scaling-op).
Una vez que la aplicación vuelva a su estado correcto, se recomienda establecer la propiedad de `SnapshotsEnabled` de la aplicación en `true`.
## No puedo obtener acceso a los recursos de una VPC
Si la aplicación utiliza una VPC que se ejecuta en Amazon VPC, haga lo siguiente para comprobar que la aplicación tenga acceso a sus recursos:
+ Comprueba tus CloudWatch registros para ver si hay el siguiente error. Este error indica que la aplicación no puede acceder a los recursos de la VPC:
```
org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms.
```
Si ve este error, compruebe que las tablas de enrutamiento estén configuradas correctamente y que los conectores tengan la configuración de conexión correcta.
Para obtener información sobre la configuración y el análisis de CloudWatch los registros, consulte[Registro y supervisión en Amazon Managed Service para Apache Flink](monitoring-overview.md).
## Los datos se pierden al escribir en un bucket de Amazon S3
Es posible que se produzcan algunas pérdidas de datos al escribir la salida en un bucket de Amazon S3 con Apache Flink versión 1.6.2. Se recomiendautilizar la última versión compatible de Apache Flink cuando utilice Amazon S3 para la salida directa. Para escribir en un bucket de Amazon S3 mediante Apache Flink 1.6.2, se recomienda que utilice Firehose. Para obtener más información sobre el uso de Firehose con Managed Service para Apache Flink, consulte [Receptor de Firehose](earlier.md#get-started-exercise-fh).
## La aplicación está en estado EJECUCIÓN pero no está procesando datos
Se puede comprobar el estado de su aplicación mediante [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html) o las acciones de [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html). Si tu aplicación introduce el `RUNNING` estado pero no escribe datos en tu receptor, puedes solucionar el problema añadiendo un CloudWatch registro de Amazon a tu aplicación. Para obtener más información, consulte [Trabaje con las opciones de CloudWatch registro de aplicaciones](cloudwatch-logs.md#adding_cloudwatch). El flujo de registro contiene mensajes que pueden ayudarlo a solucionar cualquier problema con la aplicación.
## Error de instantánea, actualización de la aplicación o parada de la aplicación: InvalidApplicationConfigurationException
Se puede producirse un error similar al siguiente durante una operación de instantánea o durante una operación que crea una instantánea, como la actualización o la detención de una aplicación:
```
An error occurred (InvalidApplicationConfigurationException) when calling the UpdateApplication operation:
Failed to take snapshot for the application xxxx at this moment. The application is currently experiencing downtime.
Please check the application's CloudWatch metrics or CloudWatch logs for any possible errors and retry the request.
You can also retry the request after disabling the snapshots in the Managed Service for Apache Flink console or by updating
the ApplicationSnapshotConfiguration through the AWS SDK
```
Este error se produce cuando la aplicación no puede crear una instantánea.
Si encuentra este error durante una operación de captura de pantalla o una operación que crea una instantánea, haga lo siguiente:
+ Deshabilite las instantáneas para su aplicación. Puede hacerlo en la consola de Managed Service for Apache Flink o mediante el `SnapshotsEnabledUpdate` parámetro de la [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)acción.
+ Investigue por qué no se pueden crear instantáneas. Para obtener más información, consulte [La aplicación está atascada en un estado transitorio](#troubleshooting-rt-stuck).
+ Vuelva a activar las instantáneas cuando la aplicación vuelva a estar en buen estado.
## java.nio.file. NoSuchFileException:/usr/local/openjdk-8/lib/security/cacerts
La ubicación del almacén de confianza SSL se actualizó en una implementación anterior. Utilice los siguientes valores para el parámetro `ssl.truststore.location` en su lugar:
```
/usr/lib/jvm/java-11-amazon-corretto/lib/security/cacerts
```
# La aplicación se está reiniciando
Si la aplicación no está en buen estado, el trabajo en Apache Flink fallará y se reiniciará continuamente. En esta sección se describen los síntomas y los pasos para solucionar esta condición.
## Síntomas
Esta condición puede tener los siguientes síntomas:
+ La métrica `FullRestarts` no es cero. Esta métrica representa el número de veces que se ha reiniciado el trabajo de la aplicación desde que se inició la aplicación.
+ La métrica `Downtime` no es cero. Esta métrica representa el número de milisegundos en los que la aplicación se encuentra en estado `FAILING` o `RESTARTING`.
+ El registro de la aplicación contiene cambios de estado a `RESTARTING` o `FAILED`. Puede consultar el registro de su aplicación para ver estos cambios de estado mediante la siguiente consulta de CloudWatch Logs Insights:[Errores de análisis: errores relacionados con las tareas de la aplicación](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
## Causas y soluciones
Las siguientes condiciones pueden provocar que la aplicación se vuelva inestable y se reinicie repetidamente:
+ **El operador está emitiendo una excepción:** si una excepción en un operador de la aplicación no se gestiona, la aplicación realiza una conmutación por error (sobre la base de que el operador no puede gestionar la falla). La aplicación se reinicia desde el último punto de control para mantener la semántica de procesamiento “una sola vez”. Como resultado, `Downtime` no es cero durante estos períodos de reinicio. Para evitar que esto suceda, le recomendamos que gestione cualquier excepción reintentable en el código de la aplicación.
Puede investigar las causas de esta condición consultando los registros de la aplicación para ver si el estado de la aplicación cambió de `RUNNING` a `FAILED`. Para obtener más información, consulte [Errores de análisis: errores relacionados con las tareas de la aplicación](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
+ **Los flujos de datos de Kinesis no se suministran correctamente:** si el origen o el receptor de la aplicación es un flujo de datos de Kinesis, compruebe si las [métricas](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html) del flujo presentan los errores `ReadProvisionedThroughputExceeded` o `WriteProvisionedThroughputExceeded`.
Si ve estos errores, puede aumentar el rendimiento disponible para el flujo de Kinesis aumentando el número de particiones del flujo. Para más información, consulte [ How do I change the number of open shards in Kinesis Data Streams?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-open-shards/)
+ **No hay otros orígenes o receptores disponibles o no se los suministra correctamente:** compruebe que la aplicación suministre correctamente los orígenes y los receptores. Compruebe que todas las fuentes o receptores utilizados en la aplicación (como otros AWS servicios o fuentes o destinos externos) estén bien aprovisionadas, no sufran limitaciones de lectura o escritura o no estén disponibles periódicamente.
Si tiene problemas de rendimiento con sus servicios dependientes, aumente los recursos disponibles para esos servicios o, bien, investigue la causa de cualquier error o falta de disponibilidad.
+ **No se suministran correctamente los operadores:** si la carga de trabajo de los subprocesos de uno de los operadores de la aplicación no se distribuye correctamente, es posible que el operador se sobrecargue y la aplicación se bloquee. Para obtener información sobre cómo ajustar el paralelismo de los operadores, consulte [Gestión correcta del escalado del operador](performance-improving.md#performance-improving-scaling-op).
+ **La aplicación produce un error DaemonException:** este error aparece en el registro de la aplicación si utiliza una versión de Apache Flink anterior a la 1.11. Es posible que necesite actualizar a una versión posterior de Apache Flink para poder utilizar una versión de KPL 0.14 o posterior.
+ **La aplicación falla con TimeoutException FlinkException, o RemoteTransportException:** estos errores pueden aparecer en el registro de la aplicación si los administradores de tareas fallan. Si la aplicación está sobrecargada, los administradores de tareas pueden experimentar una presión en los recursos de CPU o memoria y hacer que fallen.
Estos errores pueden ser similares a los siguientes:
+ `java.util.concurrent.TimeoutException: The heartbeat of JobManager with id xxx timed out`
+ `org.apache.flink.util.FlinkException: The assigned slot xxx was removed`
+ `org.apache.flink.runtime.io.network.netty.exception.RemoteTransportException: Connection unexpectedly closed by remote task manager`
Para solucionar este problema, compruebe lo siguiente:
+ Comprueba tus CloudWatch métricas para detectar picos inusuales en el uso de la CPU o la memoria.
+ Compruebe si la aplicación tiene problemas de rendimiento. Para obtener más información, consulte [Solución de problemas de rendimiento](performance-troubleshooting.md).
+ Examine el registro de la aplicación para detectar excepciones no gestionadas que esté generando el código de la aplicación.
+ **La aplicación falla y aparece el error JaxbAnnotationModule No se encuentra:** este error se produce si la aplicación usa Apache Beam, pero no tiene las dependencias o versiones de dependencia correctas. Las aplicaciones de Managed Service para Apache Flink que utilizan Apache Beam deben utilizar las siguientes versiones de dependencias:
```
2.10.2
...
com.fasterxml.jackson.module
jackson-module-jaxb-annotations
2.10.2
```
Si no proporciona la versión correcta de `jackson-module-jaxb-annotations` como dependencia explícita, la aplicación la cargará desde las dependencias del entorno y, como las versiones no coincidirán, la aplicación se bloqueará durante el tiempo de ejecución.
Para obtener más información sobre el uso de Apache Beam con Managed Service para Apache Flink, consulte [Utilice CloudFormationCreación de una aplicación con Apache Beam](examples-beam.md).
+ **La aplicación falla con java.io. IOException: Número insuficiente de búferes de red**
Esto ocurre cuando una aplicación no tiene suficiente memoria asignada para los búferes de red. Los búferes de red facilitan la comunicación entre las subtareas. Se los utiliza para almacenar registros antes de transmitirlos a través de una red y para almacenar los datos entrantes antes de dividirlos en registros y destinarlos a subtareas. La cantidad de búferes de red necesarios escala directamente según el paralelismo y la complejidad del gráfico de trabajo. Existen varios enfoques para mitigar este problema:
+ Puede configurar un `parallelismPerKpu` más bajo para que haya más memoria asignada por subtarea y búferes de red. Tenga en cuenta que bajar el `parallelismPerKpu` aumentará la KPU y, por lo tanto, el costo. Para evitarlo, puede reducir el paralelismo según el mismo factor para mantener la misma cantidad de KPU.
+ Puede simplificar el gráfico de tareas reduciendo el número de operadores o encadenándolos para que se necesiten menos búferes.
+ De lo contrario, puede ponerse en contacto con nosotros https://aws.amazon.com/premiumsupport/ para obtener una configuración personalizada del búfer de red.
# El rendimiento es demasiado lento
Si su aplicación no procesa los datos de streaming entrantes con la suficiente rapidez, tendrá un rendimiento deficiente y se volverá inestable. En esta sección se describen los síntomas y los pasos para solucionar esta condición.
## Síntomas
Esta condición puede tener los siguientes síntomas:
+ Si el origen de datos de su aplicación es un flujo de Kinesis, la métrica `millisbehindLatest` del flujo aumenta continuamente.
+ Si el origen de datos de su aplicación es un clúster de Amazon MSK, las métricas de desfase de consumo del clúster aumentan continuamente. Para obtener más información, consulte [ Supervisión del desfase del consumidor](https://docs.aws.amazon.com/msk/latest/developerguide/consumer-lag.html) en la [ Guía para desarrolladores de Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html).
+ Si el origen de datos de su aplicación es un servicio o una fuente diferente, compruebe las métricas de desfase de consumo o los datos disponibles.
## Causas y soluciones
La lentitud del rendimiento de las aplicaciones puede deberse a muchas causas. Si la aplicación no está al día con las entradas, compruebe lo siguiente:
+ Si el desfase en el rendimiento aumenta repentinamente y luego se va reduciendo, compruebe si la aplicación se está reiniciando. La aplicación dejará de procesar las entradas mientras se reinicia, lo que provocará un aumento repentino del desfase. Para obtener más información acerca de las fallas de aplicaciones, consulte [La aplicación se está reiniciando](troubleshooting-rt-restarts.md).
+ Si el desfase en el rendimiento es constante, compruebe si la aplicación está optimizada para el rendimiento. Para obtener información sobre cómo optimizar el rendimiento de la aplicación, consulte [Solución de problemas de rendimiento](performance-troubleshooting.md).
+ Si el desfase en el rendimiento no está aumentando repentinamente, sino que aumenta continuamente, y su aplicación está optimizada para el rendimiento, debe aumentar los recursos de la aplicación. Para obtener información sobre cómo aumentar los recursos de las aplicaciones, consulte [Implementación del escalado de aplicaciones](how-scaling.md).
+ Si su aplicación lee datos de un clúster de Kafka situado en una región diferente y `FlinkKafkaConsumer` o `KafkaSource` están prácticamente inactivos (con un nivel `idleTimeMsPerSecond` alto o `CPUUtilization` bajo) a pesar del elevado desfase del consumidor, puede aumentar el valor de `receive.buffer.byte`, por ejemplo, 2 097 152. Para obtener más información, consulte la sección sobre entornos de alta latencia en [Configuraciones personalizadas de MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html).
Para ver los pasos de solución de problemas relacionados con el rendimiento lento o el aumento del desfase del consumidor en el origen de la aplicación, consulte [Solución de problemas de rendimiento](performance-troubleshooting.md).
# Crecimiento de estado ilimitado
Si su aplicación no elimina adecuadamente la información de estado desactualizada, esta se acumulará continuamente y provocará problemas de rendimiento o estabilidad de la aplicación. En esta sección se describen los síntomas y los pasos para solucionar esta condición.
## Síntomas
Esta condición puede tener los siguientes síntomas:
+ La métrica `lastCheckpointDuration` está aumentando o teniendo picos gradualmente.
+ La métrica `lastCheckpointSize` está aumentando o teniendo picos gradualmente.
## Causas y soluciones
Las siguientes condiciones pueden provocar que su aplicación acumule datos de estado:
+ Su aplicación retiene los datos de estado por más tiempo del necesario.
+ Su aplicación utiliza consultas de ventana con una duración demasiado larga.
+ No configuró el TTL para sus datos de estado. Para obtener más información, consulte [State Time-To-Live (TTL)](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) en la documentación de Apache Flink.
+ Está ejecutando una aplicación que depende de la versión 2.25.0 o posterior de Apache Beam. Puede excluirse de la nueva versión de la transformación de lectura [ampliando la suya BeamApplicationProperties](https://docs.aws.amazon.com/managed-flink/latest/java/examples-beam.html#examples-beam-configure) con los experimentos y el valor clave. `use_deprecated_read` Para obtener más información, consulte la [documentación de Apache Beam](https://beam.apache.org/blog/beam-2.25.0/#highlights).
A veces, las aplicaciones se enfrentan a un crecimiento cada vez mayor del tamaño de estado, lo que no es sostenible a largo plazo (al fin y al cabo, una aplicación de Flink se ejecuta indefinidamente). A veces, esto se debe a que las aplicaciones almacenan los datos en estado y no conservan adecuadamente la información antigua. Pero a veces hay expectativas irrazonables sobre lo que Flink puede ofrecer. Las aplicaciones pueden usar agregaciones durante largos períodos de tiempo que abarcan días o incluso semanas. A menos que [AggregateFunctions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/#aggregatefunction)se utilicen, que permiten agregaciones incrementales, Flink debe mantener en estado actualizado los eventos de toda la ventana.
Además, al utilizar funciones de proceso para implementar operadores personalizados, la aplicación debe eliminar los datos del estado que ya no son necesarios para la lógica de negocios. En ese caso, el [estado](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) se time-to-live puede utilizar para anticuar automáticamente los datos en función del tiempo de procesamiento. Managed Service para Apache Flink utiliza puntos de control incrementales y, por lo tanto, el ttl del estado se basa en la [compactación de RockSDB](https://github.com/facebook/rocksdb/wiki/Compaction). Solo se puede observar una reducción real en el tamaño del estado (indicada por el tamaño del punto de control) después de una operación de compactación. En concreto, en el caso de los puntos de control con un tamaño inferior a 200 MB, es poco probable que se observe una reducción en el tamaño de los puntos de control como consecuencia de la caducidad del estado. Sin embargo, los puntos de guardado se basan en una copia limpia del estado que no contiene datos antiguos, por lo que puede activar una instantánea en Managed Service para Apache Flink para forzar la eliminación del estado obsoleto.
Con fines de depuración, puede resultar útil desactivar los puntos de control incrementales para comprobar con mayor rapidez si el tamaño de los puntos de control realmente disminuye o se estabiliza (y evitar así el efecto de compactación en RocksBS). Sin embargo, esto requiere una solicitud de asistencia con el equipo de servicio.
# Operadores vinculados a E/S
Es mejor evitar las dependencias de sistemas externos en la ruta de datos. Suele ser mucho más eficaz mantener un conjunto de datos de referencia en estado en lugar de consultar un sistema externo para enriquecer los eventos individuales. Sin embargo, a veces hay dependencias que no se pueden cambiar fácilmente de estado, por ejemplo, si desea enriquecer los eventos con un modelo de machine learning alojado en Amazon SageMaker.
Los operadores que interactúan con sistemas externos a través de la red pueden convertirse en un obstáculo y causar contrapresión. Se recomienda encarecidamente utilizar [AsyncIO](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/) para implementar la funcionalidad, reducir el tiempo de espera de las llamadas individuales y evitar que toda la aplicación se ralentice.
Además, para las aplicaciones con operadores I/O enlazados, también puede tener sentido aumentar la configuración de [ParallelismPerKPU](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_ParallelismConfiguration.html) de la aplicación Managed Service for Apache Flink. Este ajuste describe el número de subtareas paralelas que una aplicación puede realizar por unidad de procesamiento de Kinesis (KPU). Al aumentar el valor predeterminado de 1 a, por ejemplo, 4, la aplicación aprovecha los mismos recursos (y tiene el mismo costo), pero se puede escalar hasta cuadruplicar el paralelismo. Esto funciona bien para las aplicaciones I/O enlazadas, pero genera una sobrecarga adicional para las aplicaciones que no I/O están enlazadas.
# Limitación ascendente o de origen desde un flujo de datos de Kinesis
**Síntoma**: la aplicación encuentra `LimitExceededExceptions` de su flujo de datos de Kinesis de origen ascendente.
**Causa potencial**: la configuración predeterminada del conector Kinesis de la biblioteca Apache Flink está configurada para leer desde la fuente de flujo de datos de Kinesis, con una configuración predeterminada muy agresiva para el número máximo de registros recuperados por llamada `GetRecords`. Apache Flink está configurado de forma predeterminada para recuperar 10 000 registros por llamada a `GetRecords` (esta llamada se realiza de forma predeterminada cada 200 ms), aunque el límite por partición es de solo 1000 registros.
Este comportamiento predeterminado puede provocar una limitación al intentar consumir datos del flujo de datos de Kinesis, lo que afectará al rendimiento y la estabilidad de las aplicaciones.
Puede confirmarlo comprobando la CloudWatch `ReadProvisionedThroughputExceeded` métrica y viendo períodos prolongados o sostenidos en los que esta métrica es superior a cero.
También puedes ver esto en CloudWatch los registros de tu aplicación Amazon Managed Service for Apache Flink si observas `LimitExceededException` los errores continuos.
**Solución**: el cliente puede hacer una de estas dos cosas para resolver esta situación:
+ Reducción del límite predeterminado de la cantidad de registros recuperados por llamada a `GetRecords`
+ Habilitación de las lecturas adaptables en su aplicación Amazon Managed Service para Apache Flink. Para obtener más información sobre la característica de lecturas adaptables, consulte [SHARD\$1USE\$1ADAPTIVE\$1READS](https://nightlies.apache.org/flink/flink-docs-release-1.10/api/java/org/apache/flink/streaming/connectors/kinesis/config/ConsumerConfigConstants.html#SHARD_USE_ADAPTIVE_READS)
# Puntos de control
Los puntos de control son el mecanismo de Flink para garantizar que el estado de una aplicación sea tolerante a errores. El mecanismo permite a Flink recuperar el estado de los operadores si el trabajo falla y proporciona a la aplicación la misma semántica que cuando se ejecuta sin errores. Con Managed Service for Apache Flink, el estado de una aplicación se almacena en RockSDB, un key/value almacén integrado que mantiene su estado de funcionamiento en el disco. Cuando se toma un punto de control, el estado también se carga en Amazon S3, por lo que, incluso si se pierde el disco, el punto de control se puede utilizar para restaurar el estado de la aplicación.
Para obtener más información, consulte [How does State Snapshotting Work?](https://nightlies.apache.org/flink/flink-docs-master/docs/learn-flink/fault_tolerance/#how-does-state-snapshotting-work).
## Fases de creación de punto de comprobación
La subtarea de un operador de puntos de control en Flink consta de 5 etapas principales:
+ Espera [**Desfase de inicio**]: Flink utiliza barreras de puntos de control que se insertan en el flujo, por lo que el tiempo en esta fase es el tiempo que el operador espera a que la barrera del punto de control llegue a ella.
+ Alineación [**Duración de la alineación**]: en esta fase, la subtarea ha alcanzado una barrera, pero está esperando a que aparezcan barreras de otros flujos de entrada.
+ Puntos de control de sincronización [**Duración de la sincronización**]: en esta fase, la subtarea toma la instantánea del estado del operador y bloquea el resto de las actividades de la subtarea.
+ Puntos de control asíncronos [**Duración asíncrona**]: la mayor parte de esta fase consiste en que la subtarea carga el estado a Amazon S3. Durante esta fase, la subtarea ya no está bloqueada y puede procesar registros.
+ Reconocimiento: por lo general, se trata de una etapa breve y consiste simplemente en la subtarea de enviar un acuse de recibo JobManager y también de ejecutar cualquier mensaje de confirmación (por ejemplo, con los receptores de Kafka).
Cada una de estas fases (aparte de la Confirmación) se asigna a una métrica de duración de los puntos de comprobación que está disponible en la WebUI de Flink, que puede ayudar a aislar la causa del punto de control largo.
Para ver una definición exacta de cada una de las métricas disponibles en los puntos de control, vaya a la [pestaña Historial](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/#history-tab).
## Investigación
Al investigar la duración prolongada de los puntos de control, lo más importante es determinar el cuello de botella del punto de control, es decir, qué operador y subtarea están tardando más en llegar al punto de control y qué fase de esa subtarea está tardando más tiempo. Esto se puede determinar mediante la WebUI de Flink en la tarea de punto de comprobación de trabajos. La interfaz web de Flink proporciona datos e información que ayudan a investigar los problemas relacionados con los puntos de control. Para obtener un desglose completo, consulte [Monitoring Checkpointing](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/).
Lo primero que hay que tener en cuenta es la **Duración de principio a fin** de cada operador en el gráfico de tareas para determinar qué operador está tardando en llegar al punto de comprobación y merece una investigación más profunda. Según la documentación de Flink, la definición de la duración es:
*El tiempo transcurrido desde la fecha y hora de activación hasta el último acuse de recibo (o n/a si aún no se ha recibido ningún acuse de recibo). La duración de un punto de control completo de principio a fin viene determinada por la última subtarea que confirma el punto de comprobación. Este tiempo suele ser superior al que necesitan las subtareas individuales para comprobar realmente el estado.*
Las demás duraciones del punto de comprobación también proporcionan información más detallada sobre a qué se dedica el tiempo.
Si la **Duración de la sincronización** es alta, esto indica que algo está sucediendo durante la captura de pantalla. Durante esta fase se utiliza `snapshotState()` para clases que implementan la interfaz SnapshotState; puede ser código de usuario, por lo que los volcados de subprocesos pueden resultar útiles para investigar este aspecto.
Una **Duración asíncrona** prolongada sugeriría que se está dedicando mucho tiempo a cargar el estado en Amazon S3. Esto puede ocurrir si el estado es grande o si se están cargando muchos archivos de estado. Si este es el caso, vale la pena investigar cómo utiliza la aplicación el estado y asegurarse de que se utilizan las estructuras de datos nativas de Flink siempre que sea posible ([con el estado clave](https://nightlies.apache.org/flink/flink-docs-master/docs/dev/datastream/fault-tolerance/state/#using-keyed-state)). Managed Service para Apache Flink configura Flink de tal manera que se minimiza el número de llamadas a Amazon S3 y se asegura de que no se prolongue demasiado. El siguiente es un ejemplo de las estadísticas de puntos de control de un operador. Muestra que la **Duración asíncrona** es relativamente larga en comparación con las estadísticas de puntos de control del operador anteriores.
![\[Investigación de los puntos de control\]](http://docs.aws.amazon.com/es_es/managed-flink/latest/java/images/checkpoint.png)
Si el **Desfase de inicio** es alto, indicaría que la mayor parte del tiempo se dedica a esperar a que la barrera del punto de control llegue al operador. Esto indica que la solicitud está tardando un tiempo en procesar los registros, lo que significa que la barrera está pasando lentamente por el gráfico de tareas. Este suele ser el caso si el Trabajo tiene resistencia o si un operador está constantemente ocupado. El siguiente es un ejemplo de un JobGraph caso en el que el segundo KeyedProcess operador está ocupado.
![\[Investigación de los puntos de control\]](http://docs.aws.amazon.com/es_es/managed-flink/latest/java/images/checkpoint2.png)
Puedes investigar qué está tardando tanto utilizando Flink Flame Graphs o volcando TaskManager hilos. Una vez identificado el cuello de botella, se puede investigar más a fondo utilizando gráficos tipo llama o volcados de subprocesos.
## Volcados de subprocesos
Los volcados de subprocesos son otra herramienta de depuración que se encuentra en un nivel ligeramente inferior al de los gráficos tipo llama. Un volcado de subprocesos genera el estado de ejecución de todos los subprocesos en un momento dado. Flink toma un volcado de subprocesos de JVM, que es un estado de ejecución de todos los subprocesos del proceso de Flink. El estado de un subproceso se presenta mediante un seguimiento de la pila del subproceso, así como información adicional. En realidad, los gráficos tipo llama se crean utilizando múltiples seguimientos de la pila tomados en rápida sucesión. El gráfico es una visualización hecha a partir de estos seguimientos que facilita la identificación de las rutas de código más comunes.
```
"KeyedProcess (1/3)#0" prio=5 Id=1423 RUNNABLE
at app//scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:154)
at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(>19)
at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(:14)
at app//org.apache.flink.streaming.api.operators.KeyedProcessOperator.processElement(KeyedProcessOperator.java:83)
at app//org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:205)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.processElement(AbstractStreamTaskNetworkInput.java:134)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.emitNext(AbstractStreamTaskNetworkInput.java:105)
at app//org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:66)
...
```
Arriba hay un fragmento de un volcado de subprocesos tomado de la interfaz de usuario de Flink para un solo subproceso. La primera línea contiene información general sobre este subproceso, que incluye:
+ El nombre del hilo *KeyedProcess (1/3) \$10*
+ Prioridad del subproceso *prio=5*
+ Un identificador de subproceso único *Id=1423*
+ Estado del subproceso: *EJECUTABLE*
El nombre de un subproceso generalmente proporciona información sobre el propósito general del subproceso. Los subprocesos del operador se pueden identificar por su nombre, ya que los subprocesos del operador tienen el mismo nombre que el operador, así como una indicación de la subtarea con la que están relacionados, por ejemplo, el subproceso *KeyedProcess (1/3) \$10* proviene del *KeyedProcess*operador y pertenece a la primera subtarea (de 3).
Los subprocesos pueden tener uno de los siguientes estados:
+ NUEVO: el subproceso se ha creado pero aún no se ha procesado
+ EJECUTABLE: el subproceso se está ejecutando en la CPU
+ BLOQUEADO: el subproceso está esperando a que otro subproceso libere su bloqueo
+ ESPERANDO: el subproceso está en espera mediante un método `wait()`, `join()`, o `park()`
+ PROGRAMADO\$1ESPERANDO: el subproceso está en espera mediante el método dormir, esperar, unirse o ubicar, pero con un tiempo de espera máximo.
**nota**
En Flink 1.13, la profundidad máxima de un único stacktrace en el volcado de subprocesos está limitada a 8.
**nota**
Los volcados de subprocesos deberían ser el último recurso para depurar problemas de rendimiento en una aplicación de Flink, ya que pueden resultar difíciles de leer y requieren la toma de múltiples muestras y su análisis manual. Si es posible, es preferible utilizar gráficos tipo llama.
### Volcados de subprocesos en Flink
En Flink, se puede realizar un volcado de subprocesos seleccionando la opción **Administradores de tareas** en la barra de navegación izquierda de la interfaz de usuario de Flink, seleccionando un administrador de tareas específico y, a continuación, navegando a la pestaña **Volcado de subprocesos**. El volcado de subprocesos se puede descargar, copiar a su editor de texto favorito (o analizador de volcado de subprocesos) o analizar directamente dentro de la vista de texto de la interfaz de usuario web de Flink (sin embargo, esta última opción puede resultar un poco torpe).
Para determinar qué administrador de tareas utilizar, se puede utilizar un volcado de subprocesos de la **TaskManagers**pestaña cuando se elige un operador en particular. Esto muestra que el operador se ejecuta diferentes subtareas de un operador y se puede ejecutar diferentes Administradores de tareas.
![\[Uso de volcados de subprocesos\]](http://docs.aws.amazon.com/es_es/managed-flink/latest/java/images/checkpoint4.png)
El volcado estará compuesto por múltiples seguimientos de pila. Sin embargo, cuando se investiga el volcado, lo más importante es lo que está relacionado con un operador. Se pueden encontrar fácilmente, ya que los subprocesos del operador tienen el mismo nombre que el operador, así como una indicación de la subtarea con la que están relacionados. Por ejemplo, el siguiente rastreo de pila proviene del *KeyedProcess*operador y es la primera subtarea.
```
"KeyedProcess (1/3)#0" prio=5 Id=595 RUNNABLE
at app//scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:155)
at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(:19)
at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(:14)
at app//org.apache.flink.streaming.api.operators.KeyedProcessOperator.processElement(KeyedProcessOperator.java:83)
at app//org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:205)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.processElement(AbstractStreamTaskNetworkInput.java:134)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.emitNext(AbstractStreamTaskNetworkInput.java:105)
at app//org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:66)
...
```
Esto puede resultar confuso si hay varios operadores con el mismo nombre, pero podemos ponerle nombre a los operadores para evitarlo. Por ejemplo:
```
....
.process(new ExpensiveFunction).name("Expensive function")
```
## [Gráficos Flame](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/debugging/flame_graphs/)
Los gráficos tipo llama son una útil herramienta de depuración que visualiza los seguimientos de pila del código objetivo, lo que permite identificar las rutas de código más frecuentes. Se crean muestreando los seguimientos de las pilas varias veces. El eje x de un gráfico tipo llama muestra los diferentes perfiles de la pila, mientras que el eje y muestra la profundidad de la pila e incluye el seguimiento de la pila. Un único rectángulo en un gráfico tipo llama representa un marco de pila, y el ancho de un marco muestra la frecuencia con la que aparece en las pilas. Para obtener más información acerca de los gráficos tipo llama y cómo usarlos, consulte [Gráficos Flame](https://www.brendangregg.com/flamegraphs.html).
En Flink, se puede acceder al gráfico de llama de un operador a través de la interfaz de usuario web seleccionando un operador y, a continuación, eligiendo la **FlameGraph**pestaña. Una vez que se hayan recolectado suficientes muestras, se mostrará el gráfico tipo llama. A continuación se muestra FlameGraph el ProcessFunction punto de control que tardó mucho en llegar.
![\[Uso de gráficos tipo llama\]](http://docs.aws.amazon.com/es_es/managed-flink/latest/java/images/checkpoint3.png)
Este es un gráfico de llama muy simple y muestra que todo el tiempo de la CPU se está gastando al alcance `processElement` de la mano del ExpensiveFunction operador. También se obtiene el número de línea para ayudar a determinar en qué parte de la ejecución código se está realizando.
# Agotamiento del tiempo para llegar al punto de control
Si la aplicación no está optimizada o aprovisionada correctamente, los puntos de control pueden fallar. En esta sección se describen los síntomas y los pasos para solucionar esta condición.
## Síntomas
Si los puntos de control de su aplicación fallan, `numberOfFailedCheckpoints` será mayor que cero.
Los puntos de control pueden fallar debido a errores directos, como errores de la aplicación, o debido a errores transitorios, como la falta de recursos de la aplicación. Compruebe los registros y las métricas de su aplicación para detectar los siguientes síntomas:
+ Errores en el código.
+ Errores al acceder a los servicios de dependientes de la aplicación.
+ Errores al serializar los datos. Si el serializador predeterminado no puede serializar los datos de la aplicación, la aplicación fallará. Para obtener información sobre el uso de un serializador personalizado en su aplicación, consulte [Data Types and Serialization](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/dev/datastream/fault-tolerance/serialization/types_serialization/) en la documentación de Apache Flink.
+ Errores de falta de memoria.
+ Aumentos repentinos o aumentos constantes en las siguientes métricas:
+ `heapMemoryUtilization`
+ `oldGenerationGCTime`
+ `oldGenerationGCCount`
+ `lastCheckpointSize`
+ `lastCheckpointDuration`
Para obtener más información sobre la supervisión de los puntos de control, consulte [Monitoring Checkpointing](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/ops/monitoring/checkpoint_monitoring/) en la documentación de Apache Flink.
## Causas y soluciones
Los mensajes de error del registro de aplicaciones muestran la causa de las fallas directas. Los errores transitorios pueden tener las siguientes causas:
+ Su aplicación tiene un aprovisionamiento de KPU insuficiente. Para obtener información sobre cómo aumentar el aprovisionamiento de la aplicación, consulte [Implementación del escalado de aplicaciones](how-scaling.md).
+ El tamaño del estado de su aplicación es demasiado grande. Se puede supervisar el tamaño del estado de la aplicación mediante la métrica `lastCheckpointSize`.
+ Los datos de estado de la aplicación se distribuyen de forma desigual entre las claves. Si su aplicación utiliza el operador `KeyBy`, asegúrese de que los datos entrantes se dividan equitativamente entre las claves. Si la mayoría de los datos se asignan a una sola clave, se crea un cuello de botella que provoca errores.
+ La aplicación está experimentando una resistencia en la memoria o en la recopilación de elementos no utilizados. Supervise los aumentos repentinos o valores que aumentan de forma constante de su aplicación en `heapMemoryUtilization`, `oldGenerationGCTime`, y `oldGenerationGCCount`.
# Fallo en el punto de control de la aplicación Apache Beam
Si tu aplicación Beam está configurada en 0 ms, es posible que los puntos de control no se activen porque las tareas están en estado «FINALIZADO». [shutdownSourcesAfterIdleMs](https://beam.apache.org/documentation/runners/flink/#:~:text=shutdownSourcesAfterIdleMs) En esta sección se describen los síntomas y la resolución de esta condición.
## Síntoma
Vaya a los CloudWatch registros de aplicaciones de su servicio gestionado para Apache Flink y compruebe si se ha registrado el siguiente mensaje de registro. El siguiente mensaje de registro indica que el punto de control no se pudo activar porque algunas tareas estaban terminadas.
```
{
"locationInformation": "org.apache.flink.runtime.checkpoint.CheckpointCoordinator.onTriggerFailure(CheckpointCoordinator.java:888)",
"logger": "org.apache.flink.runtime.checkpoint.CheckpointCoordinator",
"message": "Failed to trigger checkpoint for job your job ID since some tasks of job your job ID has been finished, abort the checkpoint Failure reason: Not all required tasks are currently running.",
"threadName": "Checkpoint Timer",
"applicationARN": your application ARN,
"applicationVersionId": "5",
"messageSchemaVersion": "1",
"messageType": "INFO"
}
```
También se puede encontrar en el panel de control de Flink, donde algunas tareas han pasado al estado “FINALIZADO” y ya no es posible establecer puntos de control.
![\[Tareas en estado “FINALIZADO”\]](http://docs.aws.amazon.com/es_es/managed-flink/latest/java/images/beam_checkpoint_failure.png)
## Causa
shutdownSourcesAfterIdleMs es una variable de configuración de Beam que cierra las fuentes que han estado inactivas durante el tiempo configurado de milisegundos. Una vez que se ha cerrado una fuente, establecer puntos de control ya no es posible. Esto podría provocar una [falla en el punto de control](https://issues.apache.org/jira/browse/FLINK-2491).
Una de las causas por las que las tareas entran en el estado «FINALIZADAS» shutdownSourcesAfter IdleMs es cuando están configuradas en 0 ms, lo que significa que las tareas inactivas se cerrarán inmediatamente.
## Solución
Para evitar que las tareas pasen inmediatamente al estado «FINALIZADAS», establézcalas en shutdownSourcesAfter IdleMs LONG.MAX\$1VALUE. Se puede hacer esto de dos formas:
+ Opción 1: Si la configuración de su haz está establecida en la página de configuración de la aplicación Managed Service for Apache Flink, puede añadir un nuevo par clave-valor para configurar Ms de la siguiente manera: shutdpwnSourcesAfteridle
![\[Establézcalo en shutdownSourcesAfter IdleMs Long.max_value\]](http://docs.aws.amazon.com/es_es/managed-flink/latest/java/images/beam_checkpoint_failure_solution.png)
+ Opción 2: si la configuración de la viga está establecida en el archivo JAR, puede configurarla de la siguiente manera: shutdownSourcesAfter IdleMs
```
FlinkPipelineOptions options = PipelineOptionsFactory.create().as(FlinkPipelineOptions.class); // Initialize Beam Options object
options.setShutdownSourcesAfterIdleMs(Long.MAX_VALUE); // set shutdownSourcesAfterIdleMs to Long.MAX_VALUE
options.setRunner(FlinkRunner.class);
Pipeline p = Pipeline.create(options); // attach specified options to Beam pipeline
```
# Resistencia
Flink utiliza la resistencia para adaptar la velocidad de procesamiento de los operadores individuales.
El operador puede tener dificultades para seguir procesando el volumen de mensajes que recibe por muchas razones. Es posible que la operación requiera más recursos de CPU de los que dispone el operador. Es posible que el operador espere a que se completen I/O las operaciones. Si un operador no puede procesar los eventos con la suficiente rapidez, se genera una resistencia en los operadores de las fases anteriores, lo que repercute en el operador lento. Esto provoca que los operadores de las fases anteriores reduzcan la velocidad, lo que puede propagar aún más la resistencia a la fuente y hacer que la fuente se adapte al rendimiento general de la aplicación, al reducir también la velocidad. Se puede encontrar una descripción más detallada de la resistencia y su funcionamiento en [Cómo maneja Apache Flink™ la resistencia](https://www.ververica.com/blog/how-flink-handles-backpressure).
Saber qué operadores de una aplicación son lentos le proporciona información crucial para comprender la causa raíz de los problemas de rendimiento en la aplicación. La información sobre la resistencia se [expone a través del panel de control de Flink](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/). Para identificar al operador lento, busque al operador con un valor de resistencia alto que esté más cerca de un receptor (el operador B en el siguiente ejemplo). El operador que provoca la lentitud es entonces uno de los operadores de una fase posterior (en el ejemplo, el operador C). B podría procesar los eventos más rápido, pero enfrenta resistencia, ya que no puede reenviar la salida al operador C que realmente está lento.
```
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
```
Una vez que haya identificado al operador lento, intente entender por qué es lento. Se puede haber una infinidad de razones y, a veces, no es obvio cuál es el problema y su solución puede requerir días de depuración y creación de perfiles. Las siguientes son algunas razones obvias y más comunes, algunas de las cuales se explican con más detalle a continuación:
+ El operador realiza operaciones de I/O lentas, por ejemplo, llamadas de red (considere usar AsyncIO en su lugar).
+ Hay un sesgo en los datos y un operador recibe más eventos que otros (compruébelo observando la cantidad de mensajes in/out de subtareas individuales (es decir, instancias del mismo operador) en el panel de control de Flink.
+ Es una operación que consume muchos recursos (si no hay un sesgo en los datos, considere la posibilidad de ampliarla para el trabajo encuadernado o `ParallelismPerKPU` aumentarla para el trabajo CPU/memory encuadernado) I/O
+ Registro exhaustivo por parte del operador (reduzca el registro al mínimo para la aplicación de producción o, en su lugar, considere enviar los resultados de la depuración a un flujo de datos).
## Prueba del rendimiento con el receptor de descarte
El [receptor de descarte](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html) simplemente ignora todos los eventos que recibe mientras sigue ejecutando la aplicación (una aplicación sin ningún receptor no se ejecuta). Esto resulta muy útil para realizar pruebas de rendimiento, crear perfiles y comprobar si la aplicación se está escalando correctamente. También es un control de estado muy pragmático para comprobar si los receptores están causando la resistencia o la aplicación (pero comprobar las métricas de resistencia suele ser más fácil y sencillo).
Al sustituir todos los receptores de una aplicación por un receptor de descarte y crear una fuente simulada que genere datos que se parezcan a los de producción, se puede medir el rendimiento máximo de la aplicación para una configuración de paralelismo determinada. A continuación, también puede aumentar el paralelismo para comprobar que la aplicación se escala correctamente y que no presenta ningún cuello de botella que solo surja a medida que aumenta el rendimiento (por ejemplo, debido al sesgo de datos).
# Sesgo de datos
Una aplicación Flink se ejecuta en un clúster de forma distribuida. Para escalar horizontalmente a varios nodos, Flink utiliza el concepto de flujos con claves, que básicamente significa que los eventos de un flujo se dividen en función de una clave específica, por ejemplo, la identificación del cliente, y Flink puede procesar diferentes particiones en diferentes nodos. Luego, muchos de los operadores de Flink se evalúan en función de estas particiones, por ejemplo, [ventanas con clave](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/), [funciones de procesos](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/process_function/) y [Async I/O](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/).
La elección de una clave de partición a menudo depende de la lógica empresarial. Al mismo tiempo, muchas de las prácticas recomendadas, por ejemplo, para [DynamoDB](https://aws.amazon.com/dynamodb/) y Spark, también se aplican a Flink, entre las que se incluyen:
+ Garantía de una alta cardinalidad de las claves de partición
+ Evasión del sesgo en el volumen de eventos entre las particiones
Para identificar el sesgo en las particiones, compare los registros received/sent de las subtareas (es decir, instancias del mismo operador) en el panel de control de Flink. Además, el monitoreo de Managed Service para Apache Flink se puede configurar para mostrar las métricas correspondientes para `numRecordsIn/Out` y `numRecordsInPerSecond/OutPerSecond` a nivel de subtarea.
# Sesgo de estado
En el caso de los operadores con estado, es decir, los operadores que mantienen el estado para su lógica empresarial, como ventanas, el sesgo de datos siempre conduce a un sesgo de estado. Algunas subtareas reciben más eventos que otras debido al sesgo de datos y, por lo tanto, también mantienen más datos en estado. Sin embargo, incluso en el caso de una aplicación que tenga particiones equilibradas de manera uniforme, puede haber un sesgo en la cantidad de datos que se conservan en el estado. Por ejemplo, en el caso de las ventanas de sesión, algunos usuarios y sesiones, respectivamente, pueden durar mucho más que otros. Si las sesiones más largas forman parte de la misma partición, se puede producir un desequilibrio en el tamaño del estado que mantienen las distintas subtareas del mismo operador.
El sesgo de estado no solo aumenta los recursos de memoria y disco que requieren las subtareas individuales, sino que también puede disminuir el rendimiento general de la aplicación. Cuando una aplicación toma un punto de control o un punto de guardado, el estado del operador se mantiene en Amazon S3, para proteger el estado contra errores de nodos o clústeres. Durante este proceso (especialmente con la semántica de exactamente una vez, que está habilitada de forma predeterminada en Managed Service for Apache Flink), el procesamiento se detiene desde una perspectiva externa hasta que se completa. checkpoint/savepoint Si hay un sesgo de datos, el tiempo necesario para completar la operación puede estar limitado por una sola subtarea que haya acumulado una cantidad de estado particularmente alta. En casos extremos, la ejecución checkpoints/savepoints puede fallar debido a que una sola subtarea no puede mantener su estado.
De forma similar al sesgo de datos, el sesgo de estado puede ralentizar considerablemente una aplicación.
Para identificar el sesgo de estado, puede aprovechar el panel de control de Flink. Busque un punto de control o un punto de guardado reciente y compare en los detalles la cantidad de datos que se han almacenado para cada subtarea.
# Integración con recursos en diferentes regiones
Se puede habilitar usando `StreamingFileSink` para escribir en un bucket de Amazon S3 de una región diferente a la de su aplicación Managed Service para Apache Flink mediante una configuración necesaria para la replicación entre regiones en la configuración de Flink. Para ello, presente un ticket de soporte en el [Centro de AWS Support](https://console.aws.amazon.com/support/home#/).