Orientação sobre erros comuns

Nesta página, você verá alguns erros comuns que talvez ocorram ao executar o job do Dataflow e algumas sugestões de ações para lidar com esses erros.

Erros de falta de recursos:

Mensagens do job:

Erros de envio de job:

Registros de worker:

Erros de entrada e saída:

Erros de inicialização do worker:

Registros:

Recomendações:

Erros de falta de recursos

Como resolver erros de um pool de recursos esgotados

Às vezes, quando você cria um recurso do Google Cloud, pode ver um erro de um pool de recursos esgotado. Esse erro indica uma condição temporária de estoque para um recurso específico em uma zona específica. Este é o formato de mensagem:

ERROR: ZONE_RESOURCE_POOL_EXHAUSTED

Para resolver o problema, é possível aguardar um período ou criar o mesmo recurso em outra zona. Como prática recomendada, distribua seus recursos e várias zonas e regiões para tolerar interrupções.

Mensagens de job

The job failed because a work item failed 4 times.

Se somente uma operação fizer com que o código do worker falhe quatro vezes, gerando uma exceção ou travamento, o Dataflow apresentará falha no job e a mensagem a work item failed 4 times será exibida. Não é possível configurar esse limite de falhas. Para mais detalhes, consulte como lidar com erros e exceções de pipeline.

Faça uma busca nos registros do job no Cloud Monitoring pelas quatro falhas individuais. Busque entradas de registro de Nível de erro ou Nível fatal nos registros de worker que mostram exceções ou erros. Você verá pelo menos quatro dessas exceções ou erros.

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

Os SDKs do Apache Beam e os workers do Dataflow dependem de componentes comuns de terceiros. Esses componentes importam mais dependências. Os conflitos de versão podem resultar em um comportamento inesperado no serviço. Se você estiver usando qualquer um desses pacotes em seu código, esteja ciente de que algumas bibliotecas não são compatíveis com versões futuras. Talvez seja necessário marcar as versões listadas que estarão no escopo durante a execução. As dependências do SDK e do worker contêm uma lista com as dependências e as respectivas versões necessárias.

Jobs que eram executados sem problemas agora falham com Staged package...is inaccessible

  • Verifique se o bucket do Cloud Storage usado na preparação não tem configurações de TTL que possam excluir os pacotes preparados.
  • Verifique se a conta de serviço do controlador do projeto do Dataflow tem permissão para acessar o bucket do Cloud Storage usado na preparação. As falhas na permissão podem ocorrer por qualquer um dos seguintes motivos:

    • O bucket do Cloud Storage usado na preparação está presente em um projeto diferente.
    • O bucket do Cloud Storage usado na preparação foi migrado do acesso refinado para o acesso uniforme no nível do bucket. Devido à inconsistência entre as políticas de IAM e ACL, a migração do bucket de preparo para acesso uniforme no nível do bucket não permite ACLs para recursos do Cloud Storage, o que inclui as permissões mantidas pela conta de serviço do controlador do projeto do Dataflow no bucket de preparação.

Para mais informações, consulte Como acessar buckets do Cloud Storage em projetos do Google Cloud.

Tempo limite da pesquisa de modelo flexível

Seu job de modelo flexível pode retornar a seguinte mensagem de erro:

Timeout in polling result file: ${file_path}.
Service account: ${service_account_email}
Image URL: ${image_url}
Troubleshooting guide at https://cloud.google.com/dataflow/docs/guides/common-errors#timeout-polling

Isso pode ser devido aos seguintes motivos:

  1. A imagem base do Docker foi modificada.
  2. A conta de serviço que preenche ${service_account_email} não tem algumas permissões necessárias.
  3. O programa que cria o gráfico leva muito tempo para ser concluído.
  4. (Somente Python) Há um problema com o arquivo requirements.txt.
  5. Ocorreu um erro temporário.

Além de verificar registros de jobs e tentar novamente em caso de falhas temporárias, veja algumas outras etapas de solução de problemas.

Verificar o ponto de entrada do Docker

Esta etapa é para quem executa um modelo a partir de uma imagem do Docker personalizada em vez de usar um dos modelos fornecidos.

Verifique o ponto de entrada do contêiner usando o comando a seguir:

docker inspect $TEMPLATE_IMAGE

Você verá o seguinte:

Java

/opt/google/dataflow/java_template_launcher

Python

/opt/google/dataflow/python_template_launcher

Se você receber uma saída diferente, o ponto de entrada do contêiner do Docker será modificado. Restaure $TEMPLATE_IMAGE para o padrão.

