Solucionar errores de Dataflow

Si tienes problemas con tu canalización o trabajo de Dataflow, en esta página se enumeran los mensajes de error que pueden aparecer y se ofrecen sugerencias para solucionar cada error.

Los errores en los tipos de registro dataflow.googleapis.com/worker-startup, dataflow.googleapis.com/harness-startup y dataflow.googleapis.com/kubelet indican problemas de configuración en un trabajo. También pueden indicar condiciones que impidan que funcione la ruta de registro normal.

Es posible que tu flujo de trabajo genere excepciones al procesar datos. Algunos de estos errores son temporales, por ejemplo, cuando se produce una dificultad temporal para acceder a un servicio externo. Algunos de estos errores son permanentes, como los que se deben a datos de entrada dañados o no analizables, o a punteros nulos durante el cálculo.

Dataflow procesa los elementos en paquetes arbitrarios y vuelve a intentar completar el paquete cuando se produce un error en algún elemento de ese paquete. Cuando se ejecuta en modo por lotes, los paquetes que incluyen un elemento con errores se vuelven a intentar cuatro veces. El flujo de procesamiento falla por completo cuando un solo paquete falla cuatro veces. Cuando se ejecuta en modo de streaming, se vuelve a intentar indefinidamente un paquete que incluye un elemento fallido, lo que puede provocar que tu canalización se detenga permanentemente.

Las excepciones en el código de usuario, por ejemplo, tus instancias de DoFn, se registran en la interfaz de monitorización de Dataflow. Si ejecutas tu canalización con BlockingDataflowPipelineRunner, también verás mensajes de error impresos en la ventana de la consola o del terminal.

Para evitar errores en el código, añade controladores de excepciones. Por ejemplo, si quieres eliminar elementos que no superen alguna validación de entrada personalizada realizada en un ParDo, usa un bloque try/catch en tu ParDo para gestionar la excepción, registrarla y eliminar el elemento. En el caso de las cargas de trabajo de producción, implementa un patrón de mensajes sin procesar. Para hacer un seguimiento del recuento de errores, usa transformaciones de agregación.

Faltan archivos de registro

Si no ves ningún registro de tus trabajos, quita todos los filtros de exclusión que contengan resource.type="dataflow_step" de todos tus sumideros del enrutador de registros de Cloud Logging.

Ir al enrutador de registros

Para obtener más información sobre cómo quitar las exclusiones de registros, consulta la guía Quitar exclusiones.

Duplicados en el resultado

Cuando ejecutas un trabajo de Dataflow, la salida contiene registros duplicados.

Este problema puede producirse cuando tu tarea de Dataflow usa el modo de transmisión de flujo de procesamiento al menos una vez. Este modo garantiza que los registros se procesen al menos una vez. Sin embargo, en este modo se pueden crear registros duplicados.

Si tu flujo de trabajo no puede tolerar registros duplicados, usa el modo de streaming exactamente una vez. Este modo ayuda a asegurarse de que los registros no se pierdan ni se dupliquen a medida que los datos se mueven por la canalización.

Para verificar qué modo de transmisión está usando tu trabajo, consulta Ver el modo de transmisión de un trabajo.

Para obtener más información sobre los modos de transmisión, consulta Configurar el modo de transmisión de la canalización.

Errores de la canalización

En las siguientes secciones se describen los errores habituales que pueden producirse en las canalizaciones y los pasos para resolverlos o solucionarlos.

Es necesario habilitar algunas APIs de Cloud

Cuando intentas ejecutar una tarea de Dataflow, se produce el siguiente error:

Some Cloud APIs need to be enabled for your project in order for Cloud Dataflow to run this job.

Este problema se produce porque algunas APIs necesarias no están habilitadas en tu proyecto.

Para solucionar este problema y ejecutar un trabajo de Dataflow, habilita las siguientes APIs en tu proyecto:Google Cloud

• API de Compute Engine (Compute Engine)
• API de registro en la nube
• Cloud Storage
• API JSON de Cloud Storage
• API de BigQuery
• Pub/Sub
• API del almacén de datos

Para obtener instrucciones detalladas, consulta la sección Empezar a usar las APIs Google Cloud .

"@*" y "@N" son especificaciones de partición reservadas

Cuando intentas ejecutar un trabajo, aparece el siguiente error en los archivos de registro y el trabajo falla:

Workflow failed. Causes: "@*" and "@N" are reserved sharding specs. Filepattern must not contain any of them.

Este error se produce si el nombre de archivo de la ruta de Cloud Storage de los archivos temporales (tempLocation o temp_location) tiene el símbolo @ seguido de un número o un asterisco (*).

Para solucionar este problema, cambie el nombre del archivo de forma que el signo @ vaya seguido de un carácter admitido.

Solicitud errónea

Cuando ejecutas una tarea de Dataflow, los registros de Cloud Monitoring muestran una serie de advertencias similares a las siguientes:

Unable to update setup work item STEP_ID error: generic::invalid_argument: Http(400) Bad Request
Update range task returned 'invalid argument'. Assuming lost lease for work with id LEASE_ID
with expiration time: TIMESTAMP, now: TIMESTAMP. Full status: generic::invalid_argument: Http(400) Bad Request

Las advertencias de solicitud incorrecta se producen si la información del estado del trabajador está obsoleta o no está sincronizada debido a retrasos en el procesamiento. A menudo, el trabajo de Dataflow se completa correctamente a pesar de las advertencias de solicitudes incorrectas. Si es así, ignore las advertencias.

No se puede leer ni escribir en diferentes ubicaciones

Cuando ejecutas un trabajo de Dataflow, es posible que veas el siguiente error en los archivos de registro:

message:Cannot read and write in different locations: source: SOURCE_REGION, destination: DESTINATION_REGION,reason:invalid

Este error se produce cuando el origen y el destino están en regiones diferentes. También puede ocurrir cuando la ubicación de almacenamiento provisional y el destino están en regiones diferentes. Por ejemplo, si la tarea lee datos de Pub/Sub y, a continuación, escribe en un segmento de temp de Cloud Storage antes de escribir en una tabla de BigQuery, el segmento de temp de Cloud Storage y la tabla de BigQuery deben estar en la misma región.

Las ubicaciones multirregionales se consideran diferentes de las ubicaciones de una sola región, aunque la región única esté incluida en el ámbito de la ubicación multirregional. Por ejemplo, us (multiple regions in the United States) y us-central1 son regiones diferentes.

Para solucionar este problema, las ubicaciones de destino, origen y almacenamiento temporal deben estar en la misma región. Las ubicaciones de los segmentos de Cloud Storage no se pueden cambiar, por lo que es posible que tengas que crear un segmento de Cloud Storage en la región correcta.

Se ha superado el tiempo de espera de conexión.

Cuando ejecutas un trabajo de Dataflow, es posible que veas el siguiente error en los archivos de registro:

org.springframework.web.client.ResourceAccessException: I/O error on GET request for CONNECTION_PATH: Connection timed out (Connection timed out); nested exception is java.net.ConnectException: Connection timed out (Connection timed out)

Este problema se produce cuando los trabajadores de Dataflow no pueden establecer o mantener una conexión con la fuente o el destino de datos.

Para solucionar el problema, sigue estos pasos:

• Comprueba que la fuente de datos esté en funcionamiento.
• Verifica que el destino se esté ejecutando.
• Revisa los parámetros de conexión que se usan en la configuración de la canalización de Dataflow.
• Verifica que los problemas de rendimiento no afecten al origen ni al destino.
• Asegúrate de que las reglas de cortafuegos no estén bloqueando la conexión.

No existe ningún objeto de este tipo

Cuando ejecutes tus tareas de Dataflow, es posible que veas el siguiente error en los archivos de registro:

..., 'server': 'UploadServer', 'status': '404'}>, <content <No such object:...

Estos errores suelen producirse cuando algunas de las tareas de Dataflow en ejecución usan el mismo temp_location para almacenar los archivos de trabajo temporales creados cuando se ejecuta la canalización. Cuando varias tareas simultáneas comparten el mismo temp_location, es posible que estas tareas se solapen con los datos temporales de las demás y que se produzca una condición de carrera. Para evitar este problema, te recomendamos que uses un temp_location único para cada trabajo.

Dataflow no puede determinar el trabajo pendiente

Al ejecutar una canalización de streaming desde Pub/Sub, se produce la siguiente advertencia:

Dataflow is unable to determine the backlog for Pub/Sub subscription

Cuando una canalización de Dataflow extrae datos de Pub/Sub, Dataflow necesita solicitar información a Pub/Sub repetidamente. Esta información incluye la cantidad de mensajes pendientes de la suscripción y la antigüedad del mensaje más antiguo que no se ha confirmado. En ocasiones, Dataflow no puede obtener esta información de Pub/Sub debido a problemas internos del sistema, lo que puede provocar una acumulación transitoria de trabajo pendiente.

Para obtener más información, consulta Streaming con Cloud Pub/Sub.

DEADLINE_EXCEEDED o Server Unresponsive

Cuando ejecutes tus trabajos, es posible que se produzcan excepciones de tiempo de espera de RPC o uno de los siguientes errores:

DEADLINE_EXCEEDED

O:

Server Unresponsive

Estos errores suelen producirse por alguno de los motivos siguientes:

