Supervisión en un servicio gestionado para Apache Flink - Managed Service para Apache Flink

Amazon Managed Service para Apache Flink Amazon se denominaba anteriormente Amazon Kinesis Data Analytics para Apache Flink.

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.

Supervisión en un servicio gestionado para Apache Flink

Al ejecutar aplicaciones de streaming en producción, se propone ejecutar la aplicación de forma continua e indefinida. Es crucial implementar un monitoreo y una alarma adecuados de todos los componentes, no solo de la aplicación Flink. De lo contrario, se corre el riesgo de pasar por alto los problemas emergentes desde el principio y solo darse cuenta de un problema operativo una vez que se esté resolviendo por completo y sea mucho más difícil de mitigar. Entre los aspectos generales que deben supervisarse se incluyen:

  • ¿El origen ingiere datos?

  • ¿Los datos se leen desde el origen (desde la perspectiva del origen)?

  • ¿La aplicación Flink recibe datos?

  • ¿La aplicación Flink puede mantener el ritmo o se está quedando atrás?

  • ¿La aplicación Flink conserva los datos en el receptor (desde la perspectiva de la aplicación)?

  • ¿El receptor recibe datos?

Por lo tanto, deberían considerarse métricas más específicas para la aplicación Flink. Este CloudWatch panel proporciona un buen punto de partida. Para obtener más información sobre las métricas que deben supervisarse para las aplicaciones de producción, consulte Usa CloudWatch alarmas con Amazon Managed Service para Apache Flink. Estas métricas incluyen:

  • records_lag_max y millisbehindLatest: si la aplicación consume datos de Kinesis o Kafka, estas métricas indican si la aplicación se está retrasando y es necesario escalarla para poder soportar la carga actual. Se trata de una buena métrica genérica y fácil de rastrear para todo tipo de aplicaciones. Sin embargo, solo se puede usar para el escalado reactivo, es decir, cuando la aplicación ya se ha retrasado.

  • cpuUtilizationy heapMemoryUtilization: estas métricas proporcionan una buena indicación del uso general de los recursos de la aplicación y se pueden utilizar para un escalado proactivo, a menos que la aplicación esté vinculada a la E/S.

  • tiempo de inactividad: un tiempo de inactividad superior a cero indica que la aplicación ha fallado. Si el valor es mayor que 0, la aplicación no está procesando ningún dato.

  • lastCheckpointSizey lastCheckpointDuration: estas métricas controlan la cantidad de datos que se almacenan en el estado y el tiempo que se tarda en pasar por un punto de control. Si los puntos de control aumentan o tardan mucho, la aplicación dedica tiempo continuamente a los puntos de control y tiene menos ciclos de procesamiento real. En algunos puntos, los puntos de control pueden crecer demasiado o tardar tanto que fallan. Además de monitorear los valores absolutos, los clientes también deberían considerar monitorear la tasa de cambio con RATE(lastCheckpointSize) y RATE(lastCheckpointDuration).

  • numberOfFailedPuntos de control: esta métrica cuenta el número de puntos de control fallidos desde que se inició la aplicación. En función de la aplicación, puede ser tolerable que los puntos de control fallen ocasionalmente. Sin embargo, si los puntos de control fallan con regularidad, es probable que la aplicación no esté en buen estado y necesite más atención. Recomendamos monitorizar RATE(numberOfFailedCheckpoints) para avisar sobre el gradiente y no sobre los valores absolutos.