Resolva problemas de erros do Dataflow

Se tiver problemas com o pipeline ou a tarefa do Dataflow, esta página apresenta mensagens de erro que pode ver e sugestões sobre como corrigir cada erro.

Os erros nos tipos de registo dataflow.googleapis.com/worker-startup, dataflow.googleapis.com/harness-startup e dataflow.googleapis.com/kubelet indicam problemas de configuração com uma tarefa. Também podem indicar condições que impedem o funcionamento do caminho de registo normal.

O seu pipeline pode gerar exceções durante o processamento de dados. Alguns destes erros são transitórios, por exemplo, quando ocorre uma dificuldade temporária ao aceder a um serviço externo. Alguns destes erros são permanentes, como erros causados por dados de entrada danificados ou não analisáveis, ou ponteiros nulos durante o cálculo.

O Dataflow processa elementos em pacotes arbitrários e tenta novamente o pacote completo quando é gerado um erro para qualquer elemento nesse pacote. Quando executados no modo de lote, os pacotes que incluem um item com falha são repetidos quatro vezes. O pipeline falha completamente quando um único pacote falha quatro vezes. Quando é executado no modo de streaming, um pacote que inclui um item com falhas é repetido indefinidamente, o que pode fazer com que o seu pipeline fique permanentemente parado.

As exceções no código do utilizador, por exemplo, as suas instâncias DoFn, são comunicadas na interface de monitorização do fluxo de dados. Se executar o pipeline com BlockingDataflowPipelineRunner, também vê mensagens de erro impressas na janela da consola ou do terminal.

Considere proteger-se contra erros no seu código adicionando processadores de exceções. Por exemplo, se quiser ignorar elementos que falham alguma validação de entrada personalizada feita num ParDo, use um bloco try/catch no seu ParDo para processar a exceção e registar e ignorar o elemento. Para cargas de trabalho de produção, implemente um padrão de mensagens não processadas. Para acompanhar a contagem de erros, use transformações de agregação.

Ficheiros de registo em falta

Se não vir registos para os seus trabalhos, remova todos os filtros de exclusão que contenham resource.type="dataflow_step" de todos os destinos do Log Router do Cloud Logging.

Aceder ao registo do router

Para mais detalhes sobre a remoção das exclusões de registos, consulte o guia Remover exclusões.

Duplicados no resultado

Quando executa uma tarefa do Dataflow, o resultado contém registos duplicados.

Este problema pode ocorrer quando a tarefa do Dataflow usa o modo de streaming de pipeline, pelo menos, uma vez. Este modo garante que os registos são processados, pelo menos, uma vez. No entanto, é possível ter registos duplicados neste modo.

Se o seu fluxo de trabalho não tolerar registos duplicados, use o modo de streaming exactly-once. Este modo ajuda a garantir que os registos não são ignorados nem duplicados à medida que os dados se movem através do pipeline.

Para verificar que modo de streaming a sua tarefa está a usar, consulte o artigo Veja o modo de streaming de uma tarefa.

Para mais informações sobre os modos de streaming, consulte o artigo Defina o modo de streaming do pipeline.

Erros de pipeline

As secções seguintes contêm erros comuns do pipeline que pode encontrar e passos para resolver ou solucionar os erros.

É necessário ativar algumas APIs Cloud

Quando tenta executar uma tarefa do Dataflow, ocorre o seguinte erro:

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

Este problema ocorre porque algumas APIs necessárias não estão ativadas no seu projeto.

Para resolver este problema e executar uma tarefa do Dataflow, ative as seguintes APIs no seu projeto:Google Cloud

• Compute Engine API (Compute Engine)
• Cloud Logging API
• Cloud Storage
• API JSON do Cloud Storage
• API BigQuery
• Pub/Sub
• API Datastore

Para instruções detalhadas, consulte a secção Introdução sobre a ativação de Google Cloud APIs .

"@*" e "@N" são especificações de divisão reservadas

Quando tenta executar uma tarefa, é apresentado o seguinte erro nos ficheiros de registo e a tarefa falha:

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

Este erro ocorre se o nome do ficheiro do caminho do Cloud Storage para ficheiros temporários (tempLocation ou temp_location) tiver um sinal de arroba (@) seguido de um número ou um asterisco (*).

Para resolver este problema, altere o nome do ficheiro para que o símbolo arroba seja seguido de um caráter suportado.

Pedido inválido

Quando executa uma tarefa do Dataflow, os registos do Cloud Monitoring apresentam uma série de avisos semelhantes aos seguintes:

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

Os avisos de pedido inválido ocorrem se as informações do estado do trabalhador estiverem desatualizadas ou dessincronizadas devido a atrasos no processamento. Muitas vezes, a tarefa do Dataflow é bem-sucedida, apesar dos avisos de pedidos incorretos. Se for o caso, ignore os avisos.

Não é possível ler nem escrever em localizações diferentes

Quando executa uma tarefa do Dataflow, pode ver o seguinte erro nos ficheiros de registo:

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

Este erro ocorre quando a origem e o destino estão em regiões diferentes. Também pode ocorrer quando a localização de preparação e o destino estão em regiões diferentes. Por exemplo, se a tarefa ler a partir do Pub/Sub e, em seguida, escrever num contentor do tempCloud Storage antes de escrever numa tabela do BigQuery, o contentor do tempCloud Storage e a tabela do BigQuery têm de estar na mesma região.

As localizações multirregionais são consideradas diferentes das localizações de região única, mesmo que a região única esteja no âmbito da localização multirregional. Por exemplo, us (multiple regions in the United States) e us-central1 são regiões diferentes.

Para resolver este problema, certifique-se de que os locais de destino, origem e preparação estão na mesma região. Não é possível alterar as localizações dos contentores do Cloud Storage, pelo que pode ter de criar um novo contentor do Cloud Storage na região correta.

A ligação excedeu o tempo limite

Quando executa uma tarefa do Dataflow, pode ver o seguinte erro nos ficheiros de registo:

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 ocorre quando os trabalhadores do Dataflow não conseguem estabelecer nem manter uma ligação com a origem ou o destino de dados.

Para resolver o problema, siga estes passos de resolução de problemas:

• Verifique se a origem de dados está em execução.
• Verifique se o destino está em execução.
• Reveja os parâmetros de ligação usados na configuração do pipeline do Dataflow.
• Verifique se os problemas de desempenho não estão a afetar a origem nem o destino.
• Certifique-se de que as regras de firewall não estão a bloquear a ligação.

Não existe um objeto deste género

Quando executa as tarefas do Dataflow, pode ver o seguinte erro nos ficheiros de registo:

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

Normalmente, estes erros ocorrem quando algumas das suas tarefas do Dataflow em execução usam o mesmo temp_location para preparar ficheiros de tarefas temporários criados quando a pipeline é executada. Quando várias tarefas simultâneas partilham o mesmo temp_location, estas tarefas podem interferir nos dados temporários umas das outras, e pode ocorrer uma condição de corrida. Para evitar este problema, recomendamos que use um temp_location> único para cada tarefa.

O fluxo de dados não consegue determinar o atraso

Quando executa um pipeline de streaming a partir do Pub/Sub, ocorre o seguinte aviso:

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

Quando um pipeline do Dataflow extrai dados do Pub/Sub, o Dataflow precisa de pedir repetidamente informações ao Pub/Sub. Estas informações incluem a quantidade de pendências na subscrição e a idade da mensagem não reconhecida mais antiga. Ocasionalmente, o Dataflow não consegue obter estas informações do Pub/Sub devido a problemas internos do sistema, o que pode causar uma acumulação temporária de pendências.

Para mais informações, consulte o artigo Streaming com o Cloud Pub/Sub.

DEADLINE_EXCEEDED ou servidor sem resposta

Quando executa as suas tarefas, pode encontrar exceções de limite de tempo de RPC ou um dos seguintes erros:

DEADLINE_EXCEEDED

Ou:

Server Unresponsive

Normalmente, estes erros ocorrem por um dos seguintes motivos:

• A rede de nuvem virtual privada (VPC) usada para a sua tarefa pode não ter uma regra de firewall. A regra de firewall tem de ativar todo o tráfego TCP entre as VMs na rede VPC que especificou nas opções da pipeline. Para mais informações, consulte o artigo Regras de firewall para o Dataflow.

  Em alguns casos, os trabalhadores não conseguem comunicar entre si. Quando executa uma tarefa do Dataflow que não usa o Dataflow Shuffle nem o Streaming Engine, os trabalhadores têm de comunicar entre si através das portas TCP 12345 e 12346 na rede da VPC. Neste cenário, o erro inclui o nome do worker harness e a porta TCP bloqueada. O erro tem o aspeto de um dos seguintes exemplos:

  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 resolver este problema, use a flag gcloud compute firewall-rules create rules para permitir o tráfego de rede para as portas 12345 e 12346. O exemplo seguinte demonstra o comando da CLI gcloud:

  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
  

  Substitua o seguinte:

  • FIREWALL_RULE_NAME: o nome da regra de firewall
  • NETWORK: o nome da sua rede