• Puede que la red de nube privada virtual (VPC) que se usa en tu trabajo no tenga una regla de firewall. La regla de cortafuegos debe habilitar todo el tráfico TCP entre las VMs de la red VPC que hayas especificado en las opciones de la canalización. Para obtener más información, consulta Reglas de cortafuegos de Dataflow.

  En algunos casos, los trabajadores no pueden comunicarse entre sí. Cuando ejecutas una tarea de Dataflow que no usa Dataflow Shuffle ni Streaming Engine, los trabajadores deben comunicarse entre sí mediante los puertos TCP 12345 y 12346 en la red de VPC. En este caso, el error incluye el nombre del harness de trabajador y el puerto TCP que está bloqueado. El error se parece a uno de los siguientes ejemplos:

  DEADLINE_EXCEEDED: (g)RPC timed out when SOURCE_WORKER_HARNESS
  talking to DESTINATION_WORKER_HARNESS:12346.
  

  Rpc to WORKER_HARNESS:12345 completed with error UNAVAILABLE: failed to connect to all addresses
  Server unresponsive (ping error: Deadline Exceeded, UNKNOWN: Deadline Exceeded...)
  

  Para solucionar este problema, usa la marca de gcloud compute firewall-rules create reglas para permitir el tráfico de red a los puertos 12345 y 12346. En el siguiente ejemplo se muestra el comando de Google Cloud CLI:

  gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --network NETWORK \
    --action allow \
    --direction IN \
    --target-tags dataflow \
    --source-tags dataflow \
    --priority 0 \
    --rules tcp:12345-12346
  

  Haz los cambios siguientes:

  • FIREWALL_RULE_NAME: el nombre de la regla de cortafuegos
  • NETWORK: el nombre de tu red

• Tu trabajo está limitado por el barajado.

  Para solucionar este problema, realice uno o varios de los siguientes cambios.

  Java

  • Si el trabajo no usa el shuffle basado en servicios, cambia a Dataflow Shuffle basado en servicios definiendo --experiments=shuffle_mode=service. Para obtener más información sobre la disponibilidad, consulta el artículo sobre Shuffle de Dataflow.
  • Añade más trabajadores. Prueba a definir --numWorkers con un valor más alto cuando ejecutes tu canalización.
  • Aumenta el tamaño del disco adjunto de los trabajadores. Prueba a definir --diskSizeGb con un valor más alto al ejecutar tu canalización.
  • Usa un disco persistente con SSD. Prueba a definir --workerDiskType="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" al ejecutar tu flujo de procesamiento.

  Python

  • Si el trabajo no usa el shuffle basado en servicios, cambia a Dataflow Shuffle basado en servicios definiendo --experiments=shuffle_mode=service. Para obtener más información sobre la disponibilidad, consulta el artículo sobre Shuffle de Dataflow.
  • Añade más trabajadores. Prueba a definir --num_workers con un valor más alto cuando ejecutes tu canalización.
  • Aumenta el tamaño del disco adjunto de los trabajadores. Prueba a definir --disk_size_gb con un valor más alto al ejecutar tu canalización.
  • Usa un disco persistente con SSD. Prueba a definir --worker_disk_type="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" al ejecutar tu flujo de procesamiento.

  Go

  • Si el trabajo no usa el shuffle basado en servicios, cambia a Dataflow Shuffle basado en servicios definiendo --experiments=shuffle_mode=service. Para obtener más información sobre la disponibilidad, consulta el artículo sobre Shuffle de Dataflow.
  • Añade más trabajadores. Prueba a definir --num_workers con un valor más alto cuando ejecutes tu canalización.
  • Aumenta el tamaño del disco adjunto de los trabajadores. Prueba a definir --disk_size_gb con un valor más alto al ejecutar tu canalización.
  • Usa un disco persistente con SSD. Prueba a definir --disk_type="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" al ejecutar tu flujo de procesamiento.

Errores de codificación, excepciones de E/S o comportamientos inesperados en el código de usuario

Los SDKs de Apache Beam y los trabajadores de Dataflow dependen de componentes comunes de terceros. Estos componentes importan dependencias adicionales. Las colisiones de versiones pueden provocar un comportamiento inesperado en el servicio. Además, algunas bibliotecas no son compatibles con versiones posteriores. Es posible que tengas que fijar las versiones que se incluyan en el ámbito durante la ejecución. SDK and Worker Dependencies (SDK y dependencias de trabajador) contiene una lista de dependencias y sus versiones necesarias.

Error al ejecutar LookupEffectiveGuestPolicies

Cuando ejecutas un trabajo de Dataflow, es posible que veas el siguiente error en los archivos de registro:

OSConfigAgent Error policies.go:49: Error running LookupEffectiveGuestPolicies:
error calling LookupEffectiveGuestPolicies: code: "Unauthenticated",
message: "Request is missing required authentication credential.
Expected OAuth 2 access token, login cookie or other valid authentication credential.

Este error se produce si la gestión de la configuración del SO está habilitada en todo el proyecto.

Para solucionar este problema, inhabilita las políticas de VM Manager que se apliquen a todo el proyecto. Si no puedes inhabilitar las políticas de VM Manager en todo el proyecto, puedes ignorar este error y filtrarlo de las herramientas de monitorización de registros.

El entorno de tiempo de ejecución de Java ha detectado un error fatal

Se produce el siguiente error durante el inicio del trabajador:

A fatal error has been detected by the Java Runtime Environment

Este error se produce si la canalización usa la interfaz nativa de Java (JNI) para ejecutar código que no es de Java y ese código o las vinculaciones de JNI contienen un error.

googclient_deliveryattempt attribute key error

Tu tarea de Dataflow falla y se produce uno de los siguientes errores:

The request contains an attribute key that is not valid (key=googclient_deliveryattempt). Attribute keys must be non-empty and must not begin with 'goog' (case-insensitive).

O:

Invalid extensions name: googclient_deliveryattempt

Este error se produce cuando su trabajo de Dataflow tiene las siguientes características:

• La tarea de Dataflow usa Streaming Engine.
• El flujo de procesamiento tiene un sumidero de Pub/Sub.
• La canalización usa una suscripción de extracción.
• La canalización usa una de las APIs de servicio de Pub/Sub para publicar mensajes en lugar de usar el receptor de E/S de Pub/Sub integrado.
• Pub/Sub usa la biblioteca de cliente de Java o C#.
• La suscripción de Pub/Sub tiene un tema de mensajes fallidos.

Este error se produce porque, cuando se usa la biblioteca de cliente de Java o C# de Pub/Sub y se habilita un tema de mensajes fallidos para una suscripción, los intentos de entrega se encuentran en el atributo de mensaje googclient_deliveryattempt en lugar de en el campo delivery_attempt. Para obtener más información, consulta el artículo Hacer un seguimiento de los intentos de entrega de la página "Gestionar errores de mensajes".

Para solucionar este problema, haz uno o varios de los siguientes cambios.

• Inhabilita Streaming Engine.
• Usa el conector Apache Beam PubSubIO integrado en lugar de la API de servicio Pub/Sub.
• Usa otro tipo de suscripción de Pub/Sub.
• Elimina el tema de mensajes fallidos.
• No uses la biblioteca de cliente de Java o C# con tu suscripción de extracción de Pub/Sub. Para ver otras opciones, consulta los ejemplos de código de la biblioteca de cliente.
• En el código de su canalización, cuando las claves de atributo empiecen por goog, borre los atributos de mensaje antes de publicar los mensajes.

Se ha detectado una tecla de acceso rápido ...

Se produce el siguiente error:

A hot key HOT_KEY_NAME was detected in...

Estos errores se producen si tus datos contienen una tecla de acceso rápido. Una tecla activa es una tecla con suficientes elementos como para afectar negativamente al rendimiento de la canalización. Estas claves limitan la capacidad de Dataflow para procesar elementos en paralelo, lo que aumenta el tiempo de ejecución.

Para imprimir la clave legible por humanos en los registros cuando se detecte una combinación de teclas en la pipeline, usa la opción de pipeline de combinación de teclas.

Para solucionar este problema, compruebe que sus datos estén distribuidos de forma uniforme. Si una clave tiene un número de valores desproporcionado, puedes hacer lo siguiente:

• Vuelve a cifrar tus datos. Aplica una transformación ParDo para generar nuevos pares clave-valor.
• En el caso de las tareas de Java, usa la transformación Combine.PerKey.withHotKeyFanout.
• En el caso de las tareas de Python, usa la transformación CombinePerKey.with_hot_key_fanout.
• Habilita Dataflow Shuffle.

Para ver las teclas de acceso rápido en la interfaz de monitorización de Dataflow, consulta el artículo Solucionar problemas de tareas por lotes lentas.

Especificación de tabla no válida en Data Catalog

Cuando usas Dataflow SQL para crear tareas de Dataflow SQL, es posible que la tarea falle y se muestre el siguiente error en los archivos de registro:

Invalid table specification in Data Catalog: Could not resolve table in Data Catalog

Este error se produce si la cuenta de servicio de Dataflow no tiene acceso a la API Data Catalog.

Para resolver este problema, habilita la API Data Catalog en el Google Cloud proyecto que estés usando para escribir y ejecutar consultas.

También puedes asignar el rol roles/datacatalog.viewer a la cuenta de servicio de Dataflow.

El gráfico de la tarea es demasiado grande

Es posible que tu trabajo falle y se muestre el siguiente error:

The job graph is too large. Please try again with a smaller job graph,
or split your job into two or more smaller jobs.

Este error se produce si el tamaño del gráfico de tu trabajo supera los 10 MB. Determinadas condiciones de tu canalización pueden provocar que el gráfico de trabajo supere el límite. Entre las condiciones habituales se incluyen las siguientes:

