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 temporal y el destino se encuentran 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 arnés 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 entrada/salida 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

El tamaño de la carga útil de la solicitud supera el límite: 20971520 bytes

Cuando ejecutas una canalización, es posible que el trabajo falle y se muestre el siguiente error:

com.google.api.client.googleapis.json.GoogleJsonResponseException: 400 Bad Request
POST https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID/workItems:reportStatus
{
  "code": 400,
  "errors": [
    {
      "domain": "global",
      "message": "Request payload size exceeds the limit: 20971520 bytes.",
      "reason": "badRequest"
    }
  ],
  "message": "Request payload size exceeds the limit: 20971520 bytes.",
  "status": "INVALID_ARGUMENT"
}

Este error puede producirse cuando una tarea que usa el ejecutor de Dataflow tiene un gráfico de tareas muy grande. Un gráfico de tareas grande puede generar un gran número de métricas que deben enviarse al servicio Dataflow. Si el tamaño de estas métricas supera el límite de 20 MB de la solicitud de la API, el trabajo fallará.

Para resolver este problema, migra tu flujo de trabajo para que use Dataflow Runner v2. Runner v2 usa un método más eficiente para generar informes de métricas y no tiene esta limitación de 20 MB.

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 de forma local, 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 de gran tamaño 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 un flujo de registro diferente. 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 notifican como INFO, incluye los registros INFO en tu 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