• A sua tarefa está associada à reprodução aleatória.

  Para resolver este problema, faça uma ou mais das seguintes alterações.

  Java

  • Se a tarefa não estiver a usar a aleatorização baseada em serviços, mude para a aleatorização do Dataflow baseada em serviços definindo --experiments=shuffle_mode=service. Para ver detalhes e disponibilidade, consulte o artigo Dataflow Shuffle.
  • Adicione mais trabalhadores. Experimente definir --numWorkers com um valor mais elevado quando executar o pipeline.
  • Aumente o tamanho do disco anexado para os trabalhadores. Experimente definir --diskSizeGb com um valor mais elevado quando executar o pipeline.
  • Use um disco persistente com tecnologia SSD. Experimente definir --workerDiskType="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" quando executar o pipeline.

  Python

  • Se a tarefa não estiver a usar a aleatorização baseada em serviços, mude para a aleatorização do Dataflow baseada em serviços definindo --experiments=shuffle_mode=service. Para ver detalhes e disponibilidade, consulte o artigo Dataflow Shuffle.
  • Adicione mais trabalhadores. Experimente definir --num_workers com um valor mais elevado quando executar o pipeline.
  • Aumente o tamanho do disco anexado para os trabalhadores. Experimente definir --disk_size_gb com um valor mais elevado quando executar o pipeline.
  • Use um disco persistente com tecnologia SSD. Experimente definir --worker_disk_type="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" quando executar o pipeline.

  Ir

  • Se a tarefa não estiver a usar a aleatorização baseada em serviços, mude para a aleatorização do Dataflow baseada em serviços definindo --experiments=shuffle_mode=service. Para ver detalhes e disponibilidade, consulte o artigo Dataflow Shuffle.
  • Adicione mais trabalhadores. Experimente definir --num_workers com um valor mais elevado quando executar o pipeline.
  • Aumente o tamanho do disco anexado para os trabalhadores. Experimente definir --disk_size_gb com um valor mais elevado quando executar o pipeline.
  • Use um disco persistente com tecnologia SSD. Experimente definir --disk_type="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" quando executar o pipeline.

Erros de codificação, IOExceptions ou comportamento inesperado no código do utilizador

Os SDKs do Apache Beam e os trabalhadores do Dataflow dependem de componentes comuns de terceiros. Estes componentes importam dependências adicionais. As colisões de versões podem resultar num comportamento inesperado no serviço. Além disso, algumas bibliotecas não são compatíveis com versões futuras. Pode ter de fixar as versões listadas que estão no âmbito durante a execução. Dependências do SDK e do Worker contém uma lista de dependências e as respetivas versões necessárias.

Erro ao executar LookupEffectiveGuestPolicies

Quando executa uma tarefa do Dataflow, pode ver o seguinte erro nos ficheiros de registo:

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 erro ocorre se a gestão da configuração do SO estiver ativada para todo o projeto.

Para resolver este problema, desative as políticas do VM Manager que se aplicam a todo o projeto. Se não for possível desativar as políticas do VM Manager para todo o projeto, pode ignorar com segurança este erro e filtrá-lo das ferramentas de monitorização de registos.

Foi detetado um erro fatal pelo Java Runtime Environment

Ocorre o seguinte erro durante o arranque do trabalhador:

A fatal error has been detected by the Java Runtime Environment

Este erro ocorre se o pipeline estiver a usar a interface nativa Java (JNI) para executar código não Java e esse código ou as associações JNI contiverem um erro.

Erro da chave do atributo googclient_deliveryattempt

A sua tarefa do Dataflow falha com um dos seguintes erros:

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).

Ou:

Invalid extensions name: googclient_deliveryattempt

Este erro ocorre quando a tarefa do Dataflow tem as seguintes características:

• A tarefa do Dataflow usa o Streaming Engine.
• O pipeline tem um destino do Pub/Sub.
• O pipeline usa uma subscrição de obtenção.
• O pipeline usa uma das APIs do serviço Pub/Sub para publicar mensagens em vez de usar o destino de E/S do Pub/Sub incorporado.
• O Pub/Sub está a usar a biblioteca cliente Java ou C#.
• A subscrição do Pub/Sub tem um tópico de mensagens não entregues.

Este erro ocorre porque, quando usa a biblioteca de cliente Java ou C# do Pub/Sub e um tópico de mensagens não entregues para uma subscrição está ativado, as tentativas de entrega estão no atributo de mensagem googclient_deliveryattempt em vez do campo delivery_attempt. Para mais informações, consulte o artigo Monitorize as tentativas de entrega na página "Resolva falhas de mensagens".

Para contornar este problema, faça uma ou mais das seguintes alterações.

• Desative o motor de streaming.
• Use o conector Apache Beam PubSubIO integrado em vez da API do serviço Pub/Sub.
• Use um tipo de subscrição do Pub/Sub diferente.
• Remova o tópico de mensagens não entregues.
• Não use a biblioteca cliente Java ou C# com a sua subscrição de obtenção do Pub/Sub. Para outras opções, consulte os exemplos de código da biblioteca de cliente.
• No código do pipeline, quando as chaves de atributos começam por goog, apague os atributos das mensagens antes de publicar as mensagens.

Foi detetada uma tecla de atalho ...

Nota: a deteção e o registo de teclas de atalho estão desativados para pipelines de streaming desde março de 2022.

Ocorre o seguinte erro:

A hot key HOT_KEY_NAME was detected in...

Estes erros ocorrem se os seus dados contiverem uma tecla de atalho. Uma tecla de atalho é uma tecla com elementos suficientes para afetar negativamente o desempenho do pipeline. Estas chaves limitam a capacidade do Dataflow de processar elementos em paralelo, o que aumenta o tempo de execução.

Para imprimir a chave legível por humanos nos registos quando é detetada uma tecla de atalho no pipeline, use a opção de pipeline de teclas de atalho.

Para resolver este problema, verifique se os dados estão distribuídos uniformemente. Se uma chave tiver um número desproporcionado de valores, considere as seguintes ações:

• Volte a introduzir a chave dos seus dados. Aplique uma transformação ParDo para gerar novos pares chave-valor.
• Para tarefas Java, use a transformação Combine.PerKey.withHotKeyFanout.
• Para tarefas Python, use a função CombinePerKey.with_hot_key_fanout transform.
• Ative o Dataflow Shuffle.

Para ver as teclas de atalho na interface de monitorização do Dataflow, consulte o artigo Resolva problemas de atrasos em trabalhos em lote.

Especificação da tabela inválida no catálogo de dados

Quando usa o Dataflow SQL para criar tarefas do Dataflow SQL, a tarefa pode falhar com o seguinte erro nos ficheiros de registo:

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

Este erro ocorre se a conta de serviço do Dataflow não tiver acesso à API Data Catalog.

Para resolver este problema, ative a API Data Catalog no Google Cloud projeto que está a usar para escrever e executar consultas.

Em alternativa, atribua a função roles/datacatalog.viewer à conta de serviço do Dataflow.

O gráfico de tarefas é demasiado grande

A tarefa pode falhar com o seguinte erro:

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 erro ocorre se o tamanho do gráfico da tarefa exceder 10 MB. Determinadas condições no seu pipeline podem fazer com que o gráfico de tarefas exceda o limite. As condições comuns incluem:

• Uma transformação Create que inclui uma grande quantidade de dados na memória.
• Uma instância DoFn que é serializada para transmissão a trabalhadores remotos.
• Um DoFn como uma instância de classe interna anónima que (possivelmente, de forma inadvertida) extrai uma grande quantidade de dados para serem serializados.
• Está a ser usado um gráfico acíclico orientado (DAG) como parte de um ciclo programático que está a enumerar uma lista grande.

Para evitar estas condições, pondere reestruturar o seu pipeline.

Key Commit Too Large

Quando executa uma tarefa de streaming, é apresentado o seguinte erro nos ficheiros de registo do trabalhador:

KeyCommitTooLargeException

Este erro ocorre em cenários de streaming se uma quantidade muito grande de dados for agrupada sem usar uma transformação Combine ou se uma grande quantidade de dados for produzida a partir de um único elemento de entrada.

Para reduzir a possibilidade de encontrar este erro, use as seguintes estratégias:

• Certifique-se de que o processamento de um único elemento não pode resultar em saídas ou modificações de estado que excedam o limite.
• Se vários elementos foram agrupados por uma chave, considere aumentar o espaço de chaves para reduzir os elementos agrupados por chave.
• Se os elementos de uma chave forem emitidos com uma frequência elevada durante um curto período, isso pode resultar em muitos GB de eventos para essa chave em janelas. Reescrever o pipeline para detetar chaves como esta e emitir apenas um resultado que indique que a chave estava frequentemente presente nessa janela.
• Use transformações de espaço sublineares Combine para operações comutativas e associativas. Não use um combinador se não reduzir o espaço. Por exemplo, o combinador para strings que apenas anexa strings é pior do que não usar o combinador.

A rejeitar mensagem com mais de 7168 KB

Quando executa uma tarefa do Dataflow criada a partir de um modelo, a tarefa pode falhar com o seguinte erro:

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 erro ocorre quando as mensagens escritas numa fila de mensagens rejeitadas excedem o limite de tamanho de 7168 K. Como solução alternativa, ative o Streaming Engine, que tem um limite de tamanho superior. Para ativar o Streaming Engine, use a seguinte opção de pipeline.

Java

--enableStreamingEngine=true

Python

--enable_streaming_engine=true

Entidade do pedido demasiado extensa

Quando envia o seu trabalho, é apresentado um dos seguintes erros na consola ou na janela do 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

Quando encontra um erro sobre o payload JSON ao enviar a tarefa, a representação JSON do pipeline excede o tamanho máximo do pedido de 20 MB.

A dimensão da tarefa está associada à representação JSON do pipeline. Uma conduta maior significa um pedido maior. O Dataflow tem uma limitação que restringe os pedidos a 20 MB.

Para estimar o tamanho do pedido JSON do seu pipeline, execute-o com a seguinte opção:

Java

--dataflowJobFile=PATH_TO_OUTPUT_FILE

Python

--dataflow_job_file=PATH_TO_OUTPUT_FILE

Ir

A saída do seu trabalho como JSON não é suportada em Go.

Este comando escreve uma representação JSON da sua tarefa num ficheiro. O tamanho do ficheiro serializado é uma boa estimativa do tamanho do pedido. O tamanho real é ligeiramente superior devido a algumas informações adicionais incluídas no pedido.

Determinadas condições no seu pipeline podem fazer com que a representação JSON exceda o limite. As condições comuns incluem:

• Uma transformação Create que inclui uma grande quantidade de dados na memória.
• Uma instância DoFn que é serializada para transmissão a trabalhadores remotos.
• Um DoFn como uma instância de classe interna anónima que (possivelmente, de forma inadvertida) extrai uma grande quantidade de dados para serem serializados.

Para evitar estas condições, pondere reestruturar o seu pipeline.

As opções da pipeline do SDK ou a lista de ficheiros de preparação excedem o limite de tamanho

Quando executa um pipeline, ocorre um dos seguintes erros:

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

Ou:

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

Estes erros ocorrem se não for possível iniciar o pipeline devido ao excesso dos limites de metadados do Compute Engine. Não é possível alterar estes limites. O Dataflow usa metadados do Compute Engine para opções de pipelines. O limite está documentado nas limitações dos metadados personalizados do Compute Engine.

Os seguintes cenários podem fazer com que a representação JSON exceda o limite:

• Existem demasiados ficheiros JAR para preparar.
• O campo de pedido sdkPipelineOptions é demasiado grande.

Para estimar o tamanho do pedido JSON do seu pipeline, execute-o com a seguinte opção:

Java

--dataflowJobFile=PATH_TO_OUTPUT_FILE

Python

--dataflow_job_file=PATH_TO_OUTPUT_FILE

Ir

A saída do seu trabalho como JSON não é suportada em Go.

O tamanho do ficheiro de saída deste comando tem de ser inferior a 256 KB. Os 512 KB na mensagem de erro referem-se ao tamanho total do ficheiro de saída e às opções de metadados personalizados para a instância de VM do Compute Engine.

Pode obter uma estimativa aproximada da opção de metadados personalizados para a instância de VM executando tarefas do Dataflow no projeto. Escolha qualquer tarefa do Dataflow em execução. Selecione uma instância de VM e, em seguida, navegue para a página de detalhes da instância de VM do Compute Engine para verificar a secção de metadados personalizados. O comprimento total dos metadados personalizados e do ficheiro deve ser inferior a 512 KB. Não é possível fazer uma estimativa precisa para a tarefa com falha, porque as VMs não são iniciadas para tarefas com falha.

Se a sua lista de JARs estiver a atingir o limite de 256 KB, reveja-a e reduza os ficheiros JAR desnecessários. Se ainda for demasiado grande, experimente executar a tarefa do Dataflow com um JAR uber. Para ver um exemplo que demonstra como criar e usar um JAR completo, consulte Crie e implemente um JAR completo.

Se o campo de pedido sdkPipelineOptions for demasiado grande, inclua a seguinte opção quando executar o pipeline. A opção de pipeline é a mesma para Java, Python e Go.

--experiments=no_display_data_on_gce_metadata

Chave de aleatorização demasiado grande

O seguinte erro é apresentado nos ficheiros de registo do trabalhador:

Shuffle key too large

Este erro ocorre se a chave serializada emitida para um (Co-)GroupByKey específico for demasiado grande após a aplicação do codificador correspondente. O Dataflow tem um limite para chaves de ordenação aleatória serializadas.

Para resolver este problema, reduza o tamanho das chaves ou use codificadores mais eficientes em termos de espaço.

Para mais informações, consulte os limites de produção do Dataflow.

O número total de objetos BoundedSource ... é superior ao limite permitido

Pode ocorrer um dos seguintes erros ao executar tarefas com Java:

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

Ou:

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

Java

Este erro pode ocorrer se estiver a ler um número muito grande de ficheiros através de TextIO, AvroIO ou BigQueryIO através da EXPORT ou de alguma outra origem baseada em ficheiros. O limite específico depende dos detalhes da sua origem, mas é da ordem das dezenas de milhares de ficheiros num pipeline. Por exemplo, a incorporação de esquemas em AvroIO.Read permite menos ficheiros.

Este erro também pode ocorrer se tiver criado uma origem de dados personalizada para o seu pipeline e o método splitIntoBundles da sua origem tiver devolvido uma lista de objetos BoundedSource que ocupa mais de 20 MB quando serializada.

O limite permitido para o tamanho total dos BoundedSource objetos gerados pela operação splitIntoBundles() da sua origem personalizada é de 20 MB.

Para contornar esta limitação, faça uma das seguintes alterações:

1. Ative o Runner V2. O Runner v2 converte as origens em DoFns divisíveis que não têm este limite de divisão de origens.

2. Modifique a sua subclasse BoundedSource personalizada para que o tamanho total dos objetos BoundedSource gerados seja inferior ao limite de 20 MB. Por exemplo, a sua origem pode gerar inicialmente menos divisões e basear-se no reequilíbrio dinâmico do trabalho para dividir ainda mais as entradas a pedido.

O tamanho do payload do pedido excede o limite: 20971520 bytes

Quando executa um pipeline, a tarefa pode falhar com o seguinte erro:

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 erro pode ocorrer quando uma tarefa que usa o executor do Dataflow tem um gráfico de tarefas muito grande. Um gráfico de tarefas grande pode gerar um grande número de métricas que têm de ser comunicadas ao serviço Dataflow. Se o tamanho destas métricas exceder o limite de pedido da API de 20 MB, a tarefa falha.

Para resolver este problema, migre o seu pipeline para usar o Dataflow Runner v2. O Runner v2 usa um método mais eficiente para comunicar métricas e não tem esta limitação de 20 MB.

NameError

Quando executa o pipeline através do serviço Dataflow, ocorre o seguinte erro:

NameError

Este erro não ocorre quando executa localmente, por exemplo, quando executa o comando usando o DirectRunner.

Este erro ocorre se os seus DoFns estiverem a usar valores no espaço de nomes global que não estão disponíveis no worker do Dataflow.

Por predefinição, as importações, as funções e as variáveis globais definidas na sessão principal não são guardadas durante a serialização de uma tarefa do Dataflow.

Para resolver este problema, use um dos seguintes métodos. Se as DoFnestiverem definidas no ficheiro principal e fizerem referência a importações e funções no espaço de nomes global, defina a opção de pipeline --save_main_session como True. Esta alteração serializa o estado do espaço de nomes global e carrega-o no trabalhador do Dataflow.

Se tiver objetos no seu espaço de nomes global que não podem ser processados, ocorre um erro de processamento. Se o erro estiver relacionado com um módulo que deve estar disponível na distribuição do Python, importe o módulo localmente, onde é usado.

Por exemplo, em vez de:

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

utilização:

def myfunc():
  import re
  # use re module

Em alternativa, se os seus DoFns abrangerem vários ficheiros, use uma abordagem diferente para agrupar o fluxo de trabalho e gerir as dependências.

