Airflow gerenciado (geração 3) | Airflow gerenciado (geração 2) | Airflow gerenciado (geração 1 legada)
Nesta página, listamos os problemas conhecidos do Airflow Gerenciado. Para informações sobre correções de problemas, consulte as Notas da versão.
Alguns problemas afetam versões anteriores e podem ser corrigidos fazendo upgrade do ambiente.
Os intervalos de endereços não RFC 1918 são parcialmente compatíveis com pods e serviços
O Airflow gerenciado depende do GKE para oferecer suporte a endereços não RFC 1918 para pods e serviços. Somente a seguinte lista de intervalos não RFC 1918 é compatível com o Airflow gerenciado:
- 100.64.0.0/10
- 192.0.0.0/24
- 192.0.2.0/24
- 192.88.99.0/24
- 198.18.0.0/15
- 198.51.100.0/24
- 203.0.113.0/24
- 240.0.0.0/4
Os rótulos de ambiente adicionados durante uma atualização não são totalmente propagados
Quando você atualiza os rótulos do ambiente, eles não são aplicados às VMs do Compute Engine no cluster do ambiente. Como solução alternativa, você pode aplicar os marcadores manualmente.
Não é possível criar ambientes do Airflow Gerenciado com as restrições da política da organização/compute.disableSerialPortLogging aplicadas
A criação do ambiente do Airflow Gerenciado vai falhar se
a política da organização constraints/compute.disableSerialPortLogging for
aplicada ao projeto de destino.
Diagnóstico
Para determinar se você foi afetado por esse problema, siga este procedimento:
Acesse o menu do GKE no console doGoogle Cloud . Acesse o menu do GKE
Em seguida, selecione o cluster recém-criado. Verifique o seguinte erro:
Not all instances running in IGM after 123.45s.
Expect <number of desired instances in IGM>. Current errors:
[CONDITION_NOT_MET]: Instance '<generated instance name>' creation failed:
Constraint constraints/compute.disableSerialPortLogging violated for
project <target project number>.
Alternativas:
Desative a política da organização no projeto em que o ambiente do Airflow Gerenciado será criado.
Uma política da organização sempre pode ser desativada para envolvidos no projeto, mesmo se os recursos pai (organização ou pasta) tiverem essa política ativada. Consulte a página Como personalizar políticas de restrições booleanas para mais detalhes.
Usar filtros de exclusão
Usar um filtro de exclusão para registros de porta serial tem a mesma meta que a desativação da política organizacional, já que haverá registros do console serial no Logging. Para mais detalhes, consulte a página Filtros de exclusão.
Uso do Deployment Manager para gerenciar recursos do Google Cloud protegidos pelo VPC Service Controls
As versões 2.0.x do Airflow Gerenciado (geração legada 1) e do Airflow Gerenciado (geração 2) usam o Deployment Manager para criar componentes de ambientes do Airflow Gerenciado.
Em dezembro de 2020, você pode ter recebido informações de que talvez seja necessário realizar outras configurações do VPC Service Controls para usar o Deployment Manager para gerenciar recursos protegidos pelo VPC Service Controls.
Gostaríamos de esclarecer que nenhuma ação é necessária da sua parte se você estiver usando o Airflow Gerenciado e não estiver usando o Deployment Manager diretamente para gerenciar os recursos do Google Cloud mencionados no comunicado do Deployment Manager.
O Deployment Manager exibe informações sobre um recurso incompatível
Talvez você veja o seguinte aviso na guia do Deployment Manager:
The deployment uses actions, which are an unsupported feature. We recommend
that you avoid using actions.
Para implantações do Deployment Manager que pertencem ao Airflow gerenciado, ignore esse aviso.
Não é possível excluir um ambiente depois que o cluster dele é excluído
Esse problema se aplica às versões 2.0.x do Airflow Gerenciado (geração 1 legada) e do Airflow Gerenciado (geração 2).
Se você excluir o cluster do GKE do ambiente antes do próprio ambiente, as tentativas de excluir o ambiente resultarão no seguinte erro:
Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]
Para excluir um ambiente quando o cluster já foi excluído:
No console do Google Cloud , acesse a página do Deployment Manager.
Encontre todas as implantações marcadas com rótulos:
goog-composer-environment:<environment-name>goog-composer-location:<environment-location>
Você verá duas implantações marcadas com os rótulos descritos:
- Uma implantação chamada
<environment-location>-<environment-name-prefix>-<hash>-sd - Uma implantação chamada
addons-<uuid>
Exclua manualmente os recursos que ainda estão listados nessas duas implantações e existem no projeto, como tópicos e assinaturas do Pub/Sub. Para fazer isso, siga estas etapas:
Selecione as implantações.
Clique em Excluir.
Selecione a opção Excluir 2 implantações e todos os recursos criados por elas, como VMs, balanceadores de carga e discos e clique em Excluir tudo.
A operação de exclusão falha, mas os recursos restantes são excluídos.
Exclua as implantações usando uma destas opções:
No console do Google Cloud , selecione as duas implantações novamente. Clique em Excluir e selecione a opção Excluir 2 implantações, mas manter os recursos criados por elas.
Execute um comando gcloud para excluir as implantações com a política
ABANDON:gcloud deployment-manager deployments delete addons-<uuid> \ --delete-policy=ABANDON gcloud deployment-manager deployments delete <location>-<env-name-prefix>-<hash>-sd \ --delete-policy=ABANDON
Avisos sobre entradas duplicadas da tarefa "echo" pertencente ao DAG "echo-airflow_monitoring"
Você talvez veja a seguinte entrada nos registros do Airflow:
in _query db.query(q) File "/opt/python3.6/lib/python3.6/site-packages/MySQLdb/
connections.py", line 280, in query _mysql.connection.query(self, query)
_mysql_exceptions.IntegrityError: (1062, "Duplicate entry
'echo-airflow_monitoring-2020-10-20 15:59:40.000000' for key 'PRIMARY'")
Ignore essas entradas de registro, porque esse erro não afeta o DAG do Airflow e o processamento de tarefas.
Estamos trabalhando para melhorar o serviço do Airflow gerenciado e remover esses avisos dos registros do Airflow.
A criação do ambiente falha em projetos com APIs do Identity-Aware Proxy adicionadas ao perímetro do VPC Service Controls
Em projetos com o VPC Service Controls ativado,
a conta cloud-airflow-prod@system.gserviceaccount.com requer acesso explícito
no perímetro de segurança para criar ambientes.
Para criar ambientes, use uma das seguintes soluções:
Não adicione a API Cloud Identity-Aware Proxy e a API Identity-Aware Proxy TCP ao perímetro de segurança.
Adicione a conta de serviço
cloud-airflow-prod@system.gserviceaccount.comcomo membro do perímetro de segurança usando a seguinte configuração no arquivo de condições YAML:- members: - serviceAccount:cloud-airflow-prod@system.gserviceaccount.com
A criação ou o upgrade do ambiente do Airflow gerenciado falha quando a política compute.vmExternalIpAccess está desativada
Esse problema se aplica aos ambientes do Airflow Gerenciado (geração 1 legada) e do Airflow Gerenciado (geração 2).
Os clusters do GKE de propriedade do Airflow gerenciado configurados no
modo de IP público exigem conectividade externa para as VMs. Por isso,
a política compute.vmExternalIpAccess não pode proibir a criação de VMs
com endereços IP externos. Para mais informações sobre essa política da organização, consulte Restrições da política da organização.
A primeira execução do DAG para um arquivo DAG enviado tem várias tarefas com falha
Quando você faz o upload de um arquivo DAG, às vezes as primeiras tarefas da primeira execução do DAG falham com o erro Unable to read remote log.... Esse problema ocorre porque o arquivo DAG é sincronizado entre o bucket do ambiente, os workers do Airflow e os programadores do Airflow do ambiente. Se o programador receber o arquivo DAG e programá-lo para ser executado
por um worker, e se o worker ainda não tiver o arquivo DAG, a execução da tarefa
vai falhar.
Para mitigar esse problema, os ambientes com o Airflow 2 são configurados para realizar duas novas tentativas para uma tarefa com falha por padrão. Se uma tarefa falhar, ela será repetida duas vezes com intervalos de 5 minutos.
Anúncios sobre a remoção do suporte para APIs Beta obsoletas das versões do GKE
O Airflow Gerenciado gerencia os clusters do GKE que pertencem a ele. A menos que você use explicitamente essas APIs nos DAGs e no código, ignore os avisos sobre as suspensões de uso da API GKE. O Airflow Gerenciado cuida de todas as migrações, se necessário.
O Airflow Gerenciado não deve ser afetado pela vulnerabilidade do Apache Log4j 2 (CVE-2021-44228)
Em resposta à vulnerabilidade do Apache Log4j 2 (CVE-2021-44228), o Airflow Gerenciado realizou uma investigação detalhada e acreditamos que ele não é vulnerável a essa exploração.
Os workers ou programadores do Airflow podem ter problemas ao acessar o bucket do Cloud Storage do ambiente
O Airflow Gerenciado usa o gcsfuse para acessar a pasta /data no bucket do ambiente e salvar os registros de tarefas do Airflow no diretório /logs (se ativado). Se o gcsfuse estiver sobrecarregado ou o bucket do ambiente estiver indisponível,
talvez ocorram falhas na instância de tarefa do Airflow e erros
Transport endpoint is not connected nos registros do Airflow.
Soluções:
- Desative o salvamento de registros no bucket do ambiente. Essa opção já está desativada por padrão se um ambiente for criado usando o Airflow Gerenciado 2.8.0 ou versões posteriores.
- Faça upgrade para o Airflow Gerenciado 2.8.0 ou uma versão mais recente.
- Reduza
[celery]worker_concurrencye aumente o número de workers do Airflow. - Reduza a quantidade de registros produzidos no código do DAG.
- Siga as recomendações e práticas recomendadas para implementar DAGs e ativar novas tentativas de tarefas.
Às vezes, a interface do Airflow pode não recarregar um plug-in depois que ele é alterado
Se um plug-in consistir em muitos arquivos que importam outros módulos, a interface do Airflow poderá não reconhecer que um plug-in precisa ser recarregado. Nesse caso, reinicie o servidor da Web do Airflow do seu ambiente.
O cluster do ambiente tem cargas de trabalho no estado Não programável
Esse problema conhecido se aplica apenas ao Airflow Gerenciado (2ª geração).
No Airflow Gerenciado (2ª geração), depois que um ambiente é criado, várias cargas de trabalho no cluster do ambiente permanecem no estado Não programável.
Quando um ambiente é escalonado verticalmente, novos pods de worker são criados e o Kubernetes tenta executá-los. Se não houver recursos livres disponíveis para executá-los, os pods de worker serão marcados como não programáveis.
Nessa situação, o escalonador automático de cluster adiciona mais nós, o que leva alguns minutos. Até que isso seja feito, os pods permanecem no estado Não programável e não executam nenhuma tarefa.
As cargas de trabalho do DaemonSet não programáveis chamadas composer-gcsfuse e
composer-fluentd que não podem ser iniciadas em nós em que os componentes do Airflow
não estão presentes não afetam seu ambiente.
Se o problema persistir por muito tempo (mais de uma hora), verifique os registros do escalonador automático de clusters. Eles podem ser encontrados no Visualizador de registros com o seguinte filtro:
resource.type="k8s_cluster"
logName="projects/<project-name>/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
resource.labels.cluster_name="<cluster-name>"
Ele contém informações sobre as decisões tomadas pelo escalonador automático de cluster: expanda qualquer noDecisionStatus para ver o motivo pelo qual o cluster não pode ser escalonado verticalmente ou horizontalmente.
Erro 504 ao acessar a interface do Airflow
Você pode receber o erro 504 Gateway Timeout ao acessar a interface do Airflow. Esse erro pode ter várias causas:
Problema de comunicação temporário. Nesse caso, tente acessar a interface do Airflow mais tarde. Também é possível reiniciar o servidor da Web do Airflow.
(Somente Airflow gerenciado (Geração 3)) Problema de conectividade. Se a interface do Airflow estiver permanentemente indisponível e erros de tempo limite ou 504 forem gerados, verifique se o ambiente pode acessar
*.composer.googleusercontent.com.(Somente Airflow gerenciado (Geração 2)) Problema de conectividade. Se a interface do Airflow estiver permanentemente indisponível e erros de tempo limite ou 504 forem gerados, verifique se o ambiente pode acessar
*.composer.cloud.google.com. Se você usa o Acesso privado do Google e envia tráfego por IPs virtuaisprivate.googleapis.comou o VPC Service Controls e envia tráfego por IPs virtuaisrestricted.googleapis.com, verifique se o Cloud DNS também está configurado para nomes de domínio*.composer.cloud.google.com.Servidor da Web do Airflow que não responde. Se o erro 504 persistir, mas você ainda conseguir acessar a interface do Airflow em determinados momentos, o servidor da Web do Airflow pode não estar respondendo porque está sobrecarregado. Tente aumentar os parâmetros de escala e desempenho do servidor da Web.
Erro 502 ao acessar a interface do Airflow
O erro 502 Internal server exception indica que a interface do Airflow não pode
atender às solicitações recebidas. Esse erro pode ter várias causas:
Problema de comunicação temporário. Tente acessar a interface do Airflow mais tarde.
Falha ao iniciar o servidor da Web. Para iniciar, o servidor da Web exige que os arquivos de configuração sejam sincronizados primeiro. Verifique se há entradas de registro semelhantes a
GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmpouGCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmpnos registros do servidor da Web. Se você receber esses erros, verifique se os arquivos mencionados nas mensagens de erro ainda estão presentes no bucket do ambiente.Em caso de remoção acidental (por exemplo, porque uma política de retenção foi configurada), é possível restaurá-los:
Defina uma nova variável de ambiente no seu ambiente. Você pode usar qualquer nome e valor de variável.
Substituir uma opção de configuração do Airflow. É possível usar uma opção de configuração do Airflow que não existe.
Erro 500 ao acessar a interface do Airflow depois de substituir [webserver]analytics_tool
Em ambientes com o Airflow 2, se você substituir a
opção de configuração [webserver]analytics_tool do Airflow para rotear dados anônimos
de uso da interface do Airflow para um serviço de análise (como
Google Analytics, Segment, MetaRouter ou Matomo), o acesso à
interface do Airflow após a atualização do ambiente pode retornar uma
resposta (500) Internal Server Error, com um dos seguintes erros nos
registros do servidor da Web do Airflow:
airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config
airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config
Quando [webserver]analytics_tool é definido no Airflow 2, o servidor da Web do Airflow
exige que as opções de análise associadas na seção [webserver] também sejam
definidas ao renderizar a interface do Airflow.
No Airflow 3, as opções de configuração [webserver]analytics_tool, [webserver]analytics_id e
[webserver]analytics_url foram removidas.
Soluções:
- Remova a substituição da opção de configuração do Airflow
[webserver]analytics_toolou - Especifique todas as opções de configuração obrigatórias do Airflow juntas:
[webserver]analytics_tool[webserver]analytics_id[webserver]analytics_url(obrigatório no Airflow 2.9 e versões mais recentes, mesmo que sua ferramenta de análise não use um URL personalizado)
Passar o cursor sobre a instância da tarefa na visualização em árvore gera um TypeError não detectado
No Airflow 2, a visualização em árvore na interface do Airflow pode não funcionar corretamente quando um fuso horário não padrão é usado. Como solução alternativa para esse problema, configure o fuso horário explicitamente na interface do Airflow.
A interface do Airflow no Airflow 2.2.3 ou versões anteriores é vulnerável à CVE-2021-45229
Como indicado em CVE-2021-45229,
a tela "Acionar DAG com configuração" era suscetível a ataques de XSS
pelo argumento de consulta origin.
Recomendação: faça upgrade para a versão mais recente do Airflow Gerenciado que oferece suporte ao Airflow 2.2.5.
Os workers exigem mais memória do que nas versões anteriores do Airflow
Sintomas:
No ambiente do Airflow Gerenciado (2ª geração), todas as cargas de trabalho do cluster do ambiente dos workers do Airflow estão no status
CrashLoopBackOffe não executam tarefas. Também é possível ver os avisos doOOMKillingque são gerados se você for afetado por esse problema.Esse problema pode impedir upgrades do ambiente.
Causa:
- Se você usar um valor personalizado para a opção de configuração
[celery]worker_concurrencydo Airflow e configurações de memória personalizadas para workers do Airflow, poderá ter esse problema quando o consumo de recursos se aproximar do limite. - Os requisitos de memória do worker do Airflow no Airflow 2.6.3 com Python 3.11 são 10% maiores em comparação com os workers em versões anteriores.
- Os requisitos de memória do worker do Airflow no Airflow 2.3 e versões posteriores são 30% maiores em comparação com os workers no Airflow 2.2 ou Airflow 2.1.
Soluções:
- Remova a substituição de
worker_concurrencypara que o Airflow gerenciado calcule esse valor automaticamente. - Se você usar um valor personalizado para
worker_concurrency, defina-o como um valor mais baixo. Use o valor calculado automaticamente como ponto de partida. - Como alternativa, é possível aumentar a quantidade de memória disponível para os workers do Airflow.
- Se não for possível fazer upgrade do ambiente para uma versão mais recente devido a esse problema, aplique uma das soluções propostas antes de fazer upgrade.
Acionamento de DAGs em redes privadas usando o Cloud Run functions
O Airflow gerenciado não permite acionar DAGs com funções do Cloud Run em redes privadas usando o conector de VPC.
Recomendação: use o Cloud Run functions para publicar mensagens no Pub/Sub. Esses eventos podem acionar sensores do Pub/Sub para iniciar DAGs do Airflow ou implementar uma abordagem baseada em operadores adiáveis.
Pastas vazias em Scheduler e Workers
O Airflow gerenciado não remove ativamente pastas vazias dos workers e programadores do Airflow. Essas entidades podem ser criadas como resultado do processo de sincronização do bucket do ambiente quando essas pastas existiam no bucket e foram removidas.
Recomendação: ajuste os DAGs para que eles estejam preparados para pular essas pastas vazias.
Essas entidades são removidas dos armazenamentos locais de programadores e workers do Airflow quando esses componentes são reiniciados (por exemplo, como resultado de operações de redução de escala vertical ou manutenção no cluster do ambiente).
Suporte para Kerberos
O Airflow gerenciado não é compatível com a configuração do Airflow Kerberos.
Suporte para classes de computação no Airflow Gerenciado (Geração 2) e no Airflow Gerenciado (Geração 3)
O Airflow Gerenciado (Gen 3) e o Airflow Gerenciado (Gen 2) oferecem suporte apenas à classe de computação de uso geral. Isso significa que não é possível executar pods que solicitam outras classes de computação, como Balanced ou Scale-Out.
A classe de uso geral permite executar pods que solicitam até 110 GB de memória e até 30 CPUs (conforme descrito em Solicitações máximas de classe de computação).
Se você quiser usar uma arquitetura baseada em ARM ou precisar de mais CPU e memória, use uma classe de computação diferente, que não é compatível com os clusters do Airflow gerenciado (geração 3) e do Airflow gerenciado (geração 2).
Recomendação: use GKEStartPodOperator para executar pods do Kubernetes em
um cluster diferente que seja compatível com a classe de computação selecionada. Se você
executar pods personalizados que exigem uma classe de computação diferente, eles também precisarão ser executados
em um cluster do Airflow não gerenciado.
Suporte para operadores do Google Campaign Manager 360
Os operadores do Google Campaign Manager em versões do Airflow Gerenciado anteriores à 2.1.13 são baseados na API Campaign Manager 360 v3.5, que foi descontinuada e será desativada em 1º de maio de 2023.
Se você usa operadores do Google Campaign Manager, faça upgrade do ambiente para a versão 2.1.13 ou mais recente do Airflow gerenciado.
Suporte para operadores do Google Display & Video 360
Os operadores do Google Display & Video 360 em versões do Airflow Gerenciado anteriores à 2.1.13 são baseados na API Display & Video 360 v1.1, que foi descontinuada e será desativada em 27 de abril de 2023.
Se você usa operadores do Google Display & Video 360, faça upgrade do ambiente para a versão 2.1.13 ou mais recente do Airflow Gerenciado. Além disso, talvez seja necessário alterar seus DAGs porque alguns dos operadores do Google Display & Video 360 foram descontinuados e substituídos por novos.
- O uso de
GoogleDisplayVideo360CreateReportOperatorfoi descontinuado. Em vez disso, useGoogleDisplayVideo360CreateQueryOperator. Esse operador retornaquery_idem vez dereport_id. - O uso de
GoogleDisplayVideo360RunReportOperatorfoi descontinuado. Em vez disso, useGoogleDisplayVideo360RunQueryOperator. Esse operador retornaquery_idereport_idem vez de apenasreport_id, e requerquery_idem vez dereport_idcomo parâmetro. - Para verificar se um relatório está pronto, use o novo
sensor
GoogleDisplayVideo360RunQuerySensorque usa os parâmetrosquery_idereport_id. O sensorGoogleDisplayVideo360ReportSensordescontinuado exigia apenasreport_id. GoogleDisplayVideo360DownloadReportV2Operatoragora exige os parâmetrosquery_idereport_id.- No
GoogleDisplayVideo360DeleteReportOperator, não há mudanças que possam afetar seus DAGs.
Restrições de nome do intervalo secundário
CVE-2023-29247 (a página de detalhes da instância da tarefa na UI é vulnerável a um XSS armazenado)
A interface do Airflow nas versões 2.0.x a 2.5.x é vulnerável à CVE-2023-29247.
Se você usa uma versão do Airflow Gerenciado anterior à 2.4.2 e suspeita que seu ambiente possa estar vulnerável à exploração, leia a descrição a seguir e as possíveis soluções.
No Airflow gerenciado, o acesso à interface do Airflow é protegido com o IAM e o controle de acesso à interface do Airflow.
Isso significa que, para explorar a vulnerabilidade da interface do Airflow, os invasores primeiro precisam ter acesso ao projeto, além das permissões e dos papéis do IAM necessários.
Solução:
Verifique as permissões e os papéis do IAM no projeto, incluindo os papéis do Serviço Gerenciado para Apache Airflow atribuídos a usuários individuais. Verifique se apenas usuários aprovados podem acessar a interface do Airflow.
Verifique os papéis atribuídos aos usuários pelo mecanismo de controle de acesso da interface do Airflow, que é um mecanismo separado que fornece acesso mais granular à interface do Airflow. Verifique se apenas usuários aprovados podem acessar a interface do Airflow e se todos os novos usuários estão registrados com um papel adequado.
Considere uma proteção extra com o VPC Service Controls.
O DAG de monitoramento do Airflow do ambiente do Composer do Airflow gerenciado (geração 2) não é recriado após a exclusão
O DAG de monitoramento do Airflow não é recriado automaticamente se for excluído pelo usuário ou movido do bucket em ambientes com composer-2.1.4-airflow-2.4.3.
Solução:
- Isso foi corrigido em versões mais recentes, como composer-2.4.2-airflow-2.5.3. A abordagem sugerida é fazer upgrade do ambiente para uma versão mais recente.
- Uma alternativa ou solução temporária para um upgrade de ambiente seria copiar o DAG airflow_monitoring de outro ambiente com a mesma versão.
Não é possível reduzir o armazenamento do Cloud SQL
O Airflow Gerenciado usa o Cloud SQL para executar o banco de dados do Airflow. Com o tempo, o armazenamento em disco da instância do Cloud SQL pode aumentar porque o disco é escalonado para acomodar os dados armazenados pelas operações do Cloud SQL quando o banco de dados do Airflow cresce.
Não é possível reduzir o tamanho do disco do Cloud SQL.
Como solução alternativa, se você quiser usar o menor tamanho de disco do Cloud SQL, recrie os ambientes do Airflow Gerenciado com snapshots.
A métrica de uso do disco do banco de dados não diminui depois da remoção de registros do Cloud SQL
Os bancos de dados relacionais, como Postgres ou MySQL, não removem fisicamente as linhas quando elas são excluídas ou atualizadas. Em vez disso, ele as marca como "tuplas mortas" para manter a consistência dos dados e evitar o bloqueio de transações simultâneas.
O MySQL e o Postgres implementam mecanismos de recuperação de espaço após a exclusão de registros.
Embora seja possível forçar o banco de dados a recuperar o espaço em disco não utilizado, essa é uma operação que consome muitos recursos e que também bloqueia o banco de dados, tornando o Airflow Gerenciado indisponível. Portanto, é recomendável confiar nos mecanismos de criação para recuperar o espaço não utilizado.
Acesso bloqueado: erro de autorização
Se esse problema afetar um usuário, a caixa de diálogo Acesso bloqueado: erro de autorização vai conter a mensagem Error 400: admin_policy_enforced.
Se a opção Controles de API > Apps de terceiros não configurados > Não permitir que os usuários acessem apps de terceiros estiver ativada no Google Workspace e o Apache Airflow no app Airflow gerenciado não for explicitamente permitido, os usuários não poderão acessar a interface do Airflow, a menos que permitam explicitamente o aplicativo.
Para permitir o acesso, siga as etapas em Permitir acesso à interface do Airflow no Google Workspace.
Loop de login ao acessar a interface do Airflow
Esse problema pode ter as seguintes causas:
Se as vinculações de acesso baseado no contexto do Chrome Enterprise Premium forem usadas com níveis de acesso que dependem de atributos do dispositivo, e o Apache Airflow no app Airflow Gerenciado não estiver isento, não será possível acessar a interface do Airflow devido a um loop de login. Para permitir o acesso, siga as etapas em Permitir acesso à interface do Airflow em vinculações de acesso baseado no contexto.
Se as regras de entrada estiverem configuradas em um perímetro do VPC Service Controls que protege o projeto, e a regra de entrada que permite o acesso ao serviço do Airflow gerenciado usar o tipo de identidade
ANY_SERVICE_ACCOUNTouANY_USER_ACCOUNT, os usuários não poderão acessar a interface do Airflow, resultando em um loop de login. Para mais informações sobre como lidar com esse cenário, consulte Permitir acesso à interface do Airflow nas regras de entrada do VPC Service Controls.
Instâncias de tarefa que foram concluídas no passado marcadas como FALHA
Em algumas circunstâncias e cenários raros, as instâncias de tarefa do Airflow que foram bem-sucedidas
no passado podem ser marcadas como FAILED.
Se isso acontecer, geralmente é porque foi acionado por uma operação de atualização ou upgrade do ambiente ou por uma manutenção do GKE.
Observação: o problema em si não indica nenhum problema no ambiente e não causa falhas reais na execução da tarefa.
O problema foi corrigido na versão 2.6.5 ou posterior do Airflow Gerenciado.
Os componentes do Airflow têm problemas ao se comunicar com outras partes da configuração do Airflow Gerenciado
Esse problema se aplica apenas às versões 2.10.2 e anteriores do Airflow Gerenciado (2ª geração).
Em casos muito raros, a lentidão da comunicação com o servidor de metadados do Compute Engine pode fazer com que os componentes do Airflow não funcionem de maneira ideal. Por exemplo, o programador do Airflow pode ser reiniciado, as tarefas do Airflow podem precisar ser repetidas ou o tempo de inicialização da tarefa pode ser maior.
Sintomas:
Os seguintes erros aparecem nos registros dos componentes do Airflow (como programadores, workers ou o servidor da Web do Airflow):
Authentication failed using Compute Engine authentication due to unavailable metadata server
Compute Engine Metadata server unavailable on attempt 1 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 2 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 3 of 3. Reason: timed out
Solução:
- Faça upgrade do ambiente para uma versão mais recente do Airflow Gerenciado. Esse problema foi corrigido a partir da versão 2.11.0 do Airflow Gerenciado.
A pasta /data não está disponível no servidor da Web do Airflow
No Airflow Gerenciado (Geração 2) e no Airflow Gerenciado (Geração 3), o servidor da Web do Airflow é um componente somente leitura, e o Airflow Gerenciado não sincroniza a pasta data/ com esse componente.
Às vezes, é útil compartilhar arquivos comuns entre todos os componentes do Airflow, incluindo o servidor da Web do Airflow.
Solução:
Encapsule os arquivos a serem compartilhados com o servidor da Web em um módulo PYPI e instale-o como um pacote PYPI comum. Depois que o módulo PYPI é instalado no ambiente, os arquivos são adicionados às imagens dos componentes do Airflow e ficam disponíveis para eles.
Adicione arquivos à pasta
plugins/. Essa pasta é sincronizada com o servidor da Web do Airflow.
Diagramas de tempos de análise de DAG não contínuos e tamanho do conjunto de DAGs no monitoramento
Os diagramas de tempos de análise de DAG não contínuos e de tamanho de bolsa de DAG no painel de monitoramento indicam problemas com tempos de análise de DAG longos (mais de 5 minutos).
Solução: recomendamos manter o tempo total de análise do DAG em menos de 5 minutos. Para reduzir o tempo de análise do DAG, siga as diretrizes de gravação do DAG.
Os registros dos componentes do Airflow Gerenciado estão ausentes no Cloud Logging
Há um problema no componente do ambiente responsável por fazer upload dos registros dos componentes do Airflow para o Cloud Logging. Esse bug às vezes leva a uma situação em que o registro no nível do Airflow Gerenciado pode estar ausente para um componente do Airflow. O mesmo registro ainda está disponível no nível do componente do Kubernetes.
Ocorrência do problema: muito rara, esporádica
Causa:
Comportamento incorreto do componente do Airflow Gerenciado responsável por fazer upload de registros para o Cloud Logging.
Soluções:
Faça upgrade do ambiente para a versão 2.10.0 ou mais recente do Airflow Gerenciado.
Em versões anteriores do Airflow Gerenciado, a solução temporária quando você se depara com essa situação é iniciar uma operação do Airflow Gerenciado que reinicie os componentes para os quais o registro está ausente.
Não é possível mudar o cluster do ambiente para o GKE Enterprise Edition
Esta observação se aplica ao Airflow Gerenciado 1 e ao Airflow Gerenciado 2.
O cluster do GKE do ambiente do Airflow gerenciado é criado no GKE Standard Edition.
Desde dezembro de 2024, o serviço Airflow Gerenciado não permite a criação de ambientes com clusters na edição Enterprise.
Os ambientes do Airflow gerenciado não foram testados com o GKE Enterprise Edition e têm um modelo de faturamento diferente.
Mais comunicações relacionadas ao GKE Standard Edition em comparação com o Enterprise Edition serão feitas no segundo trimestre de 2025.
Componentes do Airflow com problemas ao se comunicar com outras partes da configuração do Airflow Gerenciado
Em alguns casos, devido a uma falha na resolução de DNS, os componentes do Airflow podem ter problemas ao se comunicar com outros componentes do Airflow Gerenciado ou endpoints de serviço fora do ambiente do Airflow Gerenciado.
Sintomas:
Os seguintes erros podem aparecer nos registros dos componentes do Airflow (como programadores, workers ou o servidor da Web do Airflow):
google.api_core.exceptions.ServiceUnavailable: 503 DNS resolution failed ...
... Timeout while contacting DNS servers
ou
Could not access *.googleapis.com: HTTPSConnectionPool(host='www.googleapis.com', port=443): Max retries exceeded with url: / (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7c5ef5adba90>: Failed to resolve 'www.googleapis.com' ([Errno -3] Temporary failure in name resolution)"))
ou
redis.exceptions.ConnectionError: Error -3 connecting to
airflow-redis-service.composer-system.svc.cluster.local:6379.
Temporary failure in name resolution.
Soluções possíveis:
Faça upgrade para o Airflow Gerenciado 2.9.11 ou
Defina a seguinte variável de ambiente:
GCE_METADATA_HOST=169.254.169.254.
O ambiente está no estado de erro depois que a conta de faturamento do projeto foi excluída ou desativada ou a API Cloud Composer foi desativada
Os ambientes do Airflow gerenciado afetados por esses problemas não são recuperáveis:
- Depois que a conta de faturamento do projeto foi excluída ou desativada, mesmo que outra conta tenha sido vinculada posteriormente.
- Depois que a API Cloud Composer foi desativada no projeto, mesmo que tenha sido ativada posteriormente.
Para resolver o problema, faça o seguinte:
Ainda é possível acessar os dados armazenados nos buckets do ambiente, mas os ambientes em si não podem mais ser usados. É possível criar um novo ambiente do Airflow Gerenciado e transferir seus DAGs e dados.
Se você quiser realizar qualquer uma das operações que tornam seus ambientes irrecuperáveis, faça backup dos dados, por exemplo, criando um snapshot do ambiente. Dessa forma, é possível criar outro ambiente e transferir os dados dele carregando esse snapshot.
Avisos sobre o orçamento de interrupção de pods para clusters de ambiente
Os seguintes avisos podem aparecer na interface do GKE para clusters de ambiente do Airflow Gerenciado:
GKE can't perform maintenance because the Pod Disruption Budget allows
for 0 Pod evictions. Update the Pod Disruption Budget.
A StatefulSet is configured with a Pod Disruption Budget but without readiness
probes, so the Pod Disruption Budget isn't as effective in gauging application
readiness. Add one or more readiness probes.
Não é possível eliminar esses avisos. Estamos trabalhando para impedir que esses avisos sejam gerados.
Soluções possíveis:
- Ignore esses avisos até que o problema seja corrigido.
Não é possível remover um valor de campo em uma conexão do Airflow
Causa:
A interface do usuário do Apache Airflow tem uma limitação que impede a atualização de campos de conexão para valores vazios. Quando você tenta fazer isso, o sistema reverte para as configurações salvas anteriormente.
Soluções possíveis:
Embora a versão 2.10.4 do Apache Airflow inclua uma correção permanente, há uma solução temporária para usuários de versões anteriores. Para isso, exclua a conexão e recrie-a, deixando os campos obrigatórios vazios. A interface de linha de comando é a abordagem recomendada para excluir a conexão:
gcloud composer environments run ENVIRONMENT_NAME \
--location LOCATION \
connections delete -- \
CONNECTION_ID
Depois de excluir a conexão, recrie-a usando a interface do Airflow, garantindo que os campos que você quer deixar vazios estejam realmente em branco. Também é possível criar a conexão executando o comando connections add da CLI do Airflow com a Google Cloud CLI.
Os registros de tarefas do Airflow não serão coletados se [core]execute_tasks_new_python_interpreter estiver definido como True
O Airflow Gerenciado não coleta registros de tarefas do Airflow se a opção de configuração [core]execute_tasks_new_python_interpreter estiver definida como True.
Possível solução:
- Remova a substituição dessa opção de configuração ou defina
o valor como
False.
Pontos de dados ausentes nas métricas, ValueError: não é possível determinar o caminho sem o nome do bucket
Os ambientes com as versões 2.16.0 e 2.16.1 do Airflow Gerenciado (2ª geração) podem apresentar
um problema conhecido com a geração de relatórios de métricas. É possível observar alguns pontos de dados ignorados nas métricas do relatório e ver mensagens de erro sobre as reinicializações do pod airflow-monitoring nos registros do ambiente.
Exemplo de mensagem de erro:
ValueError: Cannot determine path without bucket name error.
Esse problema não afeta a funcionalidade do ambiente. O ambiente ainda está operacional, e as informações de integridade e monitoramento do ambiente são informadas corretamente. Você pode ignorar as mensagens de erro.
Desempenho degradado do ambiente em várias versões do pacote google-api-core
As versões do pacote pré-instalado google-api-core de 2.28.0 a 2.30.2 podem
causar degradação do desempenho do ambiente, o que pode resultar em tempos mais longos para
executar uma tarefa e tempos mais longos para mover uma tarefa do estado na fila para o estado de
execução.
Builds do Airflow gerenciado (3ª geração) afetados:
- composer-3-airflow-3.1.7-build.0 para composer-3-airflow-3.1.7-build.5
- composer-3-airflow-3.1.0-build.5 para composer-3-airflow-3.1.0-build.10
- composer-3-airflow-2.11.1-build.0
- composer-3-airflow-2.10.5-build.22 para composer-3-airflow-2.10.5-build.33
- composer-3-airflow-2.9.3-build.42 para composer-3-airflow-2.9.3-build.53
Builds do Airflow gerenciado (2ª geração) afetados:
- composer-2.16.10-airflow-2.11.1
- composer-2.16.0-airflow-2.10.5 para composer-2.16.10-airflow-2.10.5
- composer-2.16.0-airflow-2.9.3 para composer-2.16.10-airflow-2.9.3
Recomendamos que você faça upgrade do ambiente para as seguintes versões, que contêm uma versão do pacote em que o problema foi corrigido ou não está presente:
- composer-3-airflow-3.1.7-build.7 e mais recentes
- composer-3-airflow-2.11.1-build.3 e mais recentes
- composer-3-airflow-2.10.5-build.36 e mais recentes
- composer-3-airflow-2.9.3-build.54 (contém 2.27.0)
- composer-2.17.0-airflow-2.11.1 e mais recentes
- composer-2.17.0-airflow-2.10.5 e mais recentes
- composer-2.16.11-airflow-2.11.1 (contém 2.27.0)
- composer-2.16.11-airflow-2.10.5 (contém 2.27.0)
- composer-2.16.11-airflow-2.9.3 (contém 2.27.0)
Como solução alternativa, instale manualmente uma versão mais recente do pacote google-api-core em um ambiente afetado especificando >=2.30.3 como a versão necessária.
A seguir
- Como resolver problemas da criação de ambientes
- Como resolver problemas de DAGs
- Como solucionar problemas do Airflow Scheduler