• Una transformación Create que incluya una gran cantidad de datos en memoria.
• Una instancia DoFn grande que se serializa para enviarla a trabajadores remotos.
• Un DoFn como instancia de clase interna anónima que (posiblemente sin querer) extrae una gran cantidad de datos para serializarse.
• Se está usando un grafo acíclico dirigido (DAG) como parte de un bucle programático que está enumerando una lista grande.

Para evitar estas condiciones, puedes reestructurar tu canalización.

Key Commit Too Large

Al ejecutar un trabajo de streaming, aparece el siguiente error en los archivos de registro del trabajador:

KeyCommitTooLargeException

Este error se produce en situaciones de streaming si se agrupa una gran cantidad de datos sin usar una transformación Combine o si se genera una gran cantidad de datos a partir de un solo elemento de entrada.

Para reducir la probabilidad de que se produzca este error, sigue estas estrategias:

• Asegúrate de que el procesamiento de un solo elemento no dé lugar a salidas ni a modificaciones de estado que superen el límite.
• Si se han agrupado varios elementos por una clave, considere la posibilidad de aumentar el espacio de la clave para reducir el número de elementos agrupados por clave.
• Si los elementos de una clave se emiten con una frecuencia alta durante un breve periodo, puede que se generen muchos GB de eventos para esa clave en las ventanas. Reescribe la canalización para detectar claves como esta y solo emitir una salida que indique que la clave estaba presente con frecuencia en esa ventana.
• Usa transformaciones de espacio sublineal Combine para operaciones conmutativas y asociativas. No uses un combinador si no reduce el espacio. Por ejemplo, un combinador de cadenas que solo añade cadenas es peor que no usar ningún combinador.

Rechazando mensaje de más de 7168 K

Cuando ejecutas una tarea de Dataflow creada a partir de una plantilla, es posible que la tarea falle y se muestre el siguiente error:

Error: CommitWork failed: status: APPLICATION_ERROR(3): Pubsub publish requests are limited to 10MB, rejecting message over 7168K (size MESSAGE_SIZE) to avoid exceeding limit with byte64 request encoding.

Este error se produce cuando los mensajes escritos en una cola de mensajes fallidos superan el límite de tamaño de 7168 K. Como solución alternativa, habilita Streaming Engine, que tiene un límite de tamaño superior. Para habilitar Streaming Engine, usa la siguiente opción de flujo de procesamiento.

Request Entity Too Large

Cuando envías el trabajo, aparece uno de los siguientes errores en la consola o en la ventana de terminal:

413 Request Entity Too Large
The size of serialized JSON representation of the pipeline exceeds the allowable limit
Failed to create a workflow job: Invalid JSON payload received
Failed to create a workflow job: Request payload exceeds the allowable limit

Si se produce un error en la carga útil de JSON al enviar un trabajo, significa que la representación JSON de tu canalización supera el tamaño máximo de solicitud de 20 MB.

El tamaño de tu trabajo está vinculado a la representación JSON de la canalización. Una canalización más grande implica una solicitud más grande. Dataflow tiene una limitación que restringe las solicitudes a 20 MB.

Para estimar el tamaño de la solicitud JSON de tu canalización, ejecútala con la siguiente opción:

Este comando escribe una representación JSON de tu trabajo en un archivo. El tamaño del archivo serializado es una buena estimación del tamaño de la solicitud. El tamaño real es ligeramente superior debido a la información adicional incluida en la solicitud.

Determinadas condiciones de tu canal pueden provocar que la representación JSON supere el límite. Entre las condiciones habituales se incluyen las siguientes:

• Una transformación Create que incluya una gran cantidad de datos en memoria.
• Una instancia DoFn grande que se serializa para enviarla a trabajadores remotos.
• Un DoFn como instancia de clase interna anónima que (posiblemente sin querer) extrae una gran cantidad de datos para serializarse.

Para evitar estas condiciones, puedes reestructurar tu canalización.

Las opciones de la canalización del SDK o la lista de archivos de almacenamiento supera el límite de tamaño

Al ejecutar una canalización, se produce uno de los siguientes errores:

SDK pipeline options or staging file list exceeds size limit.
Please keep their length under 256K Bytes each and 512K Bytes in total.

O:

Value for field 'resource.properties.metadata' is too large: maximum size

Estos errores se producen si no se puede iniciar la canalización porque se han superado los límites de los metadatos de Compute Engine. Estos límites no se pueden cambiar. Dataflow usa metadatos de Compute Engine para las opciones de las canalizaciones. El límite se describe en las limitaciones de los metadatos personalizados de Compute Engine.

En los siguientes casos, la representación JSON puede superar el límite:

• Hay demasiados archivos JAR para organizar.
• El campo de solicitud sdkPipelineOptions es demasiado grande.

Para estimar el tamaño de la solicitud JSON de tu canalización, ejecútala con la siguiente opción:

El tamaño del archivo de salida de este comando debe ser inferior a 256 KB. Los 512 KB del mensaje de error hacen referencia al tamaño total del archivo de salida y a las opciones de metadatos personalizados de la instancia de VM de Compute Engine.

Puedes obtener una estimación aproximada de la opción de metadatos personalizados para instancias de VM ejecutando tareas de Dataflow en el proyecto. Elige cualquier trabajo de Dataflow en ejecución. Selecciona una instancia de VM y, a continuación, ve a la página de detalles de la instancia de VM de Compute Engine para comprobar si está la sección de metadatos personalizados. La longitud total de los metadatos personalizados y del archivo debe ser inferior a 512 KB. No es posible hacer una estimación precisa del trabajo fallido, ya que las VMs no se activan para los trabajos fallidos.

Si tu lista JAR alcanza el límite de 256 KB, revísala y reduce los archivos JAR innecesarios. Si sigue siendo demasiado grande, prueba a ejecutar el trabajo de Dataflow con un uber JAR. Para ver un ejemplo de cómo crear y usar un uber JAR, consulta Compilar e implementar un uber JAR.

Si el campo de solicitud sdkPipelineOptions es demasiado grande, incluya la siguiente opción cuando ejecute su canalización. La opción de canalización es la misma para Java, Python y Go.

--experiments=no_display_data_on_gce_metadata

La clave de barajado es demasiado grande

Aparece el siguiente error en los archivos de registro del trabajador:

Shuffle key too large

Este error se produce si la clave serializada emitida a un (Co-)GroupByKey concreto es demasiado grande después de aplicar el codificador correspondiente. Dataflow tiene un límite para las claves de orden aleatorio serializadas.

Para resolver este problema, reduce el tamaño de las claves o usa codificadores que ocupen menos espacio.

Para obtener más información, consulta los límites de producción de Dataflow.

El número total de objetos BoundedSource ... es superior al límite permitido

Puede que se produzca uno de los siguientes errores al ejecutar trabajos con Java:

Total number of BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit

O:

Total size of the BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit

NameError

Cuando ejecutas tu flujo de procesamiento con el servicio Dataflow, se produce el siguiente error:

NameError

Este error no se produce cuando ejecutas el código localmente, por ejemplo, cuando lo ejecutas con DirectRunner.

Este error se produce si tus DoFn usan valores del espacio de nombres global que no están disponibles en el trabajador de Dataflow.

De forma predeterminada, las importaciones, funciones y variables globales definidas en la sesión principal no se guardan durante la serialización de un trabajo de Dataflow.

Para solucionar este problema, utilice uno de los siguientes métodos. Si tus DoFns están definidos en el archivo principal y hacen referencia a importaciones y funciones en el espacio de nombres global, asigna el valor True a la opción de canalización --save_main_session. Este cambio serializa el estado del espacio de nombres global y lo carga en el trabajador de Dataflow.

Si tienes objetos en tu espacio de nombres global que no se pueden serializar, se produce un error de serialización. Si el error se refiere a un módulo que debería estar disponible en la distribución de Python, importa el módulo localmente, donde se utilice.

Por ejemplo, en lugar de lo siguiente:

import re
…
def myfunc():
  # use re module

Uso:

def myfunc():
  import re
  # use re module

Si tus DoFn abarcan varios archivos, utiliza otro método para empaquetar tu flujo de trabajo y gestionar las dependencias.

El objeto está sujeto a la política de retención del segmento

Cuando tienes una tarea de Dataflow que escribe en un segmento de Cloud Storage, la tarea falla y se muestra el siguiente error:

Object 'OBJECT_NAME' is subject to bucket's retention policy or object retention and cannot be deleted or overwritten

También puede que veas el siguiente error:

Unable to rename "gs://BUCKET"

El primer error se produce cuando la conservación de objetos está habilitada en el segmento de Cloud Storage en el que escribe la tarea de Dataflow. Para obtener más información, consulta Habilitar y usar configuraciones de conservación de objetos.

Para solucionar este problema, utiliza una de las siguientes soluciones:

• Escribir en un segmento de Cloud Storage que no tenga una política de retención en la carpeta temp.

• Elimina la política de conservación del segmento en el que escribe el trabajo. Para obtener más información, consulta Definir la configuración de conservación de un objeto.

El segundo error puede indicar que la conservación de objetos está habilitada en el segmento de Cloud Storage o que la cuenta de servicio de trabajador de Dataflow no tiene permiso para escribir en el segmento de Cloud Storage.

Si aparece el segundo error y la conservación de objetos está habilitada en el segmento de Cloud Storage, prueba las soluciones alternativas descritas anteriormente. Si la conservación de objetos no está habilitada en el segmento de Cloud Storage, comprueba si la cuenta de servicio de trabajador de Dataflow tiene permiso de escritura en el segmento de Cloud Storage. Para obtener más información, consulta Acceder a los segmentos de Cloud Storage.

El procesamiento se ha bloqueado o la operación está en curso

