¿Por qué se reinicia la aplicación Amazon Kinesis Data Analytics?

Resolución

Cuando se produce un error en una tarea, la aplicación Apache Flink reinicia la tarea con errores y otras tareas afectadas para que el trabajo vuelva a su estado normal.

A continuación, se describen algunas de las causas y los respectivos pasos para solucionar este problema:

• Los errores de código, como la excepción NullPointer y el tipo DataCast, se generan en el administrador de tareas y se transmiten al administrador de trabajos. A continuación, la aplicación se reinicia a partir del punto de control más reciente. Para detectar reinicios de la aplicación debidos a excepciones no gestionadas en la aplicación, compruebe las métricas de Amazon CloudWatch, como el tiempo de inactividad. Esta métrica muestra un valor distinto de cero durante los períodos de reinicio. Para identificar las causas de esta condición, busque en los registros de la aplicación cualquier cambio de estado de la aplicación de EN EJECUCIÓN a ERROR. Para obtener más información, consulte Analizar errores: errores relacionados con las tareas de la aplicación.

• Cuando se producen excepciones de falta de memoria, el administrador de tareas no puede enviar señales de ritmo adecuado al administrador de trabajos, lo que conduce a un reinicio de la aplicación. En este caso, es posible que aparezcan errores en los registros de la aplicación, como TimeoutException, FlinkException o RemoteTransportException. Compruebe si los recursos de la CPU o de la memoria sobrecargan la aplicación.

  • Asegúrese de que las métricas de CloudWatch fullRestarts y downtime tengan valores distintos de cero.
  • Compruebe las métricas cpuUtilization y heapMemoryUtilization en busca de picos inusuales.
  • Compruebe si hay excepciones no gestionadas en el código de la aplicación.
  • Compruebe si hay errores en el punto de control y en el punto de guardado. Supervise las métricas de CloudWatch numOFFailedCheckpoints, lastCheckpointSize y lastCheckpointDuration para detectar picos y aumentos constantes.
    Para resolver este problema, intente lo siguiente:
  • Si ha habilitado los registros de depuración para la aplicación, el consumo de recursos de la aplicación podría ser alto. Para reducir la cantidad de registros, habilite temporalmente los registros de depuración únicamente al investigar los problemas.
  • Analiza el volcado de subprocesos de TaskManager en el panel de control de Apache Flink. Por ejemplo, puede identificar los procesos que requieren un uso intensivo de la CPU a partir del volcado de subprocesos.
  • Revise los gráficos de llama que se elaboran mediante el muestreo de las trazas de la pila varias veces. Puede utilizar los gráficos de llama para lo siguiente: visualizar el estado general de la aplicación, identificar los métodos que consumen más recursos de la CPU e identificar la serie de llamadas en la pila que condujeron a la ejecución de un método concreto. Compruebe si hay llamadas bloqueadas por medio de los gráficos de llama fuera de la CPU.

• Si la aplicación aprovisiona insuficientemente un origen o un receptor, es posible que la aplicación experimente errores de limitación al leer y escribir en servicios de streaming como Kinesis Data Streams. Esta condición podría eventualmente provocar que la aplicación se interrumpa. Compruebe el rendimiento del origen y del receptor mediante métricas de CloudWatch como WriteProvisionedThroughputExceeded y ReadProvisionedThroughputExceeded. Considere la posibilidad de escalar las secuencias de datos para acomodar el volumen de datos mediante el aumento del número de fragmentos.

• FlinkKinesisProducer utiliza la biblioteca Kinesis Producer Library (KPL) para colocar los datos a partir de una secuencia Flink en una secuencia de Kinesis Data Stream. Los errores, como el tiempo de espera, provocan errores en la KPL que pueden llegar a provocar el reinicio de la aplicación Flink. En estos casos, es posible que aumente el tiempo de almacenamiento en el búfer y el número de reintentos. Puede ajustar las siguientes configuraciones para KPL de manera que el registro no caduque: RecordMaxBufferedTime, RecordTtl y RequestTimeout. Además, supervise las métricas importantes de KPL, como ErrorsByCode, RetriesPerRecord y UserRecordsPending. Cuando estas métricas indican que la aplicación se reinicia, utilice los filtros de CloudWatch Logs Insights para conocer los motivos exactos de los errores que han provocado el reinicio.

• Tenga en cuenta que no todos los errores conducen a un reinicio inmediato de la aplicación. Por ejemplo, los errores en el código de la aplicación pueden provocar un error en el flujo de trabajo del DAG. En este caso, no se crea el grafo acíclico dirigido (DAG) correspondiente a la aplicación. La aplicación se cierra y no se reinicia inmediatamente. Además, la aplicación no se reinicia inmediatamente cuando se produce un error de “acceso denegado”.

Si el problema persiste, póngase en contacto con AWS Support y proporcione la siguiente información:

• ARN de aplicación
• Información sobre el origen y el receptor de la aplicación
• Registros de CloudWatch para la aplicación
• Hora de emisión en UTC
• Volcados de subproceso relevantes del panel de Flink

Información relacionada

La aplicación se reinicia