O objeto está sujeito à Política de Retenção do contentor

Quando tem uma tarefa do Dataflow que escreve num contentor do Cloud Storage, a tarefa falha com o seguinte erro:

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

Também pode ver o seguinte erro:

Unable to rename "gs://BUCKET"

O primeiro erro ocorre quando a retenção de objetos está ativada no contentor do Cloud Storage para o qual a tarefa do Dataflow está a escrever. Para mais informações, consulte o artigo Ative e use configurações de retenção de objetos.

Para resolver este problema, use uma das seguintes soluções alternativas:

• Escrever num contentor do Cloud Storage que não tenha uma política de retenção na pasta temp.

• Remova a política de retenção do contentor para o qual a tarefa escreve. Para mais informações, consulte o artigo Defina a configuração de retenção de um objeto.

O segundo erro pode indicar que a retenção de objetos está ativada no contentor do Cloud Storage ou que a conta de serviço do trabalhador do Dataflow não tem autorização para escrever no contentor do Cloud Storage.

Se vir o segundo erro e a retenção de objetos estiver ativada no contentor do Cloud Storage, experimente as soluções alternativas descritas anteriormente. Se a retenção de objetos não estiver ativada no contentor do Cloud Storage, verifique se a conta de serviço do trabalhador do Dataflow tem autorização de escrita no contentor do Cloud Storage. Para mais informações, consulte o artigo Aceda aos contentores do Cloud Storage.

O processamento está bloqueado ou a operação está em curso

Se o Dataflow passar mais tempo a executar um DoFn do que o tempo especificado em TIME_INTERVAL sem ser devolvido, é apresentada a seguinte mensagem.

Java

Uma das duas seguintes mensagens de registo, consoante a versão:

Processing stuck in step STEP_NAME for at least TIME_INTERVAL

Operation ongoing in bundle BUNDLE_ID for at least TIME_INTERVAL without outputting or completing: at STACK_TRACE

Python

Operation ongoing for over TIME_INTERVAL in state STATE in step STEP_ID without returning. Current Traceback: TRACEBACK

Ir

Operation ongoing in transform TRANSFORM_ID for at least TIME_INTERVAL without outputting or completing in state STATE

Este comportamento tem duas causas possíveis:

• O seu código DoFn é lento ou está a aguardar a conclusão de alguma operação externa lenta.
• O seu código DoFn pode estar bloqueado, em impasse ou a demorar demasiado tempo a concluir o processamento.

Para determinar qual é o caso, expanda a entrada do registo do Cloud Monitoring para ver um rastreio da pilha. Procure mensagens que indiquem que o código DoFn está bloqueado ou a ter problemas. Se não estiverem presentes mensagens, o problema pode estar relacionado com a velocidade de execução do código DoFn. Considere usar o Cloud Profiler ou outra ferramenta para investigar o desempenho do seu código.

Se o seu pipeline for criado na VM Java (usando Java ou Scala), pode investigar a causa do código bloqueado. Faça um despejo de threads completo de toda a JVM (não apenas do thread bloqueado) seguindo estes passos:

1. Tome nota do nome do trabalhador na entrada do registo.
2. Na secção do Compute Engine da Google Cloud consola, encontre a instância do Compute Engine com o nome do trabalhador que anotou.
3. Use o SSH para se ligar à instância com esse nome.

4. Execute o seguinte comando:

   curl http://localhost:8081/threadz
   

Operação em curso no pacote

Quando executa um pipeline de leitura a partir de JdbcIO, as leituras particionadas a partir de JdbcIO são lentas e a seguinte mensagem é apresentada nos ficheiros de registo do trabalhador:

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 resolver este problema, faça uma ou mais das seguintes alterações ao seu pipeline:

• Use partições para aumentar o paralelismo das tarefas. Leitura com partições mais pequenas e em maior número para uma melhor escalabilidade.

• Verifique se a coluna de partição é uma coluna de índice ou uma coluna de partição verdadeira na origem. Ative a indexação e a partição nesta coluna na base de dados de origem para ter o melhor desempenho.

• Use os parâmetros lowerBound e upperBound para ignorar a localização dos limites.

Erros de quota do Pub/Sub

Quando executa um pipeline de streaming a partir do Pub/Sub, ocorrem os seguintes erros:

429 (rateLimitExceeded)

Ou:

Request was throttled due to user QPS limit being reached

Estes erros ocorrem se o seu projeto tiver uma quota do Pub/Sub insuficiente.

Para saber se o seu projeto tem uma quota insuficiente, siga estes passos para verificar se existem erros do cliente:

1. Aceda à Google Cloud consola.
2. No menu do lado esquerdo, selecione APIs e serviços.
3. Na caixa de pesquisa, pesquise Cloud Pub/Sub.
4. Clique no separador Utilização.
5. Verifique os códigos de resposta e procure códigos de erro de cliente (4xx).

O pedido é proibido pela política da organização

Quando executa um pipeline, ocorre o seguinte erro:

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 erro ocorre se o contentor do Cloud Storage estiver fora do seu perímetro de serviço.

Para resolver este problema, crie uma regra de saída que permita o acesso ao contentor fora do perímetro de serviço.

O pacote preparado… está inacessível

As tarefas que eram bem-sucedidas podem falhar com o seguinte erro:

Staged package...is inaccessible

Para resolver este problema:

• Verifique se o contentor do Cloud Storage usado para a preparação não tem definições de TTL que façam com que os pacotes preparados sejam eliminados.

• Verifique se a conta de serviço do trabalhador do seu projeto do Dataflow tem autorização para aceder ao contentor do Cloud Storage usado para a preparação. As lacunas nas autorizações podem dever-se a qualquer um dos seguintes motivos:

  • O contentor do Cloud Storage usado para a preparação está presente num projeto diferente.
  • O contentor do Cloud Storage usado para a preparação foi migrado do acesso detalhado para o acesso uniforme ao nível do contentor. Devido à inconsistência entre as políticas de IAM e ACL, a migração do contentor de preparação para o acesso de nível de contentor uniforme não permite ACLs para recursos do Cloud Storage. As ACLs incluem as autorizações detidas pela conta de serviço do trabalhador do seu projeto do Dataflow sobre o contentor de preparação.

Para mais informações, consulte o artigo Aceder a contentores do Cloud Storage em projetos da Google Cloud Platform.

Um item de trabalho falhou 4 vezes

O seguinte erro ocorre quando uma tarefa em lote falha:

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

Este erro ocorre se uma única operação num trabalho em lote fizer com que o código do trabalhador falhe quatro vezes. O fluxo de dados falha a tarefa e esta mensagem é apresentada.

Quando executado no modo de streaming, um pacote que inclua um item com falhas é repetido indefinidamente, o que pode fazer com que o seu pipeline fique permanentemente parado.

Não pode configurar este limite de falhas. Para mais detalhes, consulte o artigo sobre a resolução de erros e exceções de pipelines.

Para resolver este problema, procure nos registos do Cloud Monitoring da tarefa as quatro falhas individuais. Nos registos do trabalhador, procure entradas de registo de nível de erro ou nível fatal que mostrem exceções ou erros. A exceção ou o erro deve aparecer, pelo menos, quatro vezes. Se os registos contiverem apenas erros de tempo limite genéricos relacionados com o acesso a recursos externos, como o MongoDB, verifique se a conta de serviço do trabalhador tem autorização para aceder à sub-rede do recurso.

Limite de tempo excedido no ficheiro de resultados da sondagem

Para ver informações completas sobre a resolução de problemas de um erro "Timeout in polling result file" (Tempo limite no ficheiro de resultados da sondagem), consulte o artigo Resolva problemas de modelos flexíveis.

Write Correct File/Write/WriteImpl/PreFinalize failed

Quando executa uma tarefa, esta falha intermitentemente e ocorre o seguinte erro:

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 erro ocorre quando a mesma subpasta é usada como a localização de armazenamento temporário para várias tarefas executadas em simultâneo.

Para resolver este problema, não use a mesma subpasta como localização de armazenamento temporário para vários pipelines. Para cada pipeline, indique uma subpasta única para usar como localização de armazenamento temporário.

O elemento excede o tamanho máximo da mensagem protobuf

Quando executa tarefas do Dataflow e o seu pipeline tem elementos grandes, pode ver erros semelhantes aos seguintes exemplos:

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

Ou:

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

Ou:

Output element size exceeds the allowed limit. (... > 83886080) See https://cloud.google.com/dataflow/quotas#limits for more details.

Também pode ver um aviso semelhante ao seguinte exemplo:

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

Estes erros ocorrem quando o seu pipeline contém elementos grandes.