Verificar as permissões da conta de serviço

Verifique se a conta de serviço mencionada na mensagem tem as seguintes permissões:

  • Ele precisa ler e gravar o caminho do Cloud Storage que preenche o ${file_path} na mensagem.
  • Ele precisa ler a imagem do Docker que preenche ${image_url} na mensagem.

Verificar se o programa tela de início falha ao sair

O programa que constrói o pipeline precisa terminar antes que ele possa ser iniciado. O erro de pesquisa pode indicar que demorou muito para isso.

Algumas coisas que você pode fazer para localizar a causa no código são:

  • Verifique os registros do job e veja se alguma operação parece demorar muito para ser concluída. Um exemplo seria uma solicitação de um recurso externo.
  • Verifique se nenhuma linha de execução está bloqueando a saída do programa. Alguns clientes podem criar as próprias linhas de execução e, se esses clientes não forem encerrados, o programa aguardará para sempre que essas linhas sejam mescladas.

Observe que os pipelines iniciados diretamente (sem usar um modelo) não têm essas limitações. Portanto, se o pipeline funcionou diretamente, mas falhou como modelo, essa pode ser a causa raiz.

(Somente Python) Remover o Apache Beam do arquivo de requisitos

Se o Dockerfile incluir um requirements.txt com apache-beam[gcp], você precisa removê-lo do arquivo e instalá-lo separadamente. Exemplo:

RUN pip install apache-beam[gcp]
RUN pip install -U -r ./requirements.txt

Colocar o Beam no arquivo de requisitos é conhecido por levar a longos tempos de inicialização e geralmente causa um tempo limite.

O job de modelo flexível em filas do Python atinge o tempo limite

Se você estiver executando um job do Dataflow usando Flex Template e Python, o job poderá ficar na fila por um período e depois falhar na execução. Uma mensagem de erro Timeout in polling é exibida.

O erro se deve ao arquivo requirements.txt usado para instalar as dependências necessárias. Quando você inicia um job do Dataflow, todas as dependências são preparadas primeiro para tornar esses arquivos acessíveis às VMs do worker. O processo envolve o download e a recompilação de cada dependência direta e indireta no arquivo requirements.txt. Algumas dependências podem levar vários minutos para serem compiladas, especialmente PyArrow, que é uma dependência indireta usada pelo Apache Beam e pela maioria das bibliotecas de cliente do Google Cloud.

Como solução alternativa, execute as seguintes etapas:

  1. Faça o download das dependências pré-compiladas no Dockerfile para o diretório de preparo do Dataflow.

  2. Defina a variável de ambiente PIP_NO_DEPS como True.

    A configuração impede que o pip faça novamente o download e a recompilação de todas as dependências, o que ajuda a evitar o erro de tempo limite.

Veja a seguir um exemplo de código que mostra como as dependências são pré-carregadas.

# Copyright 2020 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#    http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

FROM gcr.io/dataflow-templates-base/python3-template-launcher-base

ENV FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE="/template/requirements.txt"
ENV FLEX_TEMPLATE_PYTHON_PY_FILE="/template/streaming_beam.py"

COPY . /template

