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.
# 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#/).