Para resolver este problema, se usar o SDK do Python, atualize para o Apache Beam versão 2.57.0 ou posterior. As versões 2.57.0 e posteriores do SDK Python melhoram o processamento de elementos grandes e adicionam registos relevantes.

Se os erros persistirem após a atualização ou se não estiver a usar o SDK Python, identifique o passo na tarefa em que o erro ocorre e tente reduzir o tamanho dos elementos nesse passo.

Quando os objetos PCollection no seu pipeline têm elementos grandes, os requisitos de RAM do pipeline aumentam. Os elementos grandes também podem causar erros de tempo de execução, especialmente quando atravessam os limites das fases unidas.

Os elementos grandes podem ocorrer quando um pipeline materializa inadvertidamente um iterável grande. Por exemplo, um pipeline que passa o resultado de uma operação GroupByKey para uma operação Reshuffle desnecessária materializa listas como elementos únicos. Estas listas contêm potencialmente um grande número de valores para cada chave.

Se o erro ocorrer num passo que usa uma entrada lateral, tenha em atenção que a utilização de entradas laterais pode introduzir uma barreira de fusão. Verifique se a transformação que produz um elemento grande e a transformação que o consome pertencem à mesma fase.

Ao criar o seu pipeline, siga estas práticas recomendadas:

• Em PCollections, use vários elementos pequenos em vez de um único elemento grande.
• Armazene grandes objetos BLOB em sistemas de armazenamento externos. Use PCollections para transmitir os respetivos metadados ou use um programador personalizado que reduza o tamanho do elemento.
• Se tiver de transmitir uma PCollection que possa exceder 2 GB como uma entrada lateral, use vistas iteráveis, como AsIterable e AsMultiMap.

O tamanho máximo de um único elemento num trabalho do Dataflow está limitado a 2 GB (ou 80 MB para o Streaming Engine). Para mais informações, consulte o artigo Quotas e limites.

O fluxo de dados não consegue processar transformações geridas…

Os pipelines que usam E/S geridas podem falhar com este erro se o Dataflow não conseguir atualizar automaticamente as transformações de E/S para a versão suportada mais recente. O URN e os nomes dos passos indicados no erro devem especificar exatamente que transformações o Dataflow não conseguiu atualizar.

Pode encontrar detalhes adicionais acerca deste erro no Explorador de registos em Nomes de registos do Dataflow managed-transforms-worker e managed-transforms-worker-startup.

Se o Explorador de registos não fornecer informações adequadas para resolver o erro, contacte o apoio técnico do Google Cloud.

Erros de tarefas de arquivo

As secções seguintes contêm erros comuns que pode encontrar quando tenta arquivar uma tarefa do Dataflow através da API.

Não é fornecido nenhum valor

Quando tenta arquivar uma tarefa do Dataflow através da API, pode ocorrer o seguinte erro:

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 erro ocorre por um dos seguintes motivos:

• O caminho especificado para o campo updateMask não segue o formato correto. Este problema pode ocorrer devido a erros ortográficos.

• O JobMetadata não está especificado corretamente. No campo JobMetadata, para userDisplayProperties, use o par de chave-valor "archived":"true".

Para resolver este erro, verifique se o comando que transmite à API corresponde ao formato necessário. Para mais detalhes, consulte o artigo Arquive uma tarefa.

A API não reconhece o valor

Quando tenta arquivar uma tarefa do Dataflow através da API, pode ocorrer o seguinte erro:

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 erro ocorre quando o valor fornecido no par valor-chave de tarefas de arquivo não é um valor suportado. Os valores suportados para o par de chave-valor de tarefas de arquivo são "archived":"true" e "archived":"false".

Para resolver este erro, verifique se o comando que transmite à API corresponde ao formato necessário. Para mais detalhes, consulte o artigo Arquive uma tarefa.

Não é possível atualizar o estado e a máscara

Quando tenta arquivar uma tarefa do Dataflow através da API, pode ocorrer o seguinte erro:

Cannot update both state and mask.

Este erro ocorre quando tenta atualizar o estado da tarefa e o estado de arquivo na mesma chamada API. Não pode fazer atualizações ao estado da tarefa e ao parâmetro de consulta updateMask na mesma chamada API.

Para resolver este erro, atualize o estado da tarefa numa chamada da API separada. Faça atualizações ao estado da tarefa antes de atualizar o estado de arquivo da tarefa.

Falha na modificação do fluxo de trabalho

Quando tenta arquivar uma tarefa do Dataflow através da API, pode ocorrer o seguinte erro:

Workflow modification failed.

Normalmente, este erro ocorre quando tenta arquivar uma tarefa em execução.

Para resolver este erro, aguarde até que a tarefa seja concluída antes de a arquivar. Os trabalhos concluídos têm um dos seguintes estados de trabalho:

• JOB_STATE_CANCELLED
• JOB_STATE_DRAINED
• JOB_STATE_DONE
• JOB_STATE_FAILED
• JOB_STATE_UPDATED

Para mais informações, consulte o artigo Detetar a conclusão de tarefas do Dataflow.

Erros de imagem de contentor

As secções seguintes contêm erros comuns que pode encontrar quando usa contentores personalizados e passos para resolver ou solucionar os erros. Normalmente, os erros têm o seguinte prefixo:

Unable to pull container image due to error: DETAILED_ERROR_MESSAGE

Autorização "containeranalysis.occurrences.list" recusada

O seguinte erro é apresentado nos ficheiros de registo:

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"]

A API Container Analysis é necessária para a análise de vulnerabilidades.

Nota: esta API é ativada automaticamente pela API Container Scanning.

Para mais informações, consulte os artigos Vista geral da análise de SO e Configurar o controlo de acesso na documentação do Artifact Analysis.

Erro ao sincronizar o pod… falha ao "StartContainer"

Ocorre o seguinte erro durante o arranque do trabalhador:

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].

Um pod é um grupo de contentores Docker localizados em conjunto que são executados num worker do Dataflow. Este erro ocorre quando um dos contentores Docker no pod não é iniciado. Se a falha não for recuperável, o worker do Dataflow não consegue iniciar e as tarefas em lote do Dataflow acabam por falhar com erros como os seguintes:

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

Normalmente, este erro ocorre quando um dos contentores falha continuamente durante o arranque.

Nota: se vir um erro Dataflow job appears to be stuck quando um único trabalhador é iniciado repetidamente e, em seguida, parado após alguns minutos, o problema é provavelmente um problema de rede. Para mais informações, consulte o artigo O trabalhador único é iniciado e parado repetidamente.

Para compreender a causa principal, procure os registos capturados imediatamente antes da falha. Para analisar os registos, use o Explorador de registos. No Explorador de registos, limite os ficheiros de registo às entradas de registo emitidas pelo worker com erros de arranque do contentor. Para limitar as entradas do registo, conclua os seguintes passos:

1. No Explorador de registos, encontre a entrada de registo Error syncing pod.
2. Para ver as etiquetas associadas à entrada do registo, expanda a entrada do registo.
3. Clique na etiqueta associada ao resource_name e, de seguida, clique em Mostrar entradas correspondentes.

No Explorador de registos, os registos do Dataflow estão organizados em várias streams de registos. A mensagem Error syncing pod é emitida no registo com o nome kubelet. No entanto, os registos do contentor com falhas podem estar num fluxo de registo diferente. Cada contentor tem um nome. Use a tabela seguinte para determinar que stream de registos pode conter registos relevantes para o contentor com falhas.

Nome do contentor	Nomes de registos
sdk, sdk0, sdk1, sdk-0-0 e semelhantes	docker
arnês	arnês, arnês-início
python, java-batch, java-streaming	worker-startup, worker
artefacto	artefacto

Quando consultar o Explorador de registos, certifique-se de que a consulta inclui os nomes de registos relevantes na interface do criador de consultas ou não tem restrições no nome do registo.

Depois de selecionar os registos relevantes, o resultado da consulta pode ter o seguinte aspeto:

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")

Uma vez que os registos que comunicam o sintoma da falha do contentor são, por vezes, comunicados como INFO, inclua registos INFO na sua análise.

As causas típicas de falhas de contentores incluem o seguinte:

1. O seu pipeline Python tem dependências adicionais que são instaladas no tempo de execução e a instalação não é bem-sucedida. Pode ver erros como pip install failed with error. Este problema pode ocorrer devido a requisitos em conflito ou a uma configuração de rede restrita que impede que um worker do Dataflow extraia uma dependência externa de um repositório público através da Internet.

2. Um trabalhador falha a meio da execução do pipeline devido a um erro de falta de memória. Pode ver um erro como um dos seguintes:

   • 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 um problema de falta de memória, consulte o artigo Resolva problemas de falta de memória do Dataflow.

3. O fluxo de dados não consegue extrair a imagem do contentor. Para mais informações, consulte o artigo O pedido de obtenção de imagens falhou com o erro.