Si Dataflow dedica más tiempo a ejecutar un DoFn que el tiempo especificado en TIME_INTERVAL sin devolver nada, se muestra el siguiente mensaje.

Este comportamiento puede deberse a dos motivos:

• Tu código DoFn es lento o está esperando a que se complete alguna operación externa lenta.
• Es posible que tu código DoFn esté bloqueado o que tarde demasiado en completar el proceso.

Para determinar cuál es el caso, despliega la entrada de registro de Cloud Monitoring para ver un seguimiento de pila. Busca mensajes que indiquen que el código DoFn está bloqueado o que tiene algún problema. Si no hay mensajes, el problema puede ser la velocidad de ejecución del código DoFn. Puedes usar Cloud Profiler u otra herramienta para investigar el rendimiento de tu código.

Si tu canal se ha creado en la máquina virtual de Java (con Java o Scala), puedes investigar la causa del bloqueo del código. Haz un volcado de pila completo de toda la JVM (no solo del hilo bloqueado) siguiendo estos pasos:

1. Anota el nombre del trabajador de la entrada de registro.
2. En la sección Compute Engine de la Google Cloud consola, busca la instancia de Compute Engine con el nombre de trabajador que has anotado.
3. Usa SSH para conectarte a la instancia con ese nombre.

4. Ejecuta el siguiente comando:

   curl http://localhost:8081/threadz
   

Operación en curso en el paquete

Cuando ejecutas una lectura de una canalización desde JdbcIO, las lecturas particionadas de JdbcIO son lentas y aparece el siguiente mensaje en los archivos de registro de los trabajadores:

Operation ongoing in bundle process_bundle-[0-9-]* for PTransform{id=Read from JDBC with Partitions\/JdbcIO.Read\/JdbcIO.ReadAll\/ParDo\(Read\)\/ParMultiDo\(Read\).*, state=process} for at least (0[1-9]h[0-5][0-9]m[0-5][0-9]s) without outputting or completing:

Para solucionar este problema, haz uno o varios de los siguientes cambios en tu flujo de procesamiento:

• Usa particiones para aumentar el paralelismo de los trabajos. Lee con más particiones de menor tamaño para mejorar el escalado.

• Comprueba si la columna de partición es una columna de índice o una columna de partición real en la fuente. Activa la indexación y la creación de particiones en esta columna de la base de datos de origen para obtener el mejor rendimiento.

• Usa los parámetros lowerBound y upperBound para saltarte la búsqueda de los límites.

Errores de cuota de Pub/Sub

Al ejecutar una canalización de streaming desde Pub/Sub, se producen los siguientes errores:

429 (rateLimitExceeded)

O:

Request was throttled due to user QPS limit being reached

Estos errores se producen si tu proyecto no tiene suficiente cuota de Pub/Sub.

Para saber si tu proyecto no tiene suficiente cuota, sigue estos pasos para comprobar si hay errores del cliente:

1. Ve a la Google Cloud consola.
2. En el menú de la izquierda, selecciona APIs & services (APIs y servicios).
3. En el cuadro de búsqueda, busca Cloud Pub/Sub.
4. Haz clic en la pestaña Uso.
5. Consulta los códigos de respuesta y busca los códigos de error del cliente (4xx).

La política de la organización prohíbe esta solicitud

Al ejecutar una canalización, se produce el siguiente error:

Error trying to get gs://BUCKET_NAME/FOLDER/FILE:
{"code":403,"errors":[{"domain":"global","message":"Request is prohibited by organization's policy","reason":"forbidden"}],
"message":"Request is prohibited by organization's policy"}

Este error se produce si el segmento de Cloud Storage está fuera de tu perímetro de servicio.

Para solucionar este problema, crea una regla de salida que permita acceder al bucket desde fuera del perímetro de servicio.

No se puede acceder al paquete de lanzamiento...

Es posible que los trabajos que antes se completaban correctamente ahora fallen y muestren el siguiente error:

Staged package...is inaccessible

Para solucionar este problema, sigue estos pasos:

• Verifica que el segmento de Cloud Storage que se usa para la fase de staging no tenga ajustes de TTL que provoquen que se eliminen los paquetes en fase de staging.

• Verifica que la cuenta de servicio de trabajador de tu proyecto de Dataflow tenga permiso para acceder al segmento de Cloud Storage que se usa para la fase de staging. Las lagunas en los permisos pueden deberse a cualquiera de los siguientes motivos:

  • El segmento de Cloud Storage que se usa para la fase de staging está en otro proyecto.
  • El segmento de Cloud Storage utilizado para la puesta en escena se ha migrado del acceso detallado al acceso uniforme a nivel de segmento. Debido a la incoherencia entre las políticas de gestión de identidades y accesos y las LCA, al migrar el segmento de almacenamiento provisional al acceso uniforme a nivel de segmento, no se permiten las LCA para los recursos de Cloud Storage. Las listas de control de acceso incluyen los permisos que tiene la cuenta de servicio de trabajador de tu proyecto de Dataflow sobre el segmento de almacenamiento provisional.

Para obtener más información, consulta Acceder a segmentos de Cloud Storage en proyectos de Google Cloud Platform.

Un elemento de trabajo ha fallado 4 veces

Se produce el siguiente error cuando falla un trabajo por lotes:

The job failed because a work item has failed 4 times.

Este error se produce si una sola operación de un trabajo por lotes provoca que el código de trabajador falle cuatro veces. Dataflow falla en la tarea y se muestra este mensaje.

Cuando se ejecuta en modo de streaming, se vuelve a intentar indefinidamente un paquete que incluye un elemento fallido, lo que puede provocar que tu canalización se detenga permanentemente.

No puedes configurar este umbral de fallos. Para obtener más información, consulta el artículo sobre la gestión de errores y excepciones de la canalización.

Para solucionar este problema, consulta los registros de Cloud Monitoring de la tarea para ver los cuatro errores individuales. En los registros de los trabajadores, busca entradas de registro de nivel de error o nivel fatal que muestren excepciones o errores. La excepción o el error deben aparecer al menos cuatro veces. Si los registros solo contienen errores de tiempo de espera genéricos relacionados con el acceso a recursos externos, como MongoDB, comprueba que la cuenta de servicio de trabajador tenga permiso para acceder a la subred del recurso.

Tiempo de espera en el archivo de resultados de sondeo

Para obtener información completa sobre cómo solucionar el error "Tiempo de espera agotado en el archivo de resultados de sondeo", consulta el artículo Solucionar problemas de plantillas de Flex.

Write Correct File/Write/WriteImpl/PreFinalize failed

Al ejecutar un trabajo, este falla de forma intermitente y se produce el siguiente error:

Workflow failed. Causes: S27:Write Correct File/Write/WriteImpl/PreFinalize failed., Internal Issue (ID): ID:ID, Unable to expand file pattern gs://BUCKET_NAME/temp/FILE

Este error se produce cuando se usa la misma subcarpeta como ubicación de almacenamiento temporal para varios trabajos que se ejecutan simultáneamente.

Para solucionar este problema, no utilice la misma subcarpeta como ubicación de almacenamiento temporal para varias canalizaciones. En cada canalización, proporciona una subcarpeta única que se usará como ubicación de almacenamiento temporal.

El elemento supera el tamaño máximo del mensaje protobuf

Cuando ejecutas trabajos de Dataflow y tu canalización tiene elementos grandes, es posible que veas errores similares a los siguientes ejemplos:

Exception serializing message!
ValueError: Message org.apache.beam.model.fn_execution.v1.Elements exceeds maximum protobuf size of 2GB

O:

Buffer size ... exceeds GRPC limit 2147483548. This is likely due to a single element that is too large.

También puede que veas una advertencia similar a la del siguiente ejemplo:

Data output stream buffer size ... exceeds 536870912 bytes. This is likely due to a large element in a PCollection.

Estos errores se producen cuando tu canalización contiene elementos grandes.

Para resolver este problema, si usas el SDK de Python, actualiza a Apache Beam versión 2.57.0 o posterior. Las versiones 2.57.0 y posteriores del SDK de Python mejoran el procesamiento de elementos de gran tamaño y añaden registros relevantes.

Si los errores persisten después de actualizar o si no usas el SDK de Python, identifica el paso del trabajo en el que se produce el error e intenta reducir el tamaño de los elementos de ese paso.

Cuando los objetos PCollection de tu canalización tienen elementos grandes, los requisitos de RAM de la canalización aumentan. Los elementos grandes también pueden provocar errores de tiempo de ejecución, sobre todo cuando cruzan los límites de las fases combinadas.

Los elementos grandes pueden producirse cuando una canalización materializa inadvertidamente un iterable grande. Por ejemplo, una canalización que pasa la salida de una operación GroupByKey a una operación Reshuffle innecesaria materializa las listas como elementos únicos. Estas listas pueden contener un gran número de valores por cada clave.

Si el error se produce en un paso que usa una entrada lateral, ten en cuenta que el uso de entradas laterales puede introducir una barrera de fusión. Comprueba si la transformación que produce un elemento grande y la transformación que lo consume pertenecen a la misma fase.

Cuando construyas tu canalización, sigue estas prácticas recomendadas:

• En PCollections, usa varios elementos pequeños en lugar de un solo elemento grande.
• Almacena blobs grandes en sistemas de almacenamiento externos. Puede usar PCollections para transferir sus metadatos o usar un codificador personalizado que reduzca el tamaño del elemento.
• Si debes transferir una PCollection que pueda superar los 2 GB como entrada secundaria, usa vistas iterables, como AsIterable y AsMultiMap.