# We could get rid of installing libffi-dev and git, or we could leave them.
RUN apt-get update \
    && apt-get install -y libffi-dev git \
    && rm -rf /var/lib/apt/lists/* \
    # Upgrade pip and install the requirements.
    && pip install --no-cache-dir --upgrade pip \
    && pip install --no-cache-dir -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE \
    # Download the requirements to speed up launching the Dataflow job.
    && pip download --no-cache-dir --dest /tmp/dataflow-requirements-cache -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE

# Since we already downloaded all the dependencies, there's no need to rebuild everything.
ENV PIP_NO_DEPS=True

Erros de envio de job

413 Request Entity Too Large/The size of serialized JSON representation of the pipeline exceeds the allowable limit

Se você se deparar com um erro do payload do JSON ao enviar o job, significa que a representação JSON do pipeline excede o tamanho máximo da solicitação, que é 20 MB. Esses erros podem aparecer como uma destas mensagens no console ou na janela de terminal:

  • 413 Request Entity Too Large
  • "O tamanho da representação JSON serializada do pipeline excede o limite permitido"
  • "Falha ao criar um job de fluxo de trabalho. Payload do JSON inválida"
  • "Falha ao criar um job de fluxo de trabalho. Payload de solicitação excede o limite permitido"

O tamanho do job está associado especificamente à representação JSON do pipeline. Um pipeline grande significa uma solicitação maior. Atualmente, a limitação do Dataflow restringe as solicitações a 20 MB.

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

Java

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

Esse comando grava uma representação JSON do job em um arquivo. O tamanho do arquivo serializado é uma boa estimativa do tamanho da solicitação. O tamanho real é um pouco maior em função de algumas informações extras incluídas na solicitação.

Certas condições no pipeline podem fazer com que a representação JSON exceda o limite. As condições mais comuns são as seguintes:

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

Para evitar essas condições, reestruture seu pipeline.

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

O tamanho do gráfico do job não pode exceder 10 MB. Determinadas condições no pipeline podem fazer com que o gráfico do job exceda o limite. As condições mais comuns são as seguintes:

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

Para evitar essas condições, reestruture seu pipeline.

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

Esse erro pode ser gerado em caso de leitura de um número muito grande de arquivos por meio de TextIO, AvroIO ou alguma outra fonte baseada em arquivo. O limite específico depende dos detalhes da fonte (por exemplo, o esquema de incorporação em AvroIO.Read permitirá menos arquivos), mas é aproximadamente de dezenas de milhares de arquivos em um pipeline.

Esse erro também poderá ocorrer se você tiver criado uma fonte de dados personalizada para o pipeline e o método splitIntoBundles dela retornar uma lista de objetos BoundedSource que ocupam mais de 20 MB quando serializados.

O limite permitido de tamanho total dos objetos BoundedSource gerados pela operação splitIntoBundles() da fonte personalizada é de 20 MB. Para contornar essa limitação, modifique sua subclasse BoundedSource personalizada para que o tamanho total dos objetos BoundedSource gerados seja menor que o limite de 20 MB. Por exemplo, a fonte pode gerar menos divisões inicialmente e contar com o Reequilíbrio dinâmico de trabalho para dividir ainda mais entradas sob demanda.

"As opções de pipeline do SDK ou a lista de arquivos de preparo excedem o limite de tamanho. Mantenha o tamanho deles com menos de 256 mil bytes e 512 mil bytes no total."

Não foi possível iniciar o pipeline porque os limites de metadados do Google Compute Engine foram excedidos. Não é possível alterar esses limites. O Dataflow usa os metadados do Compute Engine para as opções de pipeline. Esse limite está documentado nas limitações de metadados personalizados do Compute Engine.

O excesso de arquivos jar no cenário pode fazer com que a representação JSON exceda o limite.

Como encontrar a opção de pipeline completa e o tamanho dela? Para estimar o tamanho da solicitação JSON do pipeline, execute-o com a seguinte opção:

Java

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

O tamanho do arquivo de saída acima é inferior a 256 mil bytes. Há 512 mil bytes na mensagem de erro referente ao tamanho total do arquivo de saída acima e às opções de metadados personalizados para a instância de VM do Compute Engine. É possível determinar uma estimativa aproximada da opção de metadados personalizados para a instância de VM na execução de jobs do Dataflow no projeto. Escolha qualquer job do Dataflow em execução, use uma instância de VM e navegue até a página de detalhes da instância de VM do Compute Engine para verificar a seção de metadados personalizados. O tamanho total dos metadados personalizados e o arquivo acima precisa ser inferior a 512 mil bytes. Não é possível fazer uma estimativa precisa do job com falha, já que as VMs desse job não foram geradas.

Se a lista de jar estiver atingindo o limite de 256 mil bytes, revise-a e reduza os jars desnecessários. Se ainda for muito grande, tente executar o job do Dataflow usando um uber jar.

A seção de função do Cloud da documentação tem um exemplo de como criar e usar uber jar.

Startup of the worker pool in zone $ZONE failed to bring up any of the desired $N 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.

Esse erro tem duas causas possíveis:

  • Talvez você tenha excedido uma das cotas do Compute Engine necessárias para a criação do worker do Dataflow.
  • Sua organização tem restrições que proíbem algum aspecto do processo de criação da instância de VM, como a conta em uso ou a zona segmentada.

Para solucionar esse problema, siga estas instruções:

Revise o registro da instância de VM

  1. Acesse o Visualizador de registros do Cloud.
  2. Na lista suspensa Recurso auditado, selecione Instância da VM.
  3. Na lista suspensa Todos os registros, selecione compute.googleapis.com/activity_log.
  4. Verifique se há entradas no registro relacionadas à falha na criação da instância de VM.

Verificar o uso das cotas do Compute Engine

  1. Na linha de comando da máquina local ou no Cloud Shell, execute o seguinte comando para ver o uso de recursos do Compute Engine em comparação com as cotas do Dataflow para a zona que você está segmentando:

    gcloud compute regions describe [REGION]

  2. Analise os resultados dos seguintes recursos para ver se algum deles excede a cota:

    • CPUS
    • DISKS_TOTAL_GB
    • IN_USE_ADDRESSES
    • INSTANCE_GROUPS
    • INSTANCE_GROUP_MANAGERS
    • INSTANCES
  3. Se for necessário, solicite uma alteração de cota.

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

  1. Acesse a página Políticas da organização
  2. Analise as restrições que podem limitar a criação de instâncias de VM para a conta que você está usando (por exemplo, a conta de serviço do Dataflow) ou para a zona que você está segmentando.

Registros de workers

"Processamento parado/operação em andamento na etapa <step_id> por pelo menos <time_interval> sem resultado ou conclusão no estado final em <stack_trace>"

Se o Dataflow passar mais tempo executando um DoFn do que o tempo especificado em <time_interval> sem retorno, essa mensagem será exibida.

Esse erro tem duas causas possíveis:

  • O código DoFn é simplesmente lento ou está aguardando que alguma operação externa lenta seja concluída.
  • O código DoFn pode estar travado, entrou em um impasse ou apresenta uma lentidão anormal para concluir o processamento.

Para determinar qual é o caso, amplie a entrada de registro do Cloud Monitoring para ver um stack trace. Procure mensagens que indiquem que o código DoFn está travado ou encontrando problemas. Se nenhuma estiver presente, o problema pode ser a velocidade de execução do código DoFn. Considere usar o Cloud Profiler ou outra ferramenta para investigar o desempenho do código.

É possível investigar mais a fundo a causa do código travado se o seu pipeline foi criado na VM do Java (usando Java ou Scala). Para isso, consiga um despejo completo da JVM (não apenas da linha de execução travada) ao seguir estas instruções:

  1. Anote o nome do worker na entrada de registro.
  2. Na seção Compute Engine do Console do Cloud, encontre a instância do Compute Engine com o nome do worker que você anotou.
  3. Conecte à instância com esse nome por SSH.
  4. Execute este comando:

    curl http://localhost:8081/threadz
    

Exceções de chave de embaralhamento muito grande

Se você encontrar exceções indicando que a chave de embaralhamento é muito grande, significa que a chave serializada emitida para um determinado (Co-)GroupByKey, depois que o codificador correspondente foi aplicado, é muito grande. O Dataflow tem um limite de chaves de embaralhamento serializadas. Considere reduzir o tamanho das chaves ou usar codificadores mais eficientes em termos de espaço.

KeyCommitTooLargeException

Em cenários de streaming, isso pode ser causado pelo agrupamento de uma grande quantidade de dados sem usar uma transformação Combine ou pela produção de uma grande quantidade de dados de um único elemento de entrada. As estratégias a seguir podem reduzir a chance de gerar essa exceção:

  • Garante que o processamento de um único elemento não possa resultar em saídas ou modificações de estado acima do limite.
  • Se vários elementos foram agrupados por uma chave, considere aumentar o espaço para reduzir os elementos agrupados por chave.
  • Se os elementos de uma chave forem emitidos em uma frequência alta durante um curto período, isso pode resultar em muitos GB de eventos para essa chave nas janelas. Reescreva o pipeline para detectar chaves como essa e apenas emita uma saída indicando que a chave estava presente com frequência naquela janela.
  • Certifique-se de usar transformações Combine de espaço sublinear para operações combináveis e associadas. Não use um combinador se ele não reduzir o espaço. Por exemplo, usar um combinador para strings que apenas anexa strings é pior do que não usar o combinador.

Exceções de tempo limite de RPC, exceções DEADLINE_EXCEEDED ou erros Server Unresponsive

Se ocorrerem tempos limites de RPC, exceções de DEADLINE_EXCEEDED ou erros de Server Unresponsive durante a execução do job, eles geralmente indicam um dos dois problemas:

  • A rede VPC usada para o job pode estar sem uma regra de firewall. A regra de firewall precisa permitir todo o tráfego TCP entre as VMs na rede VPC que você especificou nas opções do pipeline. Consulte Como especificar rede e sub-rede para mais detalhes.

  • O job está vinculado à reprodução aleatória. Realize uma das ações a seguir ou uma combinação delas:

    Java

    • Se o job não estiver usando o Shuffle baseado em serviço, mude para o uso do Dataflow Shuffle baseado em serviço definindo --experiments=shuffle_mode=service. Para detalhes e disponibilidade, leia Dataflow Shuffle.
    • Adicione mais workers. Defina --numWorkers com um valor mais alto ao executar o pipeline.
    • Aumente o tamanho do disco anexado para os workers. Defina --diskSizeGb com um valor mais alto ao executar o pipeline.
    • Use um disco permanente com SSD. Defina --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" ao executar o pipeline.

    Python

    • Se o job não estiver usando o Shuffle baseado em serviço, mude para o uso do Dataflow Shuffle baseado em serviço definindo --experiments=shuffle_mode=service. Para detalhes e disponibilidade, leia Dataflow Shuffle.
    • Adicione mais workers. Defina --num_workers com um valor mais alto ao executar o pipeline.
    • Aumente o tamanho do disco anexado para os workers. Defina --disk_size_gb com um valor mais alto ao executar o pipeline.
    • Use um disco permanente com SSD. Defina --worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" ao executar o pipeline.

Uma chamada do agente de worker em Java para uma DoFn do Python falhou apresentando o erro <error message>

Se uma DoFn implementada no Python falhar e gerar uma exceção, uma mensagem de erro pertinente será exibida.

Expanda a entrada de registro de erros do Cloud Monitoring e procure a mensagem e o traceback. Ele mostra qual código falhou para que você possa corrigi-lo se necessário. Se você acredita que isso é um bug no Apache Beam ou no Dataflow, informe o bug.

Não há espaço livre no dispositivo

Quando um job ficar sem espaço em disco, você poderá ver erros de No space left on device nos registros do worker.

Se um job faz o download de grandes dependências no tempo de execução, usa grandes contêineres personalizados ou grava muitos dados temporários no disco local, o armazenamento permanente do worker pode ficar sem espaço livre.

Ao usar o Dataflow Shuffle, o Dataflow define um tamanho de disco padrão menor. Como resultado, os jobs que estão sendo transferidos de embaralhados baseados no worker também poderão apresentar esse erro.

Também será possível que o disco de inicialização do worker seja preenchido se estiver registrando mais de 50 entradas por segundo.

Para ver os recursos de disco associados a um único worker, procure detalhes de instâncias de VM para VMs de worker associadas ao job. Parte do espaço em disco será consumida pelo sistema operacional, binários, registros e contêineres.

Para aumentar o espaço do disco permanente ou do disco de inicialização, ajuste a opção de pipeline do tamanho do disco.

É possível acompanhar o uso do espaço em disco nas instâncias de VM de worker usando o Cloud Monitoring. Consulte Receber métricas de VMs de workers do agente do Monitoring para ver instruções sobre como configurar isso.

Também é possível procurar problemas de espaço em disco de inicialização ao visualizar a saída da porta serial nas instâncias de VM de worker e ao procurar mensagens como "Falha ao abrir o diário do sistema: sem espaço no dispositivo". Se você tiver um grande número de instâncias de VM de worker, crie um script para executar gcloud compute instances get-serial-port-output em todas elas de uma só vez e analisar a saída.

Para mais informações, consulte Recursos do disco permanente.

EOFError: dados de marshal muito curtos

Esse erro às vezes acontece quando os workers do pipeline do Python ficam sem espaço em disco. Consulte Não há espaço disponível no dispositivo.

Avisos de Bad request nos registros do shuffler

Durante a execução de um job do Dataflow, os registros do Cloud Monitoring podem exibir uma série de avisos semelhantes a:

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 "solicitação inválida" aparecem porque as informações de estado do worker estão desatualizadas ou fora de sincronia devido a atrasos no processamento. Geralmente, seu job do Dataflow será bem-sucedido mesmo com esses avisos. Se esse for o caso, ignore-os.

Uma chave com uso intenso <hot-key-name> foi detectada em...

Esses erros identificam uma chave com uso intenso nos seus dados Uma chave com uso intenso é uma chave com elementos suficientes para afetar negativamente o desempenho do pipeline. Essas chaves limitam a capacidade do Dataflow de processar elementos em paralelo, o que aumenta o tempo de execução.

Para registrar a presença de uma chave com uso intenso, use a opção de canal de chave com uso intenso.

Verifique se seus dados estão distribuídos de maneira uniforme. Se uma chave tiver muitos valores de forma desproporcional, realize uma das ações a seguir:

O pipeline do contêiner personalizado do Python falha com SystemError: código de operação desconhecido

Se você encontrar um erro inesperado de SystemError: unknown opcode no Python imediatamente após o envio do job e o stack trace incluir apache_beam/internal/pickler.py, verifique se a versão do Python que você está usando localmente corresponde à versão no contêiner imagem para as versões principal e secundária. A diferença na versão do patch, como 3.6.7 versus 3.6.8, não cria problemas de compatibilidade, mas a diferença na versão secundária, como 3.6.8 versus 3.8.2, pode causar falhas no pipeline.

Erros de entrada e saída

Os gráficos de métricas de E/S usam códigos de erro canônicos. Se esses códigos de erro persistirem nas suas origens e coletores, consulte a lista a seguir para ver as possíveis causas e medidas que você pode tomar.

  • RESOURCE_EXHAUSTED: o projeto pode ter ficado sem cota de recursos para o serviço que a origem ou o coletor está usando.

    Se o erro ocorre de vez em quando ou o gráfico de solicitações por segundo indica um grande volume de solicitações, isso pode indicar que você atingiu uma cota de limitação de taxa de API e precisa para aumentar a cota.

  • DEADLINE_EXCEEDED. A fonte ou o coletor pode ter expirado o tempo de leitura ou gravação de um grande lote de dados. Verifique o gráfico de latência e os registros dos workers. Se o erro persistir, entre em contato com a equipe de suporte.

  • INVALID_ARGUMENT: os parâmetros especificados para a origem ou o coletor podem estar malformados (como um tópico do Pub/Sub). Verifique a configuração da origem ou do coletor e confira os registros do worker.

  • FAILED_PRECONDITION: verifique a configuração da origem ou do coletor e confira os registros do worker. Isso também pode indicar um bug.

  • OUT_OF_RANGE: verifique se o recurso que está sendo usado pela origem ou o coletor existe (como um tópico ou uma assinatura do Pub/Sub).

  • UNAUTHENTICATED. Verifique se a conta de serviço do Dataflow tem permissões de gerenciamento de identidade e acesso para o serviço específico e se as APIs relevantes estão ativadas para o projeto.

  • PERMISSION_DENIED. Verifique se a conta de serviço do Dataflow tem permissões de gerenciamento de identidade e acesso para o serviço específico e se as APIs relevantes estão ativadas para o projeto.

  • NOT_FOUND: verifique se as entidades usadas pela origem ou o coletor existem (como um tópico ou uma assinatura do Pub/Sub).

  • ABORTED: o serviço pode não estar lidando corretamente com as tentativas de leitura ou gravação de dados feitas pela origem ou os coletores. Se o erro persistir, entre em contato com a equipe de suporte.

  • ALREADY_EXISTS: a E/S pode estar tentando criar uma entidade que já existe (como um tópico ou uma assinatura do Pub/Sub). Se o erro persistir, entre em contato com a equipe de suporte.

  • CANCELLED: isso pode ocorrer quando um worker do Dataflow é encerrado ou quando a lógica da origem ou do coletor decide intencionalmente cancelar tentativas de leitura ou gravação de dados.

  • DATALOSS: indica que os dados foram corrompidos ou perdidos de maneira irrecuperável. É uma boa ideia criar um novo conjunto de dados para suas origens e executar novamente o job do Dataflow.

    Também é recomendável ver se há instruções de backup e restauração disponíveis para o serviço básico do Google Cloud.

  • UNKNOWN: o serviço pode estar fora do ar. Verifique se há atualizações no Painel de status do Cloud para mais informações.

  • INTERNAL: o serviço pode estar fora do ar. Verifique se há atualizações no Painel de status do Cloud para mais informações.

  • UNAVAILABLE: o serviço pode estar fora do ar. Verifique se há atualizações no Painel de status do Cloud para mais informações.

  • UNIMPLEMENTED: a origem ou o coletor tentou usar o serviço de maneira inválida. O pipeline pode estar configurado incorretamente. Se o erro persistir, entre em contato com a equipe de suporte.

Erros de inicialização do worker

Erros nos tipos de registro dataflow.googleapis.com/worker-startup, dataflow.googleapis.com/harness-startup e dataflow.googleapis.com/kubelet indicam problemas de configuração com um job. Elas também podem indicar condições que impedem o funcionamento normal do caminho de geração de registros.

Erros NoClassDefFound

Esses erros também podem estar no formato Unable to initialize main class [...]. Os erros NoClassDefFound indicam que os arquivos JAR que estão sendo enviados para o serviço Dataflow não contêm as classes necessárias para executar o Dataflow. Isso ocorre com mais frequência quando o --filesToStage PipelineOption é modificado e alguns arquivos JAR ou de classe necessários são omitidos.

Falha na solicitação de envio de imagem com erro

Esse erro indica que um worker não pôde ser iniciado porque não foi possível extrair uma imagem de contêiner do Docker. Isso pode acontecer se o URL da imagem do contêiner do SDK personalizado estiver incorreto ou se o worker não tiver credenciais ou acesso de rede à imagem remota.

Se você estiver usando uma imagem de contêiner personalizada com o job, verifique se o URL dela está correto, se tem uma tag ou um resumo válido e se a imagem pode ser acessada pelos workers do Dataflow.

Verifique se as imagens públicas podem ser extraídas localmente executando docker pull $image a partir de uma máquina não autenticada.

Há mais consideração para imagens ou workers particulares.

  • O Dataflow só é compatível com imagens de contêiner particulares hospedadas no Container Registry. Se você estiver usando o Container Registry para hospedar sua imagem de contêiner, a conta de serviço padrão do Google Cloud terá acesso a imagens no mesmo projeto. Se você estiver usando imagens em um projeto diferente daquele usado para executar seu job do Google Cloud, configure o controle de acesso para a conta de serviço padrão do Google Cloud.
  • Se estiver usando uma nuvem privada virtual (VPC) compartilhada, verifique se os workers podem acessar o host do repositório de contêineres personalizado.
  • Use ssh para se conectar a uma VM de worker de jobs e execute docker pull $image para confirmar diretamente que ele está configurado corretamente.

Se os workers falharem várias vezes seguidas devido a esse erro e nenhum trabalho for iniciado em um job, ele falhará com um erro como Job appears to be stuck. .... Se você tiver removido o acesso à imagem durante a execução do job, seja removendo a própria imagem ou revogando as credenciais da conta de serviço do worker do Dataflow ou o acesso à Internet para acessar as imagens, o Dataflow só registrará erros e não executar ações para falhar no job. O Dataflow também evita a falha de pipelines de streaming de longa duração para evitar a perda do estado do pipeline.

Outros possíveis erros podem surgir de problemas de cota do repositório ou interrupções. Se você tiver problemas em exceder a cota do Docker Hub para extrair imagens públicas ou interrupções gerais do repositório de terceiros, considere o uso do Container Registry como repositório de imagens.

Erro ao sincronizar o pod ... falha ao usar "StartContainer"

Esse erro indica que o contêiner do worker do Docker não foi iniciado. Isso geralmente acontece quando um dos contêineres está falhando continuamente na inicialização.

Se o contêiner falhar, procure uma mensagem de erro descrevendo a falha nos registros do worker, a inicialização ou o docker. Uma falha comum de inicialização para jobs em Python são erros de instalação pip (pip install failed with error...) devido a problemas de dependência. Eles podem incluir dependências especificadas incompatíveis ou problemas de rede que tornam os repositórios especificados inacessíveis. O SDK do Apache Beam para Python no contêiner precisa ser o mesmo usado no SDK para iniciar o job.

Esse erro também poderá ocorrer se a imagem do contêiner não puder ser extraída durante um job de longa duração. Para mais detalhes, leia "Falha na solicitação de extração de imagem com erro".

"Um erro fatal foi detectado pelo Java Runtime Environment"

Isso indica que o pipeline está usando a Java Native Interface (JNI) para executar código não Java e que há um erro nesse código ou nas vinculações do JNI.

O pipeline de contêiner personalizado falha ou apresenta lentidão para iniciar os workers

Um problema conhecido pode fazer o Dataflow marcar os workers como sem resposta e reiniciá-los se estiverem usando um contêiner personalizado muito grande (aproximadamente 10 GB) e o download leva muito tempo. Isso pode tornar a inicialização do pipeline lenta ou, em alguns casos extremos, impedir que os workers sejam iniciados.

Para verificar isso, procure registros de workers no dataflow.googleapis.com/kubelet que mostram várias tentativas de extrair um contêiner que não funciona e que o kubelet não inicia no worker, por exemplo, registros como Pulling image <URL> sem uma correspondência de registros Successfully pulled image <URL> ou Started Start kubelet depois de extrair todas as imagens.

Uma solução para esse problema é executar o pipeline com a opção de pipeline --experiments=disable_worker_container_image_prepull.

Registros

Não vejo nenhum registro

Se você não vir registros para seus jobs, remova todos os filtros de exclusão que contenham resource.type="dataflow_step" de todos os coletores do Roteador de registros do Cloud Logging.

Acessar o roteador de registros

Para mais detalhes sobre como remover suas exclusões de registros, consulte o guia Como remover exclusões.

Recomendações

Alto uso da cota de transferência do Streaming Engine

Os jobs que usam o Streaming Engine têm um limite regional para a quantidade de dados que podem ser transferidos de/para o Streaming Engine. É importante permanecer abaixo do limite, uma vez que alcançá-lo pode afetar o desempenho do job. Além disso, reduzir a quantidade de bytes transferidos pode reduzir o custo faturado.

Para ver o limite do seu projeto, consulte as instruções em Cotas e limites. Para visualizar o uso atual dos jobs, siga este link para o Metrics Explorer. Se necessário, selecione o projeto em que o job está em execução. Em seguida, substitua REGION pela região do seu interesse e clique em "Executar consulta".

Sugestões para reduzir o uso:

  • Reduza a quantidade de dados processados pelas transformações GroupByKey e Combine. Isso pode ser feito reduzindo o número de elementos transmitidos ou omitindo campos desnecessários.
  • Codifique dados com mais eficiência para ocupar menos espaço. Em alguns casos, isso pode aumentar o uso da CPU no worker.

    • Para tipos de dados personalizados, o codificador padrão pode ser ineficiente (SerializableCoder em Java, PickleCoder em Python). Tente selecionar um codificador padrão mais eficiente para o tipo personalizado ou uma PCollection com um esquema.

      Para ver uma explicação mais detalhada sobre os codificadores e como especificá-los, consulte o capítulo do Guia de programação do Beam sobre codificação de dados. Para saber mais sobre o PCollections com esquemas, consulte o capítulo sobre esquemas.

    • Para elementos grandes, aplicar a compactação pode ajudar.

  • Reduza grandes leituras de estado. Por exemplo, um pipeline que tenha um BagState grande o suficiente precisará transferi-lo do Streaming Engine sempre que for buscado.

    • Tente reduzir o tamanho do estado.
    • Tente reduzir a frequência das buscas de estado.
    • O estado está vinculado a uma chave e janela específicas. É possível usar de janelas não globais para limitar o tamanho do estado.

    Para saber mais sobre o estado, consulte o capítulo do Guia de programação do Beam sobre estado e timers.

Escalonamento automático: maxNumWorkers pode ser aumentado

O Dataflow detectou que um job está usando o número máximo de workers permitidos, maxNumWorkers (ou max_num_workers) e que pode utilizar mais workers se esse valor máximo foi aumentado. Por exemplo, essa recomendação seria feita para um job que tenha maxNumWorkers definido como 50 e esteja usando 50 workers com uma utilização média da CPU do worker acima de 80%.

Normalmente, o aumento de maxNumWorkers aumenta a capacidade do pipeline: um pipeline em lote pode ser concluído em menos tempo, e um pipeline de streaming pode gerenciar picos maiores de dados e processar mais elementos por segundo. No entanto, isso pode aumentar o custo (consulte Preços dos recursos do worker). Consulte o Guia de escalonamento automático para ver detalhes sobre como o algoritmo de escalonamento automático funciona e como configurá-lo.

Sugestões:

  • Tente aumentar a opção de pipeline maxNumWorkers ou removê-la. Sem a opção, o Dataflow usará os padrões listados no Guia de escalonamento automático.
  • Não há problema em não fazer nada se o desempenho do pipeline for adequado.
    • Para pipelines em lote, verifique se o tempo total de execução atende aos seus requisitos.
    • Para pipelines de streaming, verifique o gráfico de atualização de dados na guia "Métricas do job" na página do job. Verifique se ele não aumenta continuamente e se os valores estão dentro dos limites aceitáveis.

Alta distribuição de dados detectada.

O Dataflow detectou que um job tem uma ou mais transformações com um fan-out. Isso ocorre quando um ParDo com uma alta proporção de contagem de elementos de saída para entrada é mesclado com um ParDo subsequente. Nessa situação, a segunda ParDo é executada sequencialmente com a primeira. Isso força todos os elementos de saída de uma determinada entrada no mesmo worker, reduzindo o paralelismo e diminuindo o desempenho.

Sugestões:

  • Insira um GroupByKey e desagrupe após o primeiro ParDo. O serviço Dataflow nunca funde operações ParDo em uma agregação.
  • Transmita a PCollection intermediária como uma entrada secundária para outro ParDo. O serviço Dataflow sempre materializa entradas secundárias.
  • Insira uma etapa de ordem aleatória. A realocação evita a fusão, verifica os dados e reconfigura a estratégia de gestão de janelas para que nenhum dado seja descartado. A reordenação é compatível com o Dataflow, mesmo que esteja marcada como obsoleta na documentação do Apache Beam. Lembre-se que o embaralhamento dos dados pode aumentar o custo de execução do pipeline.