4. O contentor usado não é compatível com a arquitetura da CPU da VM do trabalhador. Nos registos de arranque do arnês, pode ver um erro semelhante ao seguinte: exec /opt/apache/beam/boot: exec format error. Para verificar a arquitetura da imagem do contentor, execute docker image inspect $IMAGE:$TAG e procure a palavra-chave Architecture. Se for apresentado o erro Error: No such image: $IMAGE:$TAG, pode ter de extrair primeiro a imagem executando o comando docker pull $IMAGE:$TAG. Para obter informações sobre a criação de imagens de várias arquiteturas, consulte o artigo Crie uma imagem de contentor de várias arquiteturas.

Depois de identificar o erro que está a fazer com que o contentor falhe, tente resolver o erro e, em seguida, reenvie o pipeline.

O pedido de obtenção de imagens falhou com o erro

Durante o arranque do trabalhador, é apresentado um dos seguintes erros nos registos do trabalhador ou da tarefa:

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

Estes erros ocorrem se um trabalhador não conseguir iniciar porque não consegue obter uma imagem de contentor Docker. Este problema ocorre nos seguintes cenários:

• O URL da imagem do contentor do SDK personalizado está incorreto
• O trabalhador não tem credenciais nem acesso à rede para a imagem remota

Para resolver este problema:

• Se estiver a usar uma imagem de contentor personalizada com o seu trabalho, verifique se o URL da imagem está correto e tem uma etiqueta ou um resumo válidos. Os trabalhadores do Dataflow também precisam de acesso à imagem.
• Verifique se as imagens públicas podem ser extraídas localmente executando o docker pull $image a partir de uma máquina não autenticada.

Para imagens privadas ou trabalhadores privados:

• Se estiver a usar o Container Registry para alojar a sua imagem de contentor, é recomendado que use o Artifact Registry. A partir de 15 de maio de 2023, o Container Registry foi descontinuado. Se usar o Container Registry, pode fazer a transição para o Artifact Registry. Se as suas imagens estiverem num projeto diferente do usado para executar a tarefa da Google Cloud Platform, configure o controlo de acesso para a conta de serviço predefinida da Google Cloud Platform.
• Se estiver a usar uma nuvem virtual privada (VPC) partilhada, certifique-se de que os trabalhadores conseguem aceder ao anfitrião do repositório de contentores personalizado.
• Use ssh para estabelecer ligação a uma VM de trabalho em execução e execute docker pull $image para confirmar diretamente que o trabalhador está configurado corretamente.

Se os trabalhadores falharem várias vezes seguidas devido a este erro e o trabalho tiver sido iniciado num trabalho, o trabalho pode falhar com um erro semelhante à seguinte mensagem:

Job appears to be stuck.

Se remover o acesso à imagem enquanto a tarefa está em execução, seja removendo a própria imagem ou revogando as credenciais da conta de serviço do trabalhador do Dataflow ou o acesso à Internet para aceder às imagens, o Dataflow apenas regista erros. O Dataflow não falha a tarefa. O Dataflow também evita falhas em pipelines de streaming de longa duração para evitar a perda do estado do pipeline.

Outros erros possíveis podem surgir de problemas ou indisponibilidades de quota do repositório. Se tiver problemas ao exceder a quota do Docker Hub para extrair imagens públicas ou interrupções gerais de repositórios de terceiros, considere usar o Artifact Registry como repositório de imagens.

SystemError: unknown opcode

O pipeline do contentor personalizado do Python pode falhar com o seguinte erro imediatamente após o envio da tarefa:

SystemError: unknown opcode

Além disso, o rastreio de pilha pode incluir

apache_beam/internal/pickler.py

Para resolver este problema, verifique se a versão do Python que está a usar localmente corresponde à versão na imagem do contentor até à versão principal e secundária. A diferença na versão de patch, como 3.6.7 em comparação com 3.6.8, não cria problemas de compatibilidade. A diferença na versão secundária, como 3.6.8 em comparação com 3.8.2, pode causar falhas no pipeline.

Erros de atualização do pipeline de streaming

Para obter informações sobre como resolver erros quando atualiza um pipeline de streaming usando funcionalidades como a execução de uma tarefa de substituição paralela, consulte o artigo Resolva problemas de atualizações de pipelines de streaming.

Atualização do arnês do Runner v2

A seguinte mensagem de informação é apresentada nos registos de tarefas de uma tarefa do Runner v2

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

Isto significa que a versão do processo de enquadramento do executor vai ser atualizada automaticamente 7 dias após a entrega inicial da mensagem, o que resulta numa breve pausa no processamento. Se quiser controlar quando esta pausa ocorre, consulte o artigo Atualize um pipeline existente para iniciar uma tarefa de substituição que terá a versão mais recente da plataforma de execução.

Erros do trabalhador

As secções seguintes contêm erros comuns de trabalhadores que pode encontrar e passos para resolver ou solucionar os erros.

A chamada do Java worker harness para o Python DoFn falha com um erro

Se uma chamada do framework de trabalho Java para um DoFn do Python falhar, é apresentada uma mensagem de erro relevante.

Para investigar o erro, expanda a entrada do registo de erros do Cloud Monitoring e consulte a mensagem de erro e o rastreio. Mostra-lhe que código falhou para que o possa corrigir, se necessário. Se considerar que o erro é um erro no Apache Beam ou Dataflow, denuncie o erro.

EOFError: marshal data too short

O seguinte erro é apresentado nos registos do trabalhador:

EOFError: marshal data too short

Este erro ocorre por vezes quando os trabalhadores do pipeline Python ficam sem espaço no disco.

Para resolver este problema, consulte o artigo Não existe espaço disponível no dispositivo.

Falha ao anexar o disco

Quando tenta iniciar uma tarefa do Dataflow que usa VMs C3 com disco persistente, a tarefa falha com um ou ambos os seguintes erros:

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...

Estes erros ocorrem quando usa VMs C3 com um tipo de disco persistente não suportado. Para mais informações, consulte o artigo Tipos de discos suportados para C3.

Para usar VMs C3 com a sua tarefa do Dataflow, escolha o pd-ssd tipo de disco do trabalhador. Para mais informações, consulte as Opções ao nível do trabalhador.

Java

--workerDiskType=pd-ssd

Python

--worker_disk_type=pd-ssd

Ir

disk_type=pd-ssd

Não existe espaço no dispositivo

Quando um trabalho fica sem espaço em disco, pode aparecer o seguinte erro nos registos do trabalhador:

No space left on device

Este erro pode ocorrer por um dos seguintes motivos:

• O armazenamento persistente do trabalhador fica sem espaço livre, o que pode ocorrer por um dos seguintes motivos:
  • Uma tarefa transfere grandes dependências no tempo de execução
  • Uma tarefa usa contentores personalizados grandes
  • Uma tarefa escreve muitos dados temporários no disco local
• Quando usa o Dataflow Shuffle, o Dataflow define um tamanho do disco predefinido inferior. Como resultado, este erro pode ocorrer com tarefas que se movem do embaralhamento baseado em trabalhadores.
• O disco de arranque do trabalhador fica cheio porque está a registar mais de 50 entradas por segundo.

Para resolver este problema, siga estes passos de resolução de problemas:

Para ver os recursos de disco associados a um único trabalhador, procure os detalhes da instância da VM para as VMs de trabalho associadas à sua tarefa. Parte do espaço em disco é consumida pelo sistema operativo, ficheiros binários, registos e contentores.

Para aumentar o espaço do disco persistente ou do disco de arranque, ajuste a opção da pipeline de tamanho do disco.

Monitorize a utilização do espaço em disco nas instâncias de VM do worker através do Cloud Monitoring. Consulte o artigo Receba métricas de VMs de trabalho do agente de monitorização para ver instruções que explicam como configurar esta opção.

Procure problemas de espaço no disco de arranque: Ver saída da porta série nas instâncias de VM do trabalhador e procure mensagens como:

Failed to open system journal: No space left on device

Se tiver muitas instâncias de VMs de trabalho, pode criar um script para executar gcloud compute instances get-serial-port-output em todas elas em simultâneo. Em alternativa, pode rever esse resultado.

O pipeline Python falha após uma hora de inatividade do trabalhador

Quando usar o SDK do Apache Beam para Python com o Dataflow Runner V2 em máquinas de trabalho com muitos núcleos de CPU, use o SDK do Apache Beam 2.35.0 ou posterior. Se o seu trabalho usar um contentor personalizado, use o SDK do Apache Beam 2.46.0 ou posterior.

Considere pré-criar o contentor Python. Este passo pode melhorar os tempos de arranque das VMs e o desempenho do escalamento automático horizontal. Para usar esta funcionalidade, ative a API Cloud Build no seu projeto e envie o pipeline com o seguinte parâmetro:

