Realtime Compute for Apache Flink:Configuración y plantillas de alertas

Escenario

Nombre de la métrica o evento

Configuración de la regla

Gravedad

Acciones

Job failure

Evento de estado de ejecución del job

= FAILED (Alerta basada en eventos)

P0

1. Compruebe si la directiva de reinicio está mal configurada. Se recomienda usar la configuración predeterminada.

2. Determine si el error se debe a la directiva de reinicio o a una excepción en JobManager/TaskManager.

3. Restaure el job desde el último savepoint o checkpoint exitoso.

Spike in failovers

Overview / NumOfRestart

≥ 1 durante 1 periodo consecutivo

P0

1. Identifique la causa raíz.

• Analice los registros de failover, JobManager y TaskManager para obtener detalles del error.

• Ignorar: Fallos de máquina poco frecuentes que se recuperan automáticamente.

• Corregir: Errores de código, cuellos de botella de recursos o errores de configuración.

2. Restaure el job desde el último savepoint o checkpoint exitoso.

Consecutive checkpoint failures

NumOfCheckpoints (agregado de 5 minutos)

≤ 0 durante 1 periodo consecutivo

P0

1. Consulte System checkpoints para solucionar la causa raíz de los fallos de checkpoint.

2. Identifique y resuelva el problema.

• Problemas de parámetros (por ejemplo, tiempo de espera): Ajuste las configuraciones relacionadas con los checkpoints.

• Escalado de recursos (por ejemplo, backpressure): Use dynamic scaling para agregar recursos al operador con backpressure.

3. Actualice dinámicamente la configuración o restaure el job desde el último checkpoint exitoso.

High latency (with data ingress)

Overview / CurrentEmitEventTimeLag && NumOfRecordsInFromSourcePerSecond

Latencia máxima ≥ 180,000 ms

Registros de entrada > 0

durante 3 periodos consecutivos

P1

1. Consulte Monitor metrics para identificar la causa de la latencia.

• Datos: ¿Están desordenados los tiempos de evento?

• Tráfico: ¿Hay un aumento repentino en el tráfico ascendente o backpressure desde un sistema descendente?

Paso 2: Realice ajustes según la causa específica.

• Interno: Ajuste las opciones WITH del conector o escale verticalmente el operador que genera el cuello de botella.

• Externo: Optimice las configuraciones del servicio externo, por ejemplo, ajustando las directivas de limitación de tasa o aumentando el número de conexiones.

Upstream data flow interruption

Overview / NumOfRecordsInFromSourcePerSecond &&

SourceIdleTime

Registros de entrada ≤ 0 (según su lógica de negocio)

Tiempo máximo de inactividad ≥ 60,000 ms

durante 5 periodos consecutivos

P1

1. Revise taskmanager.log, los gráficos de flamas y las métricas del servicio ascendente para confirmar si el problema es falta de datos ascendentes, limitación de tasa o una excepción, o bien una pila de hilos bloqueada.

Paso 2: Realice ajustes según la causa específica.

• Problemas del conector: Optimice los parámetros del conector (por ejemplo, tiempo de espera, concurrencia) o agregue más recursos al TaskManager.

• Problemas del servicio ascendente: Notifique al responsable del servicio ascendente para que resuelva el problema.

• Cuellos de botella internos de Flink (por ejemplo, backpressure o congelamiento del sistema): Resuelva la causa raíz del cuello de botella (como un problema descendente) y luego reinicie el job desde el último checkpoint.

No data output

Overview / NumOfRecordsOutToSinkPerSecond

≤ 0 durante 5 periodos consecutivos

P1

1. Verifique si los datos están llegando al operador sink.

• Filtrado por lógica de negocio: Use registros o métricas para confirmar si todos los datos de entrada se filtran porque no cumplen ciertas condiciones.

• Datos tardíos descartados: Revise las configuraciones de watermark y ventanas para confirmar si se descartan datos por llegar tarde.

2. Verifique si el sink puede escribir en el sistema externo.

• Nivel de conexión: ¿Está agotado el pool de conexiones del sink? ¿Es estable la conexión de red?

• Nivel del sistema de destino: Compruebe si la base de datos o el servicio descendente presenta bloqueos de tablas, espacio en disco insuficiente, limitación de escritura u otros errores.

3. Como solución temporal, implemente una escritura dual en un sistema de almacenamiento de copia de seguridad.

CPU performance bottleneck

CPU / TMCPUUsage

≥ 85% durante 10 periodos consecutivos

P2

1. Use un gráfico de flamas o la interfaz de usuario de Flink para identificar el operador con mayor consumo.

• Lógica de negocio: Cálculos complejos, análisis sintáctico de JSON o funciones definidas por el usuario (UDF) ineficientes.

• Sesgo de datos: Una clave caliente sobrecarga una sola tarea con un gran volumen de datos.

• Recursos insuficientes: ¿Coinciden el paralelismo actual y los recursos del TaskManager con el tráfico de datos? ¿Existe backpressure severa?

• GC frecuente: Use registros o métricas de JVM para comprobar si la presión de memoria provoca Full GC frecuentes, lo cual consume una cantidad significativa de CPU.

2. Aumente el paralelismo del operador que genera el cuello de botella o asigne más núcleos de CPU al TaskManager.

Memory performance bottleneck

TMHeapMemoryUsed

≥ 90% durante 10 periodos consecutivos

P2

1. Analice los registros de GC para identificar el problema.

• Fuga de memoria: Use la interfaz de usuario de Flink o los paneles de monitoreo para observar si la memoria heap no regresa a su línea base después del GC y dicha línea base sigue aumentando.

• Capacidad insuficiente: Si el uso de memoria heap es consistentemente alto, pueden desencadenarse Full GC frecuentes y degradarse el rendimiento.

• OOM repentino: Compruebe si el procesamiento de un registro específico o un lote de datos agota la memoria al instante, lo que deriva directamente en un OutOfMemoryError.

2. Aumente el tamaño del heap o el paralelismo para reducir el volumen de datos por slot.