El tamaño máximo de un elemento en un trabajo de Dataflow es de 2 GB. Para obtener más información, consulta Cuotas y límites.

Dataflow no puede procesar las transformaciones gestionadas...

Es posible que los flujos de procesamiento que usan E/S gestionada fallen y muestren este error si Dataflow no puede actualizar automáticamente las transformaciones de E/S a la versión compatible más reciente. El URN y los nombres de los pasos proporcionados en el error deben especificar qué transformaciones exactas no ha podido actualizar Dataflow.

Puedes encontrar más detalles sobre este error en Explorador de registros, en los nombres de registro de Dataflow managed-transforms-worker y managed-transforms-worker-startup.

Si Explorador de registros no proporciona información suficiente para solucionar el error, póngase en contacto con Cloud Customer Care.

Archivar errores de tareas

En las siguientes secciones se incluyen errores habituales que pueden producirse al intentar archivar un trabajo de Dataflow mediante la API.

No se ha proporcionado ningún valor

Cuando intentas archivar un trabajo de Dataflow mediante la API, puede producirse el siguiente error:

The field mask specifies an update for the field job_metadata.user_display_properties.archived in job JOB_ID, but no value is provided. To update a field, please provide a field for the respective value.

Este error se produce por uno de los siguientes motivos:

• La ruta especificada en el campo updateMask no tiene el formato correcto. Este problema puede deberse a errores tipográficos.

• El JobMetadata no se ha especificado correctamente. En el campo JobMetadata, para userDisplayProperties, usa el par clave-valor "archived":"true".

Para resolver este error, compruebe que el comando que envía a la API tiene el formato necesario. Para obtener más información, consulta Archivar un trabajo.

La API no reconoce el valor

Cuando intentas archivar un trabajo de Dataflow mediante la API, puede producirse el siguiente error:

The API does not recognize the value VALUE for the field job_metadata.user_display_properties.archived for job JOB_ID. REASON: Archived display property can only be set to 'true' or 'false'

Este error se produce cuando el valor proporcionado en el par clave-valor de los trabajos archivados no es un valor admitido. Los valores admitidos para el par clave-valor de los trabajos de archivo son "archived":"true" y "archived":"false".

Para resolver este error, compruebe que el comando que envía a la API tiene el formato necesario. Para obtener más información, consulta Archivar un trabajo.

No se pueden actualizar el estado y la máscara al mismo tiempo

Cuando intentas archivar un trabajo de Dataflow mediante la API, puede producirse el siguiente error:

Cannot update both state and mask.

Este error se produce cuando intentas actualizar tanto el estado del trabajo como el estado del archivo en la misma llamada a la API. No puedes actualizar tanto el estado del trabajo como el parámetro de consulta updateMask en la misma llamada a la API.

Para solucionar este error, actualiza el estado del trabajo en una llamada a la API independiente. Haz cambios en el estado del trabajo antes de actualizar el estado del archivo del trabajo.

No se ha podido modificar el flujo de trabajo

Cuando intentas archivar un trabajo de Dataflow mediante la API, puede producirse el siguiente error:

Workflow modification failed.

Este error suele producirse cuando intentas archivar un trabajo que está en curso.

Para resolver este error, espera a que se complete el trabajo antes de archivarlo. Los trabajos completados tienen uno de los siguientes estados:

• JOB_STATE_CANCELLED
• JOB_STATE_DRAINED
• JOB_STATE_DONE
• JOB_STATE_FAILED
• JOB_STATE_UPDATED

Para obtener más información, consulta Detectar la finalización de un trabajo de Dataflow.

Errores de imagen de contenedor

En las secciones siguientes se describen los errores habituales que pueden producirse al usar contenedores personalizados y los pasos para resolverlos o solucionarlos. Los errores suelen ir precedidos del siguiente mensaje:

Unable to pull container image due to error: DETAILED_ERROR_MESSAGE

Permiso "containeranalysis.occurrences.list" denegado

En los archivos de registro aparece el siguiente error:

Error getting old patchz discovery occurrences: generic::permission_denied: permission "containeranalysis.occurrences.list" denied for project "PROJECT_ID", entity ID "" [region="REGION" projectNum=PROJECT_NUMBER projectID="PROJECT_ID"]

La API Container Analysis es necesaria para analizar las vulnerabilidades.

Para obtener más información, consulta la descripción general del análisis de SO y la configuración del control de acceso en la documentación de Artifact Analysis.

Error al sincronizar el pod ... no se ha podido "StartContainer"

Se produce el siguiente error durante el inicio del trabajador:

Error syncing pod POD_ID, skipping: [failed to "StartContainer" for CONTAINER_NAME with CrashLoopBackOff: "back-off 5m0s restarting failed container=CONTAINER_NAME pod=POD_NAME].

Un pod es un grupo de contenedores Docker colocados que se ejecutan en un trabajador de Dataflow. Este error se produce cuando no se puede iniciar uno de los contenedores Docker del pod. Si el error no se puede recuperar, el trabajador de Dataflow no podrá iniciarse y las tareas por lotes de Dataflow acabarán fallando con errores como los siguientes:

The Dataflow job appears to be stuck because no worker activity has been seen in the last 1h.

Este error suele producirse cuando uno de los contenedores falla continuamente durante el inicio.

Para identificar la causa principal, busca los registros capturados inmediatamente antes del fallo. Para analizar los registros, usa el Explorador de registros. En el Explorador de registros, limita los archivos de registro a las entradas de registro emitidas por el trabajador con errores de inicio del contenedor. Para limitar las entradas de registro, sigue estos pasos:

1. En el Explorador de registros, busca la entrada de registro Error syncing pod.
2. Para ver las etiquetas asociadas a la entrada de registro, despliégala.
3. Haga clic en la etiqueta asociada al resource_name y, a continuación, en Mostrar entradas coincidentes.

En el explorador de registros, los registros de Dataflow se organizan en varios flujos de registros. El mensaje Error syncing pod se emite en el registro llamado kubelet. Sin embargo, los registros del contenedor que falla podrían estar en otro flujo de registro. Cada contenedor tiene un nombre. Usa la siguiente tabla para determinar qué flujo de registro puede contener registros relevantes para el contenedor que falla.

Cuando consultes el Explorador de registros, asegúrate de que la consulta incluya los nombres de los registros pertinentes en la interfaz del creador de consultas o de que no tenga restricciones en el nombre del registro.

Después de seleccionar los registros pertinentes, el resultado de la consulta puede ser similar al siguiente ejemplo:

resource.type="dataflow_step"
resource.labels.job_id="2022-06-29_08_02_54-JOB_ID"
labels."compute.googleapis.com/resource_name"="testpipeline-jenkins-0629-DATE-cyhg-harness-8crw"
logName=("projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fdocker"
OR
"projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fworker-startup"
OR
"projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fworker")

Como los registros que informan del síntoma del fallo del contenedor a veces se registran como INFO, incluya los registros INFO en su análisis.

Las causas habituales de los errores de contenedor son las siguientes:

1. Tu canalización de Python tiene dependencias adicionales que se instalan en el tiempo de ejecución y la instalación no se realiza correctamente. Es posible que veas errores como pip install failed with error. Este problema puede deberse a requisitos contradictorios o a una configuración de red restringida que impida que un trabajador de Dataflow extraiga una dependencia externa de un repositorio público a través de Internet.

2. Un trabajador falla en mitad de la ejecución de la canalización debido a un error de falta de memoria. Es posible que veas un error como uno de los siguientes:

   • java.lang.OutOfMemoryError: Java heap space
   • Shutting down JVM after 8 consecutive periods of measured GC thrashing. Memory is used/total/max = 24453/42043/42043 MB, GC last/max = 58.97/99.89 %, #pushbacks=82, gc thrashing=true. Heap dump not written.

   Para depurar un problema de falta de memoria, consulta Solucionar problemas de falta de memoria en Dataflow.

3. Dataflow no puede extraer la imagen del contenedor. Para obtener más información, consulta Image pull request failed with error (No se ha podido realizar la solicitud de extracción de la imagen. Error:)

4. El contenedor utilizado no es compatible con la arquitectura de CPU de la VM de trabajador. En los registros de inicio del arnés, puede que veas un error como el siguiente: exec /opt/apache/beam/boot: exec format error. Para comprobar la arquitectura de la imagen del contenedor, ejecuta docker image inspect $IMAGE:$TAG y busca la palabra clave Architecture. Si aparece Error: No such image: $IMAGE:$TAG, puede que tengas que extraer la imagen primero ejecutando docker pull $IMAGE:$TAG. Para obtener información sobre cómo crear imágenes de varias arquitecturas, consulta el artículo Crear una imagen de contenedor de varias arquitecturas.

Una vez que hayas identificado el error que provoca que el contenedor falle, intenta solucionarlo y vuelve a enviar la canalización.

No se ha podido completar la solicitud de extracción de la imagen. Error:

Durante el inicio del trabajador, aparece uno de los siguientes errores en los registros del trabajador o del trabajo:

Image pull request failed with error

pull access denied for IMAGE_NAME

manifest for IMAGE_NAME not found: manifest unknown: Failed to fetch

Get IMAGE_NAME: Service Unavailable

Estos errores se producen si un trabajador no puede iniciarse porque no puede extraer una imagen de contenedor de Docker. Este problema se produce en los siguientes casos:

• La URL de la imagen del contenedor del SDK personalizado es incorrecta
• El trabajador no tiene credenciales o acceso a la red para acceder a la imagen remota

Para solucionar este problema, sigue estos pasos:

• Si usas una imagen de contenedor personalizada con tu trabajo, comprueba que la URL de la imagen sea correcta y tenga una etiqueta o un digest válidos. Los trabajadores de Dataflow también necesitan acceso a la imagen.
• Verifica que las imágenes públicas se puedan extraer de forma local ejecutando docker pull $image desde una máquina no autenticada.

Para imágenes privadas o trabajadores privados:

• Si usas Container Registry para alojar tu imagen de contenedor, te recomendamos que uses Artifact Registry. A partir del 15 de mayo del 2023, Container Registry dejará de estar disponible. Si usas Container Registry, puedes migrar a Artifact Registry. Si tus imágenes están en un proyecto distinto al que se usa para ejecutar tu trabajo de Google Cloud Platform, configura el control de acceso de la cuenta de servicio predeterminada de Google Cloud Platform.
• Si usas una nube privada virtual (VPC) compartida, asegúrate de que los trabajadores puedan acceder al host del repositorio de contenedores personalizado.
• Usa ssh para conectarte a una VM de trabajador de una tarea en ejecución y ejecuta docker pull $image para confirmar directamente que el trabajador está configurado correctamente.

Si los trabajadores fallan varias veces seguidas debido a este error y se ha empezado a trabajar en una tarea, esta puede fallar y mostrar un error similar al siguiente mensaje:

Job appears to be stuck.

Si quitas el acceso a la imagen mientras se está ejecutando el trabajo, ya sea eliminando la imagen o revocando las credenciales de la cuenta de servicio del trabajador de Dataflow o el acceso a Internet para acceder a las imágenes, Dataflow solo registrará errores. Dataflow no falla la tarea. Dataflow también evita que los flujos de procesamiento de streaming de larga duración fallen para no perder el estado del flujo de procesamiento.

También pueden producirse otros errores debido a problemas o interrupciones de la cuota del repositorio. Si tienes problemas para superar la cuota de Docker Hub al extraer imágenes públicas o si se producen interrupciones generales en repositorios de terceros, te recomendamos que uses Artifact Registry como repositorio de imágenes.

SystemError: opcode desconocido

Es posible que tu canalización de contenedor personalizado de Python falle con el siguiente error inmediatamente después de enviar el trabajo:

SystemError: unknown opcode

Además, el rastreo de la pila puede incluir

apache_beam/internal/pickler.py

Para solucionar este problema, comprueba que la versión de Python que usas localmente coincida con la versión de la imagen del contenedor hasta la versión principal y secundaria. La diferencia en la versión del parche, como 3.6.7 frente a 3.6.8, no crea problemas de compatibilidad. La diferencia en la versión secundaria, como 3.6.8 frente a 3.8.2, puede provocar errores en la canalización.

Errores de actualización del flujo de procesamiento en streaming

Para obtener información sobre cómo resolver errores al actualizar una canalización de streaming mediante funciones como la ejecución de un trabajo de sustitución en paralelo, consulta el artículo Solucionar problemas de actualizaciones de canalizaciones de streaming.

Actualización del arnés de Runner v2

El siguiente mensaje informativo aparece en los registros de trabajos de un trabajo de Runner v2

The Dataflow RunnerV2 container image of this job's workers will be ready for update in 7 days.

Esto significa que la versión del proceso del arnés del ejecutor se actualizará automáticamente en algún momento 7 días después de la entrega inicial del mensaje, lo que provocará una breve pausa en el procesamiento. Si quieres controlar cuándo se produce esta pausa, consulta Actualizar una canalización para iniciar un trabajo de sustitución que tendrá la versión más reciente del contenedor del runner.

Errores de los trabajadores

En las secciones siguientes se describen los errores de trabajador habituales que pueden producirse y los pasos para resolverlos o solucionarlos.

La llamada del contenedor de trabajo de Java a Python DoFn falla con un error

Si falla una llamada del harness de trabajador de Java a un DoFn de Python, se muestra un mensaje de error pertinente.

Para investigar el error, amplía la entrada del registro de errores de Cloud Monitoring y consulta el mensaje de error y el traceback. Te muestra qué código ha fallado para que puedas corregirlo si es necesario. Si crees que el error es un fallo de Apache Beam o Dataflow, informa del fallo.

EOFError: marshal data too short

Aparece el siguiente error en los registros de los trabajadores:

EOFError: marshal data too short

Este error se produce a veces cuando los trabajadores de la canalización de Python se quedan sin espacio en el disco.

Para solucionar este problema, consulta la sección No queda espacio en el dispositivo.

No se ha podido adjuntar el disco

Cuando intentas iniciar una tarea de Dataflow que usa máquinas virtuales C3 con un disco persistente, la tarea falla y se produce uno de los siguientes errores (o ambos):

Failed to attach disk(s), status: generic::invalid_argument: One or more operations had an error

Can not allocate sha384 (reason: -2), Spectre V2 : WARNING: Unprivileged eBPF is enabled with eIBRS on...

Estos errores se producen cuando usas VMs C3 con un tipo de disco persistente no admitido. Para obtener más información, consulta Tipos de disco admitidos para C3.

Para usar máquinas virtuales C3 con tu tarea de Dataflow, elige el tipo de disco de trabajador pd-ssd. Para obtener más información, consulta Opciones a nivel de trabajador.

No queda espacio en el dispositivo

Cuando una tarea se queda sin espacio en disco, puede que aparezca el siguiente error en los registros del trabajador:

No space left on device

Este error puede producirse por uno de los siguientes motivos:

• El almacenamiento persistente del trabajador se queda sin espacio libre, lo que puede ocurrir por uno de los siguientes motivos:
  • Un trabajo descarga dependencias grandes en el tiempo de ejecución
  • Un trabajo usa contenedores personalizados grandes
  • Un trabajo escribe muchos datos temporales en el disco local
• Cuando se usa Dataflow Shuffle, Dataflow establece un tamaño de disco predeterminado más pequeño. Por lo tanto, este error puede producirse con tareas que se mueven de la ordenación aleatoria basada en trabajadores.
• El disco de arranque del trabajador se llena porque registra más de 50 entradas por segundo.

Para solucionar este problema, sigue estos pasos:

Para ver los recursos de disco asociados a un solo trabajador, busca los detalles de la instancia de VM de las VMs de trabajador asociadas a tu tarea. El sistema operativo, los archivos binarios, los registros y los contenedores consumen parte del espacio en disco.

Para aumentar el espacio del disco persistente o del disco de arranque, ajusta la opción de la canalización de tamaño del disco.

Monitoriza el uso del espacio en disco de las instancias de VM de los trabajadores con Cloud Monitoring. Consulta las instrucciones sobre cómo configurar esta opción en el artículo Recibir métricas de VMs de trabajador del agente de Monitoring.

Busca problemas de espacio en el disco de arranque viendo la salida del puerto serie en las instancias de VM de trabajador y buscando mensajes como los siguientes:

Failed to open system journal: No space left on device

Si tienes muchas instancias de VM de trabajador, puedes crear una secuencia de comandos para ejecutar gcloud compute instances get-serial-port-output en todas ellas a la vez. En su lugar, puedes revisar ese resultado.

La canalización de Python falla después de una hora de inactividad del trabajador

Si usas el SDK de Apache Beam para Python con Dataflow Runner V2 en máquinas de trabajo con muchos núcleos de CPU, usa el SDK de Apache Beam 2.35.0 o una versión posterior. Si tu trabajo usa un contenedor personalizado, utiliza el SDK de Apache Beam 2.46.0 o una versión posterior.

Te recomendamos que compiles previamente tu contenedor de Python. Este paso puede mejorar los tiempos de inicio de las VMs y el rendimiento del escalado automático horizontal. Para usar esta función, habilita la API de Cloud Build en tu proyecto y envía tu canal con el siguiente parámetro:

‑‑prebuild_sdk_container_engine=cloud_build.

Para obtener más información, consulta Dataflow Runner V2.

También puedes usar una imagen de contenedor personalizada con todas las dependencias preinstaladas.

RESOURCE_POOL_EXHAUSTED

Cuando creas un recurso de Google Cloud Platform, se produce el siguiente error:

Startup of the worker pool in zone ZONE_NAME failed to bring up any of the desired NUMBER workers.
ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS: Instance 'INSTANCE_NAME' creation failed: The zone 'projects/PROJECT_ID/zones/ZONE_NAME' does not have enough resources available to fulfill the request. '(resource type:RESOURCE_TYPE)'.

Este error se produce cuando se agota temporalmente el stock de un recurso específico en una zona concreta.

Para solucionar el problema, puedes esperar o crear el mismo recurso en otra zona.

Como solución alternativa, implementa un bucle de reintentos para tus tareas de forma que, cuando se produzca un error de falta de stock, la tarea se vuelva a intentar automáticamente hasta que haya recursos disponibles. Para crear un bucle de reintentos, implementa el siguiente flujo de trabajo:

1. Crea una tarea de Dataflow y obtén su ID.
2. Consulta el estado de la tarea hasta que sea RUNNING o FAILED.
   • Si el estado del trabajo es RUNNING, sal del bucle de reintentos.
   • Si el estado del trabajo es FAILED, usa la API Cloud Logging para consultar los registros del trabajo y buscar la cadena ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS. Para obtener más información, consulta el artículo Trabajar con registros de canalizaciones.
     • Si los registros no contienen la cadena, sal del bucle de reintentos.
     • Si los registros contienen la cadena, crea una tarea de Dataflow, obtén el ID de la tarea y reinicia el bucle de reintentos.

Como práctica recomendada, distribuye tus recursos en varias zonas y regiones para tolerar las interrupciones.

Las instancias con aceleradores invitados no admiten la migración en tiempo real

Un flujo de procesamiento de Dataflow falla al enviar un trabajo y muestra el siguiente error:

UNSUPPORTED_OPERATION: Instance <worker_instance_name> creation failed:
Instances with guest accelerators do not support live migration

Este error puede producirse si has solicitado un tipo de máquina de trabajador que tiene aceleradores de hardware, pero no has configurado Dataflow para que los use.

Usa la --worker_acceleratoropción de servicio Dataflow o la accelerator sugerencia de recurso para solicitar aceleradores de hardware.

Si usas plantillas flexibles, puedes usar la opción --additionalExperiments para proporcionar opciones del servicio Dataflow. Si lo haces correctamente, la opción worker_accelerator se encontrará en el panel de información del trabajo de la consolaGoogle Cloud .

Cuota del proyecto ... o políticas de control de acceso que impiden la operación

Se produce el siguiente error:

Startup of the worker pool in zone ZONE_NAME failed to bring up any of the desired NUMBER workers. The project quota may have been exceeded or access control policies may be preventing the operation; review the Cloud Logging 'VM Instance' log for diagnostics.

Este error se produce por uno de los siguientes motivos:

• Ha superado una de las cuotas de Compute Engine de las que depende la creación de trabajadores de Dataflow.
• Tu organización tiene restricciones que impiden algún aspecto del proceso de creación de instancias de VM, como la cuenta que se usa o la zona de destino.

Para solucionar este problema, sigue estos pasos:

Revisar el registro de la instancia de VM

1. Ve al visualizador de Cloud Logging.
2. En la lista desplegable Recurso auditado, selecciona Instancia de VM.
3. En la lista desplegable Todos los registros, selecciona compute.googleapis.com/activity_log.
4. Busca en el registro entradas relacionadas con el error de creación de la instancia de VM.

Consultar el uso de las cuotas de Compute Engine

1. Para ver el uso de recursos de Compute Engine en comparación con las cuotas de Dataflow de la zona de destino, ejecuta el siguiente comando:

   gcloud compute regions describe [REGION]

2. Revisa los resultados de los siguientes recursos para ver si alguno supera la cuota:

   • CPUs
   • DISKS_TOTAL_GB
   • IN_USE_ADDRESSES
   • INSTANCE_GROUPS
   • INSTANCES
   • REGIONAL_INSTANCE_GROUP_MANAGERS

3. Si es necesario, solicita un cambio de cuota.

Revisar las restricciones de las políticas de la organización

1. Ve a la página Políticas de la organización.
2. Revisa las restricciones que puedan limitar la creación de instancias de VM en la cuenta que estés usando (de forma predeterminada, la cuenta de servicio de Dataflow) o en la zona de destino.
3. Si tienes una política que restringe el uso de direcciones IP externas, desactiva las direcciones IP externas para este trabajo. Para obtener más información sobre cómo desactivar las direcciones IP externas, consulta Configurar el acceso a Internet y las reglas de cortafuegos.

Se ha agotado el tiempo de espera de una actualización del trabajador

Cuando falla una tarea de Dataflow, se produce el siguiente error:

Root cause: Timed out waiting for an update from the worker. For more information, see https://cloud.google.com/dataflow/docs/guides/common-errors#worker-lost-contact.

Este error puede deberse a varios motivos, entre los que se incluyen los siguientes:

• Sobrecarga de trabajadores
• Mantener el bloqueo de intérprete global
• Configuración de DoFn de larga duración

Sobrecarga de trabajadores

A veces, se produce un error de tiempo de espera cuando el trabajador se queda sin memoria o espacio de intercambio. Para solucionar este problema, prueba a volver a ejecutar el trabajo. Si el trabajo sigue fallando y se produce el mismo error, prueba a usar un trabajador con más memoria y espacio en disco. Por ejemplo, añade la siguiente opción de inicio de la canalización:

--worker_machine_type=m1-ultramem-40 --disk_size_gb=500

Si cambia el tipo de trabajador, podría afectar al coste facturado. Para obtener más información, consulta el artículo Solucionar errores de falta de memoria de Dataflow.

Este error también puede producirse si sus datos contienen una tecla de acceso rápido. En este caso, el uso de la CPU es elevado en algunos trabajadores durante la mayor parte de la duración del trabajo. Sin embargo, el número de trabajadores no alcanza el máximo permitido. Para obtener más información sobre las teclas de acceso rápido y las posibles soluciones, consulta el artículo Escribir flujos de procesamiento de datos de Dataflow teniendo en cuenta la escalabilidad.

Para ver otras soluciones a este problema, consulta Se ha detectado una tecla de acceso rápido ....

Python: bloqueo global del intérprete (GIL)

Si tu código Python llama a código C o C++ mediante el mecanismo de extensión de Python, comprueba si el código de extensión libera el bloqueo global del intérprete (GIL) de Python en las partes del código que requieren muchos cálculos y que no acceden al estado de Python. Si el GIL no se libera durante un periodo prolongado, es posible que veas mensajes de error como: Unable to retrieve status info from SDK harness <...> within allowed time y SDK worker appears to be permanently unresponsive. Aborting the SDK.

Las bibliotecas que facilitan las interacciones con extensiones como Cython y PyBind tienen primitivas para controlar el estado de GIL. También puedes liberar manualmente el GIL y volver a adquirirlo antes de devolver el control al intérprete de Python mediante las macros Py_BEGIN_ALLOW_THREADS y Py_END_ALLOW_THREADS. Para obtener más información, consulta Estado de los hilos y bloqueo global del intérprete en la documentación de Python.

Es posible recuperar los rastreos de pila de un subproceso que esté reteniendo el GIL en un trabajador de Dataflow en ejecución de la siguiente manera:

# SSH into a running Dataflow worker VM that is currently a straggler, for example:
gcloud compute ssh --zone "us-central1-a" "worker-that-emits-unable-to-retrieve-status-messages" --project "project-id"

# Install nerdctl to inspect a running container with ptrace privileges.
wget https://github.com/containerd/nerdctl/releases/download/v2.0.2/nerdctl-2.0.2-linux-amd64.tar.gz
sudo tar Cxzvvf /var/lib/toolbox  nerdctl-2.0.2-linux-amd64.tar.gz
alias nerdctl="sudo /var/lib/toolbox/nerdctl -n k8s.io"

# Find a container running the Python SDK harness.
CONTAINER_ID=`nerdctl ps | grep sdk-0-0 | awk '{print $1}'`

# Start a shell in the running container.
nerdctl exec --privileged -it $CONTAINER_ID /bin/bash

# Inspect python processes in the running container.
ps -A | grep python
PYTHON_PID=$(ps -A | grep python | head -1 | awk '{print $1}')

# Use pystack to retrieve stacktraces from the python process.
pip install pystack

pystack remote --native $PYTHON_PID

# Find which thread holds the GIL and inspect the stacktrace.
pystack remote --native $PYTHON_PID | grep -iF "Has the GIL" -A 100

# Alternately, use inspect with gdb.
apt update && apt install -y gdb
gdb --quiet \
  --eval-command="set pagination off" \
  --eval-command="thread apply all bt" \
  --eval-command "set confirm off" \
  --eval-command="quit"  -p $PYTHON_PID

En los flujos de procesamiento de Python, en la configuración predeterminada, Dataflow asume que cada proceso de Python que se ejecuta en los trabajadores utiliza de forma eficiente un núcleo de vCPU. Si el código de la canalización evita las limitaciones de GIL, por ejemplo, mediante el uso de bibliotecas implementadas en C++, es posible que los elementos de procesamiento utilicen recursos de más de un núcleo de vCPU y que los trabajadores no obtengan suficientes recursos de CPU. Para solucionar este problema, reduce el número de subprocesos en los trabajadores.

Configuración de DoFn de larga duración

Si no usas Runner v2, una llamada de larga duración a DoFn.Setup puede provocar el siguiente error:

Timed out waiting for an update from the worker

En general, evita las operaciones que requieran mucho tiempo dentro de DoFn.Setup.

Errores transitorios al publicar en un tema

Cuando tu tarea de streaming usa el modo de streaming al menos una vez y publica datos en un receptor de Pub/Sub, aparece el siguiente error en los registros de la tarea:

There were transient errors publishing to topic

Si el trabajo se ejecuta correctamente, este error es inofensivo y puedes ignorarlo. Dataflow vuelve a intentar enviar automáticamente los mensajes de Pub/Sub con un retraso de espera.

No se han podido obtener datos debido a que el token no coincide con la clave

El siguiente error significa que el elemento de trabajo que se está procesando se ha reasignado a otro trabajador:

Unable to fetch data due to token mismatch for key

Esto suele ocurrir durante el escalado automático, pero puede suceder en cualquier momento. Se volverá a intentar cualquier trabajo afectado. Puedes ignorar este error.

Problemas de dependencia de Java

Las clases y bibliotecas incompatibles pueden provocar problemas de dependencia de Java. Si tu flujo de procesamiento tiene problemas de dependencia de Java, puede que se produzca uno de los siguientes errores:

• NoClassDefFoundError: este error se produce cuando una clase completa no está disponible durante el tiempo de ejecución. Puede deberse a problemas de configuración generales o a incompatibilidades entre la versión de protobuf de Beam y los protos generados de un cliente (por ejemplo, este problema).
• NoSuchMethodError: este error se produce cuando la clase de la ruta de clases usa una versión que no contiene el método correcto o cuando la firma del método ha cambiado.
• NoSuchFieldError: este error se produce cuando la clase de la ruta de clases usa una versión que no tiene un campo necesario durante el tiempo de ejecución.
• FATAL ERROR in native method: este error se produce cuando no se puede cargar correctamente una dependencia integrada. Cuando uses uber JAR (con sombreado), no incluyas bibliotecas que usen firmas (como Conscrypt) en el mismo JAR.

Si tu canalización contiene código y ajustes específicos de un usuario, el código no puede contener versiones mixtas de bibliotecas. Si usas una biblioteca de gestión de dependencias, te recomendamos que uses la lista de materiales de las bibliotecas de Google Cloud Platform.

Si usas el SDK de Apache Beam, para importar la lista de materiales de las bibliotecas correctas, usa beam-sdks-java-io-google-cloud-platform-bom:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.beam</groupId>
      <artifactId>beam-sdks-java-google-cloud-platform-bom</artifactId>
      <version>BEAM_VERSION</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

dependencies {
    implementation(platform("org.apache.beam:beam-sdks-java-google-cloud-platform-bom:BEAM_VERSION"))
}

Para obtener más información, consulta Gestionar las dependencias de las canalizaciones en Dataflow.

InaccessibleObjectException en JDK 17 y versiones posteriores

Cuando ejecutas canalizaciones con las versiones 17 y posteriores del kit de desarrollo de Java Platform, Standard Edition (JDK), es posible que aparezca el siguiente error en los archivos de registro del trabajador:

Unable to make protected METHOD accessible:
    module java.MODULE does not "opens java.MODULE" to ...

Este problema se produce porque, a partir de la versión 9 de Java, se necesitan opciones de máquina virtual Java (JVM) de módulos abiertos para acceder a los elementos internos del JDK. En Java 16 y versiones posteriores, siempre se necesitan opciones de módulo abierto de JVM para acceder a los elementos internos de JDK.

Para solucionar este problema, cuando pases módulos a tu flujo de procesamiento de Dataflow para abrirlo, usa el formato MODULE/PACKAGE=TARGET_MODULE(,TARGET_MODULE)* con la opción de flujo de procesamiento jdkAddOpenModules. Este formato permite acceder a la biblioteca necesaria.

Por ejemplo, si el error es module java.base does not "opens java.lang" to unnamed module @..., incluye la siguiente opción de canalización al ejecutarla:

--jdkAddOpenModules=java.base/java.lang=ALL-UNNAMED

Para obtener más información, consulta la documentación de la clase DataflowPipelineOptions.

Error al informar del progreso del elemento de trabajo

En las canalizaciones de Java, si no usas Running V2, es posible que veas el siguiente error:

Error reporting workitem progress update to Dataflow service: ...

Este error se debe a una excepción no controlada durante una actualización del progreso de un elemento de trabajo, como durante la división de una fuente. En la mayoría de los casos, si el código de usuario de Apache Beam genera una excepción no controlada, el elemento de trabajo falla, lo que provoca que la canalización falle.Sin embargo, las excepciones de Source.split se suprimen porque esa parte del código está fuera de un elemento de trabajo. Por lo tanto, solo se registra un registro de errores.

Este error suele ser inofensivo si se produce solo de forma intermitente. Sin embargo, te recomendamos que gestiones las excepciones de forma correcta dentro de tu código Source.split.

Errores del conector de BigQuery

En las siguientes secciones se describen los errores habituales del conector de BigQuery que pueden producirse y los pasos para resolverlos o solucionarlos.

quotaExceeded

Cuando se usa el conector de BigQuery para escribir en BigQuery mediante inserciones de streaming, el rendimiento de escritura es inferior al esperado y puede producirse el siguiente error:

quotaExceeded

El bajo rendimiento puede deberse a que tu canalización supera la cuota de inserción de flujo de BigQuery disponible. Si es así, los mensajes de error relacionados con la cuota de BigQuery aparecerán en los registros de los trabajadores de Dataflow (busca errores quotaExceeded).

Si ves errores quotaExceeded, sigue estos pasos para solucionarlo:

• Cuando uses el SDK de Apache Beam para Java, define la opción de receptor de BigQuery ignoreInsertIds().
• Cuando uses el SDK de Apache Beam para Python, usa la opción ignore_insert_ids.

Con estos ajustes, podrás disfrutar de un rendimiento de inserción de streaming de BigQuery de 1 GB por segundo y por proyecto. Para obtener más información sobre las advertencias relacionadas con la deduplicación automática de mensajes, consulta la documentación de BigQuery. Para aumentar la cuota de inserción de BigQuery por encima de un GBps, envía una solicitud a través de la Google Cloud consola.

Si no ves errores relacionados con la cuota en los registros de los trabajadores, es posible que los parámetros predeterminados relacionados con la agrupación o el procesamiento por lotes no proporcionen el paralelismo adecuado para que tu canal se escale. Puedes ajustar varias configuraciones relacionadas con el conector de BigQuery de Dataflow para conseguir el rendimiento esperado al escribir en BigQuery mediante inserciones de streaming. Por ejemplo, en el caso del SDK de Apache Beam para Java, ajusta numStreamingKeys para que coincida con el número máximo de trabajadores y considera la posibilidad de aumentar insertBundleParallelism para configurar el conector de BigQuery de forma que escriba en BigQuery usando más subprocesos paralelos.

Para ver las configuraciones disponibles en el SDK de Apache Beam para Java, consulta BigQueryPipelineOptions. Para ver las configuraciones disponibles en el SDK de Apache Beam para Python, consulta la transformación WriteToBigQuery.

rateLimitExceeded

Al usar el conector de BigQuery, se produce el siguiente error:

rateLimitExceeded

Este error se produce si se envían demasiadas solicitudes a la API de BigQuery en un breve periodo. BigQuery tiene límites de cuota a corto plazo. Es posible que tu flujo de procesamiento de Dataflow supere temporalmente esa cuota. En este caso, es posible que las solicitudes a la API de tu flujo de procesamiento de Dataflow a BigQuery fallen, lo que podría provocar errores rateLimitExceeded en los registros de los trabajadores.

Dataflow vuelve a intentar realizar estas operaciones, por lo que puedes ignorar estos errores sin problemas. Si crees que tu canal se ve afectado por errores de rateLimitExceeded, ponte en contacto con Cloud Customer Care.

Errores varios

En las secciones siguientes se incluyen otros errores que pueden producirse y los pasos para resolverlos o solucionarlos.

No se puede asignar sha384

El trabajo se ejecuta correctamente, pero aparece el siguiente error en los registros de trabajo:

ima: Can not allocate sha384 (reason: -2)

Si el trabajo se ejecuta correctamente, este error es inofensivo y puedes ignorarlo. Las imágenes base de las VMs de trabajador a veces producen este mensaje. Dataflow responde y soluciona automáticamente el problema subyacente.

Hay una solicitud de función para cambiar el nivel de este mensaje de WARN a INFO. Para obtener más información, consulta el artículo sobre cómo reducir el nivel de registro de errores de inicio del sistema de Dataflow a WARN o INFO.

Error al inicializar el comprobador de complementos dinámicos

El trabajo se ejecuta correctamente, pero aparece el siguiente error en los registros de trabajo:

Error initializing dynamic plugin prober" err="error (re-)creating driver directory: mkdir /usr/libexec/kubernetes: read-only file system

Si el trabajo se ejecuta correctamente, este error es inofensivo y puedes ignorarlo. Este error se produce cuando el trabajo de Dataflow intenta crear un directorio sin los permisos de escritura necesarios y la tarea falla. Si el trabajo se completa correctamente, significa que el directorio no era necesario o que Dataflow ha solucionado el problema subyacente.

Hay una solicitud de función para cambiar el nivel de este mensaje de WARN a INFO. Para obtener más información, consulta el artículo sobre cómo reducir el nivel de registro de errores de inicio del sistema de Dataflow a WARN o INFO.

No se ha encontrado el objeto: pipeline.pb

Al enumerar los trabajos con la opción JOB_VIEW_ALL, se produce el siguiente error:

No such object: BUCKET_NAME/PATH/pipeline.pb

Este error puede producirse si eliminas el archivo pipeline.pb de los archivos de almacenamiento provisional del trabajo.

Saltar la sincronización de los pódcasts

El trabajo se ejecuta correctamente, pero aparece uno de los siguientes errores en los registros de trabajo:

Skipping pod synchronization" err="container runtime status check may not have completed yet"

O:

Skipping pod synchronization" err="[container runtime status check may not have completed yet, PLEG is not healthy: pleg has yet to be successful]"

Si el trabajo se ejecuta correctamente, estos errores son inofensivos y puedes ignorarlos. El mensaje container runtime status check may not have completed yet se produce cuando el kubelet de Kubernetes omite la sincronización de pods porque está esperando que se inicialice el tiempo de ejecución del contenedor. Este escenario se produce por varios motivos, como cuando el tiempo de ejecución del contenedor se ha iniciado recientemente o se está reiniciando.

Cuando el mensaje incluye PLEG is not healthy: pleg has yet to be successful, el kubelet espera a que el generador de eventos del ciclo de vida del pod (PLEG) esté en buen estado antes de sincronizar los pods. El PLEG se encarga de generar eventos que usa kubelet para monitorizar el estado de los pods.

Hay una solicitud de función para cambiar el nivel de este mensaje de WARN a INFO. Para obtener más información, consulta el artículo sobre cómo reducir el nivel de registro de errores de inicio del sistema de Dataflow a WARN o INFO.

Recomendaciones

Para obtener información sobre las recomendaciones generadas por Estadísticas de Dataflow, consulta Estadísticas.