‑‑prebuild_sdk_container_engine=cloud_build.

Para mais informações, consulte o artigo Dataflow Runner V2.

Também pode usar uma imagem de contentor personalizada com todas as dependências pré-instaladas.

RESOURCE_POOL_EXHAUSTED

Quando cria um recurso da Google Cloud Platform, ocorre o seguinte erro:

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 erro ocorre em condições temporárias de indisponibilidade de stock para um recurso específico numa zona específica.

Para resolver o problema, pode aguardar ou criar o mesmo recurso noutra zona.

Como solução alternativa, implemente um ciclo de repetição para as suas tarefas, para que, quando ocorrer um erro de falta de stock, a tarefa seja repetida automaticamente até que os recursos estejam disponíveis. Para criar um ciclo de repetição, implemente o seguinte fluxo de trabalho:

1. Crie uma tarefa do Dataflow e obtenha o ID da tarefa.
2. Faça uma sondagem ao estado do trabalho até que o estado do trabalho seja RUNNING ou FAILED.
   • Se o estado da tarefa for RUNNING, saia do ciclo de nova tentativa.
   • Se o estado da tarefa for FAILED, use a Cloud Logging API para consultar os registos da tarefa para a string ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS. Para mais informações, consulte o artigo Trabalhe com registos de pipelines.
     • Se os registos não contiverem a string, saia do ciclo de repetição.
     • Se os registos contiverem a string, crie uma tarefa do Dataflow, obtenha o ID da tarefa e reinicie o ciclo de repetição.

Como prática recomendada, distribua os seus recursos por várias zonas e regiões para tolerar interrupções.

As instâncias com aceleradores convidados não suportam a migração em direto

Um pipeline do Dataflow falha no envio da tarefa com o seguinte erro:

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

Este erro pode ocorrer quando pediu um tipo de máquina de trabalho que tem aceleradores de hardware, mas não configurou o Dataflow para usar aceleradores.

Use a --worker_acceleratoropção de serviço Dataflow ou a accelerator sugestão de recurso para pedir aceleradores de hardware.

Se usar modelos flexíveis, pode usar a opção --additionalExperiments para fornecer opções do serviço Dataflow. Se o fizer corretamente, pode encontrar a opção worker_accelerator no painel de informações da tarefa naGoogle Cloud consola.

Quota do projeto… ou políticas de controlo de acesso que impedem a operação

Ocorre o seguinte erro:

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 erro ocorre por um dos seguintes motivos:

• Excedeu uma das quotas do Compute Engine das quais a criação de trabalhadores do Dataflow depende.
• A sua organização tem restrições em vigor que proíbem algum aspeto do processo de criação de instâncias de VM, como a conta que está a ser usada ou a zona que está a ser segmentada.

Para resolver este problema, siga estes passos de resolução de problemas:

Reveja o registo da instância de VM

1. Aceda ao visualizador de Registos na nuvem
2. Na lista pendente Recurso auditado, selecione Instância de VM.
3. Na lista pendente Todos os registos, selecione compute.googleapis.com/activity_log.
4. Analise o registo para ver se existem entradas relacionadas com a falha na criação da instância de VM.

Verifique a sua utilização das quotas do Compute Engine

1. Para ver a utilização de recursos do Compute Engine em comparação com as quotas do Dataflow para a zona que está a segmentar, execute o seguinte comando:

   gcloud compute regions describe [REGION]

2. Reveja os resultados dos seguintes recursos para ver se algum está a exceder a quota:

   • CPUS
   • DISKS_TOTAL_GB
   • IN_USE_ADDRESSES
   • INSTANCE_GROUPS
   • INSTANCES
   • REGIONAL_INSTANCE_GROUP_MANAGERS

3. Se necessário, peça uma alteração da quota.

Reveja as restrições da política da sua organização

1. Aceda à página Políticas da organização
2. Reveja as restrições que possam limitar a criação de instâncias de VM para a conta que está a usar (por predefinição, a conta de serviço do Dataflow) ou na zona que está a segmentar.
3. Se tiver uma política que restringe a utilização de endereços IP externos, desative os endereços IP externos para esta tarefa. Para mais informações sobre como desativar os endereços IP externos, consulte o artigo Configure o acesso à Internet e as regras de firewall.

Foi excedido o tempo limite enquanto aguardava uma atualização do trabalhador

Quando uma tarefa do Dataflow falha, ocorre o seguinte erro:

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.

Várias causas podem levar a este erro, incluindo as seguintes:

• Sobrecarga do trabalhador
• Manter o bloqueio do intérprete global
• Configuração de DoFn de execução prolongada

Sobrecarga de trabalhadores

Por vezes, ocorre um erro de limite de tempo quando o trabalhador fica sem memória ou espaço de troca. Para resolver este problema, como primeiro passo, experimente executar a tarefa novamente. Se a tarefa continuar a falhar e ocorrer o mesmo erro, experimente usar um trabalhador com mais memória e espaço em disco. Por exemplo, adicione a seguinte opção de inicialização do pipeline:

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

Alterar o tipo de trabalhador pode afetar o custo faturado. Para mais informações, consulte o artigo Resolva problemas de erros de falta de memória do Dataflow.

Este erro também pode ocorrer quando os seus dados contêm uma tecla de atalho. Neste cenário, a utilização da CPU é elevada em alguns trabalhadores durante a maior parte da duração da tarefa. No entanto, o número de trabalhadores não atinge o máximo permitido. Para mais informações sobre teclas de atalho e possíveis soluções, consulte o artigo Escrever pipelines do Dataflow tendo em conta a escalabilidade.

Para ver soluções adicionais para este problema, consulte o artigo Foi detetada uma tecla de atalho ....

Python: Global Interpreter Lock (GIL)

Se o seu código Python chamar código C/C++ através do mecanismo de extensão do Python, verifique se o código de extensão liberta o bloqueio global do interpretador (GIL) do Python em partes do código que exigem muitos cálculos e que não acedem ao estado do Python. Se o GIL não for libertado durante um período prolongado, pode ver mensagens de erro como: Unable to retrieve status info from SDK harness <...> within allowed time e SDK worker appears to be permanently unresponsive. Aborting the SDK.

As bibliotecas que facilitam as interações com extensões como o Cython e o PyBind têm primitivas para controlar o estado do GIL. Também pode libertar manualmente o GIL e adquiri-lo novamente antes de devolver o controlo ao intérprete do Python através das macros Py_BEGIN_ALLOW_THREADS e Py_END_ALLOW_THREADS. Para mais informações, consulte o artigo Estado do segmento e o bloqueio do interpretador global na documentação do Python.

Pode ser possível obter rastreios de pilha de um segmento que esteja a reter o GIL num worker do Dataflow em execução da seguinte forma:

# 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

Nos pipelines Python, na configuração predefinida, o Dataflow assume que cada processo Python em execução nos trabalhadores usa eficientemente um núcleo de vCPU. Se o código do pipeline ignorar as limitações da GIL, como através da utilização de bibliotecas implementadas em C++, os elementos de processamento podem usar recursos de mais do que um núcleo de CPU virtual, e os trabalhadores podem não receber recursos de CPU suficientes. Para contornar este problema, reduza o número de threads nos trabalhadores.

Configuração de DoFn de execução longa

Se não estiver a usar o Runner v2, uma chamada de longa duração para DoFn.Setup pode originar o seguinte erro:

Timed out waiting for an update from the worker

Em geral, evite operações demoradas dentro de DoFn.Setup.

Erros temporários ao publicar no tópico

Quando a tarefa de streaming usa o modo de streaming "pelo menos uma vez" e publica num destino do Pub/Sub, é apresentado o seguinte erro nos registos da tarefa:

There were transient errors publishing to topic

Se a tarefa for executada corretamente, este erro é benigno e pode ignorá-lo. O Dataflow tenta novamente enviar automaticamente as mensagens do Pub/Sub com um atraso de recuo.

Não é possível obter dados devido a uma incompatibilidade de tokens para a chave

O seguinte erro significa que o item de trabalho que está a ser processado foi reatribuído a outro trabalhador:

Unable to fetch data due to token mismatch for key

Isto ocorre mais frequentemente durante o dimensionamento automático, mas pode acontecer em qualquer altura. Qualquer trabalho afetado vai ser repetido. Pode ignorar este erro.

Problemas de dependência do Java

As classes e as bibliotecas incompatíveis podem causar problemas de dependência Java. Quando o pipeline tem problemas de dependência do Java, pode ocorrer um dos seguintes erros:

• NoClassDefFoundError: este erro ocorre quando uma classe inteira não está disponível durante o tempo de execução. Pode dever-se a problemas de configuração gerais ou a incompatibilidades entre a versão protobuf do Beam e os protos gerados de um cliente (por exemplo, este problema).
• NoSuchMethodError: este erro ocorre quando a classe no caminho de classe usa uma versão que não contém o método correto ou quando a assinatura do método foi alterada.
• NoSuchFieldError: este erro ocorre quando a classe no caminho de classe usa uma versão que não tem um campo necessário durante a execução.
• FATAL ERROR in native method: este erro ocorre quando não é possível carregar corretamente uma dependência incorporada. Quando usar o JAR Uber (sombreado), não inclua bibliotecas que usem assinaturas (como o Conscrypt) no mesmo JAR.

Se o seu pipeline contiver código e definições específicos do utilizador, o código não pode conter versões misturadas de bibliotecas. Se estiver a usar uma biblioteca de gestão de dependências, recomendamos que use a BOM das bibliotecas da Google Cloud Platform.

Se estiver a usar o SDK Apache Beam, para importar a BOM das bibliotecas corretas, use beam-sdks-java-io-google-cloud-platform-bom:

Maven

<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>

Gradle

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

Para mais informações, consulte o artigo Faça a gestão das dependências de pipelines no Dataflow.

InaccessibleObjectException no JDK 17 e posterior

Quando executa pipelines com as versões 17 e posteriores do Java Platform, Standard Edition Development Kit (JDK), pode aparecer o seguinte erro nos ficheiros de registo do trabalhador:

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

Este problema ocorre porque, a partir da versão 9 do Java, são necessárias opções de máquina virtual Java (JVM) de módulo aberto para aceder aos elementos internos do JDK. No Java 16 e versões posteriores, as opções de JVM de módulo aberto são sempre necessárias para aceder aos detalhes internos do JDK.

Para resolver este problema, quando passar módulos para o pipeline do Dataflow para abrir, use o formato MODULE/PACKAGE=TARGET_MODULE(,TARGET_MODULE)* com a opção de pipeline jdkAddOpenModules. Este formato permite o acesso à biblioteca necessária.

Por exemplo, se o erro for module java.base does not "opens java.lang" to unnamed module @..., inclua a seguinte opção de pipeline quando executar o pipeline:

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

Para mais informações, consulte a DataflowPipelineOptions documentação da classe.

Relatório de erros do progresso do item de trabalho

Para pipelines Java, se não estiver a usar o Running V2, pode ver o seguinte erro:

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

Este erro é causado por uma exceção não processada durante uma atualização do progresso de um item de trabalho, como durante a divisão de uma origem. Na maioria dos casos, se o código do utilizador do Apache Beam gerar uma exceção não processada, o item de trabalho falha, o que faz com que o pipeline falhe.No entanto, as exceções em Source.split são suprimidas, porque essa parte do código está fora de um item de trabalho. Como resultado, apenas é registado um registo de erros.

Normalmente, este erro é inofensivo se ocorrer apenas de forma intermitente. No entanto, considere processar as exceções corretamente no código Source.split.

Erros do conetor do BigQuery

As secções seguintes contêm erros comuns do conetor do BigQuery que pode encontrar, bem como passos para resolver ou solucionar os erros.

quotaExceeded

Quando usa o conetor do BigQuery para escrever no BigQuery através de inserções de streaming, a taxa de transferência de escrita é inferior à esperada e pode ocorrer o seguinte erro:

quotaExceeded

O débito lento pode dever-se ao facto de o seu pipeline exceder a quota de inserção de streaming do BigQuery disponível. Se for o caso, as mensagens de erro relacionadas com a quota do BigQuery aparecem nos registos do worker do Dataflow (procure erros quotaExceeded).

Se vir erros quotaExceeded, para resolver este problema:

• Quando usar o SDK do Apache Beam para Java, defina a opção de destino do BigQuery ignoreInsertIds().
• Quando usar o SDK do Apache Beam para Python, use a opção ignore_insert_ids.

Estas definições tornam-no elegível para uma taxa de transferência de inserção de streaming do BigQuery de 1 GB por segundo e por projeto. Para mais informações sobre ressalvas relacionadas com a deduplicação automática de mensagens, consulte a documentação do BigQuery. Para aumentar a quota de inserção por streaming do BigQuery para mais de 1 GBps, envie um pedido através da Google Cloud consola.

Se não vir erros relacionados com a quota nos registos do trabalhador, o problema pode ser que os parâmetros relacionados com o agrupamento ou o processamento em lote predefinidos não ofereçam paralelismo adequado para a sua pipeline ser dimensionada. Pode ajustar várias configurações relacionadas com o conetor do BigQuery do Dataflow para alcançar o desempenho esperado ao escrever no BigQuery através de inserções de streaming. Por exemplo, para o Apache Beam SDK para Java, ajuste numStreamingKeys de modo a corresponder ao número máximo de trabalhadores e considere aumentar insertBundleParallelism para configurar o conetor do BigQuery de modo a escrever no BigQuery usando mais threads paralelos.

Para ver as configurações disponíveis no SDK do Apache Beam para Java, consulte o artigo BigQueryPipelineOptions. Para ver as configurações disponíveis no SDK do Apache Beam para Python, consulte a transformação WriteToBigQuery.

rateLimitExceeded

Quando usa o conetor do BigQuery, ocorre o seguinte erro:

rateLimitExceeded

Este erro ocorre se forem enviados demasiados pedidos de API do BigQuery durante um curto período. O BigQuery tem limites de quota a curto prazo. É possível que o seu pipeline do Dataflow exceda temporariamente essa quota. Neste cenário, os pedidos API da sua pipeline do Dataflow para o BigQuery podem falhar, o que pode resultar em erros rateLimitExceeded nos registos do trabalhador.

O Dataflow tenta novamente essas falhas, pelo que pode ignorar estes erros em segurança. Se considerar que o seu pipeline é afetado por erros rateLimitExceeded, contacte o apoio técnico do Google Cloud.

Erros diversos

As secções seguintes contêm erros diversos que pode encontrar e passos para resolver ou solucionar os erros.

Não é possível atribuir sha384

A tarefa é executada corretamente, mas vê o seguinte erro nos registos de tarefas:

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

Se a tarefa for executada corretamente, este erro é benigno e pode ignorá-lo. Por vezes, as imagens base da VM de trabalho produzem esta mensagem. O Dataflow responde automaticamente e resolve o problema subjacente.

Existe um pedido de funcionalidade para alterar o nível desta mensagem de WARN para INFO. Para mais informações, consulte o artigo Reduzir o nível do registo de erros de lançamento do sistema do Dataflow para WARN ou INFO.

Erro ao inicializar o verificador de plug-ins dinâmicos

A tarefa é executada corretamente, mas vê o seguinte erro nos registos de tarefas:

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

Se a tarefa for executada corretamente, este erro é benigno e pode ignorá-lo. Este erro ocorre quando a tarefa do Dataflow tenta criar um diretório sem as autorizações de escrita necessárias e a tarefa falha. Se a tarefa for bem-sucedida, significa que o diretório não era necessário ou que o Dataflow resolveu o problema subjacente.

Existe um pedido de funcionalidade para alterar o nível desta mensagem de WARN para INFO. Para mais informações, consulte o artigo Reduzir o nível do registo de erros de lançamento do sistema do Dataflow para WARN ou INFO.

Objeto inexistente: pipeline.pb

Quando lista trabalhos através da opção JOB_VIEW_ALL, ocorre o seguinte erro:

No such object: BUCKET_NAME/PATH/pipeline.pb

Este erro pode ocorrer se eliminar o ficheiro pipeline.pb dos ficheiros de preparação para a tarefa.

Ignorar a sincronização de pods

A tarefa é executada corretamente, mas vê um dos seguintes erros nos registos de tarefas:

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

Ou:

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

Se a tarefa for executada corretamente, estes erros são benignos e pode ignorá-los. A mensagem container runtime status check may not have completed yet ocorre quando o kubelet do Kubernetes está a ignorar a sincronização de pods porque está à espera que o tempo de execução do contentor seja inicializado. Este cenário ocorre por vários motivos, como quando o tempo de execução do contentor foi iniciado recentemente ou está a ser reiniciado.

Quando a mensagem inclui PLEG is not healthy: pleg has yet to be successful, o kubelet está a aguardar que o gerador de eventos do ciclo de vida do pod (PLEG) fique em bom estado antes de sincronizar os pods. O PLEG é responsável por gerar eventos que são usados pelo kubelet para acompanhar o estado dos pods.

Existe um pedido de funcionalidade para alterar o nível desta mensagem de WARN para INFO. Para mais informações, consulte o artigo Reduzir o nível do registo de erros de lançamento do sistema do Dataflow para WARN ou INFO.

Recomendações

Para orientações sobre as recomendações geradas pelas estatísticas do Dataflow, consulte o artigo Estatísticas.