Depurar problemas de DAG sem memória e sem armazenamento

Cloud Composer 1 | Cloud Composer 2

Neste tutorial, apresentamos as etapas para depurar um DAG com falha no Cloud Composer e diagnosticar problemas relacionados a recursos do worker, como falta de memória ou espaço de armazenamento, com a ajuda de registros e do monitoramento de ambiente.

Introdução

Este tutorial se concentra em problemas relacionados a recursos para demonstrar maneiras de depurar um DAG.

A falta de recursos de worker alocados causa falhas no DAG. Se uma tarefa do Airflow ficar sem memória ou armazenamento, você verá uma exceção do Airflow, como:

WARNING airflow.exceptions.AirflowException: Task received SIGTERM signal
INFO - Marking task as FAILED.

ou

Task exited with return code Negsignal.SIGKILL

Nesses casos, a recomendação geral é aumentar os recursos de worker do Airflow ou reduzir o número de tarefas por worker. No entanto, como as exceções do Airflow podem ser genéricas, pode ser difícil identificar o recurso específico que está causando o problema.

Neste tutorial, explicamos como diagnosticar o motivo de uma falha do DAG e identificar o tipo de recurso que causa problemas depurando dois DAGs de exemplo que falham devido à falta de memória e armazenamento do worker.

Objetivos

• Execute exemplos de DAGs que falham pelos seguintes motivos:

  • Falta de memória do worker
  • Falta de armazenamento do worker

• Diagnosticar os motivos da falha

• Aumentar os recursos de workers alocados

• Teste os DAGs com novos limites de recursos

Custos

Neste tutorial, usamos o seguinte componente faturável do Google Cloud:

• Cloud Composer (consulte outros custos)
• Cloud Monitoring

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Veja mais detalhes em Limpeza.

Antes de começar

Esta seção descreve as ações necessárias antes de iniciar o tutorial.

Criar e configurar um projeto

Para este tutorial, você precisa de um projeto do Google Cloud. Configure o projeto da seguinte maneira:

1. No console do Google Cloud, selecione ou crie um projeto:

   Acesse o seletor de projetos

2. Verifique se o faturamento foi ativado para o projeto. Saiba como verificar se o faturamento está ativado em um projeto.

3. Verifique se o usuário do projeto do Google Cloud tem os seguintes papéis para criar os recursos necessários:

   • Administrador de ambiente e de objetos do Storage (roles/composer.environmentAndStorageObjectAdmin)
   • Administrador do Compute (roles/compute.admin)
   • Editor do Monitoring (roles/monitoring.editor)

Ativar as APIs do projeto

Ative a API Cloud Composer.

Ative a API

criar o ambiente do Cloud Composer

Crie um ambiente do Cloud Composer 2.

Importante: use a predefinição de ambiente pequena para reproduzir os erros ao usar os exemplos fornecidos mais adiante neste tutorial. Essa é a predefinição padrão ao criar um ambiente usando o console do Google Cloud.

Como parte da criação do ambiente, você concede o papel Extensão do agente de serviço da API Cloud Composer v2 (roles/composer.ServiceAgentV2Ext) à conta do agente de serviço do Composer. O Cloud Composer usa essa conta para executar operações no projeto do Google Cloud.

Verificar os limites de recursos do worker

Verifique os limites de recursos de worker do Airflow no seu ambiente:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na lista de ambientes, clique no nome do ambiente. A página Detalhes do ambiente é aberta.

3. Acesse a guia Configuração do ambiente.

4. Acesse Recursos > Configuração de cargas de trabalho > Worker.

5. Verifique se os valores são 0,5 vCPU, 1,875 GB de memória e 1 GB de armazenamento. Estes são os limites de recursos de worker do Airflow com que você vai trabalhar nas próximas etapas deste tutorial.

Exemplo: diagnosticar problemas de falta de memória

Faça upload do DAG de amostra a seguir para o ambiente criado nas etapas anteriores. Neste tutorial, este DAG é chamado de create_list_with_many_strings.

Esse DAG contém uma tarefa que executa as seguintes etapas:

1. Cria uma lista vazia s.
2. Executa um ciclo para anexar a string More à lista.
3. Imprime quanta memória a lista consome e aguarda 1 segundo a cada iteração de 1 minuto.

Aviso: este DAG simula um problema de falta de memória, o que pode interromper as operações no seu ambiente.

import time

import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import sys
from datetime import timedelta

default_args = {
    'start_date': airflow.utils.dates.days_ago(0),
    'retries': 0,
    'retry_delay': timedelta(minutes=10)
}

dag = DAG(
    'create_list_with_many_strings',
    default_args=default_args,
    schedule_interval=None)


def consume():
    s = []
    for i in range(120):
        for j in range(1000000):
            s.append("More")
        print(f"i={i}; size={sys.getsizeof(s) / (1000**3)}GB")
        time.sleep(1)


t1 = PythonOperator(
    task_id='task0',
    python_callable=consume,
    dag=dag,
    depends_on_past=False,
    retries=0
)

Acionar o DAG de amostra

Acione o DAG de amostra, create_list_with_many_strings:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na coluna Servidor da Web do Airflow, siga o link Airflow do ambiente.

3. Na interface da Web do Airflow, na página DAGs, na coluna Links do DAG, clique no botão Acionar DAG.

4. Clique em Gatilho.

5. Na página DAGs, clique na tarefa que você acionou e revise os registros de saída para verificar se o DAG começou a ser executado.

Enquanto a tarefa estiver em execução, os registros de saída imprimirão o tamanho da memória em GB que o DAG está usando.

Após vários minutos, a tarefa falhará porque excede o limite de memória do worker do Airflow de 1,875 GB.

Observação :se você acionar o DAG que exceder o limite de memória simultaneamente com qualquer outro DAG de amostra, vai perceber que, se uma das tarefas exceder o limite de memória e falhar, outras tarefas em execução também vão falhar, mesmo que não consumam memória.

Diagnosticar o DAG com falha

Se você estava executando várias tarefas no momento da falha, considere executar apenas uma tarefa e diagnosticar a pressão de recursos durante esse tempo para identificar quais tarefas causam pressão de recursos e quais você precisa aumentar.

revisar os registros de tarefas do Airflow

A tarefa do DAG create_list_with_many_strings tem um estado Failed.

Analise os registros da tarefa. A seguinte entrada de registro vai aparecer:

```none
{local_task_job.py:102} INFO - Task exited with return code
Negsignal.SIGKILL
```

`Netsignal.SIGKILL` might be an indication of your task using more memory
than the Airflow worker is allocated. The system sends
the `Negsignal.SIGKILL` signal to avoid further memory consumption.

Revise as cargas de trabalho

Revise as cargas de trabalho para verificar se a carga da tarefa não faz com que o nó em que o pod é executado exceda o limite de consumo de memória:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na lista de ambientes, clique no nome do ambiente. A página Detalhes do ambiente é aberta.

3. Acesse a guia Configuração do ambiente.

4. Em Recursos > Cluster do GKE > Cargas de trabalho, clique em Visualizar cargas de trabalho do cluster.

5. Verifique se alguns dos pods de carga de trabalho têm status semelhante a este:

   Error with exit code 137 and 1 more issue.
   ContainerStatusUnknown with exit code 137 and 1 more issue
   

   Exit code 137 significa que um contêiner ou pod está tentando usar mais memória do que o permitido. O processo é encerrado para evitar o uso da memória.

Analisar a integridade do ambiente e o monitoramento do consumo de recursos

Revise a integridade do ambiente e o monitoramento do consumo de recursos:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na lista de ambientes, clique no nome do ambiente. A página Detalhes do ambiente é aberta.

3. Acesse a guia Monitoramento e selecione Visão geral.

4. No painel Visão geral do ambiente, localize o gráfico Integridade do ambiente (DAG de monitoramento do Airflow). Ele contém uma área vermelha, que corresponde à hora em que os registros começaram a mostrar erros.

5. Selecione Workers e encontre o gráfico Uso total da memória dos workers. Observe que a linha Uso da memória tem um pico no momento em que a tarefa estava em execução.

Figura 1. Gráfico de uso total da memória dos workers (clique para ampliar)

Mesmo que a linha de uso da memória no gráfico não atinja o limite, ao diagnosticar os motivos da falha, é necessário considerar apenas a memória alocável, enquanto a linha Limite de memória no gráfico representa a memória total disponível (incluindo a capacidade reservada pelo GKE).

Neste exemplo, o limite de memória do worker é de 1,875 GB. O GKE reserva 25% dos primeiros 4 GiB de memória. O GKE também reserva um limite de remoção extra: 100 MiB de memória em cada nó para remoção do kubelet.

A memória alocável é calculada da seguinte maneira:

ALLOCATABLE = CAPACITY - RESERVED - EVICTION-THRESHOLD

Se o limite de memória for de 1,875 GB, a memória alocável real será:

1.75 GiB (1.875GB) - 0.44 (25% GiB reserved) - 0.1 = 1.21 GiB (~1.3 GB).

Ao anexar esse limite real ao gráfico de uso de memória, você verá que o pico da tarefa atinge o limite de memória real e pode concluir que a tarefa falhou devido à memória insuficiente de worker.

Observação: se o nível de consumo de memória estiver aumentando muito rápido, a linha de uso de memória pode não capturar o nível real de consumo de recursos corretamente. O DAG airflow_monitoring é uma verificação de integridade de atividade por ambiente usada para preencher a métrica de monitoramento environment/healthy. Ele permite usar os recursos do Cloud Monitoring, como gráficos de métricas ou a configuração de alertas quando o ambiente perde a integridade. Ela é executada a cada cinco minutos e coleta as métricas, o que significa que pode não capturar o uso de recursos entre as execuções.

Aumentar o limite de memória do worker

Observação: alterar a CPU ou a memória do worker reinicia os workers, o que pode afetar as tarefas em execução. Recomendamos fazer isso quando nenhum DAG estiver em execução.

Aloque mais memória do worker para que o DAG de amostra funcione:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na lista de ambientes, clique no nome do ambiente. A página Detalhes do ambiente é aberta.

3. Acesse a guia Configuração do ambiente.

4. Encontre a configuração Resources > Workloads e clique em Edit.

5. Na seção Worker, no campo Memória, especifique o novo limite de memória para workers do Airflow. Neste tutorial, use 3 GB.

6. Salve as alterações e aguarde alguns minutos para que os workers do Airflow sejam reiniciados.

Teste o DAG com o novo limite de memória

Acione o DAG create_list_with_many_strings novamente e aguarde até que ele termine a execução.

1. Nos registros de saída da execução do DAG, você verá Marking task as SUCCESS, e o estado da tarefa indicará Sucesso.

2. Revise a seção Visão geral do ambiente na guia Monitoramento e verifique se não há áreas vermelhas.

3. Clique na seção Workers e encontre o gráfico Uso total da memória dos workers. Você verá que a linha Limite de memória reflete a alteração no limite de memória, e a linha Uso de memória está muito abaixo do limite real de memória alocável.

Exemplo: diagnosticar problemas de falta de armazenamento

Nesta etapa, você faz upload de dois DAGs que criam arquivos grandes. O primeiro DAG cria um arquivo grande. O segundo DAG cria um arquivo grande e imita uma operação de longa duração.

O tamanho do arquivo em ambos os DAGs excede o limite de armazenamento padrão de workers do Airflow de 1 GB, mas o segundo DAG tem uma tarefa de espera extra para estender a duração artificialmente.

Você investigará as diferenças no comportamento de ambos os DAGs nas próximas etapas.

Observação: os DAGs neste tutorial criam arquivos locais. Em uma configuração de produção, evite armazenar arquivos ou configurações no sistema de arquivos local, porque a próxima tarefa provavelmente será executada em outro worker do Airflow sem acesso ao arquivo.

Fazer upload de um DAG que crie um arquivo grande

Faça upload do DAG de amostra a seguir para o ambiente criado nas etapas anteriores. Neste tutorial, este DAG é chamado de create_large_txt_file_print_logs.

Esse DAG contém uma tarefa que executa as seguintes etapas:

1. Grava um arquivo localfile.txt de 1,5 GB no armazenamento de workers do Airflow.
2. Mostra o tamanho do arquivo criado usando o módulo os do Python.
3. Imprime a duração da execução do DAG a cada um minuto.

Aviso: este DAG simula um problema de falta de armazenamento, o que pode interromper as operações no seu ambiente.

import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import os
from datetime import timedelta
import time

default_args = {
    'start_date': airflow.utils.dates.days_ago(0),
    'retries': 0,
    'retry_delay': timedelta(minutes=10)
}

dag = DAG(
    'create_large_txt_file_print_logs',
    default_args=default_args,
    schedule_interval=None)


def consume():
    size = 1000**2  # bytes in 1 MB
    amount = 100

    def create_file():
        print(f"Start creating a huge file")
        with open("localfile.txt", "ab") as f:
            for j in range(15):
                f.write(os.urandom(amount) * size)
        print("localfile.txt size:", os.stat("localfile.txt").st_size / (1000**3), "GB")

    create_file()
    print("Success!")


t1 = PythonOperator(
    task_id='create_huge_file',
    python_callable=consume,
    dag=dag,
    depends_on_past=False,
    retries=0)

Fazer upload de um DAG que crie um arquivo grande em uma operação de longa duração

Para imitar um DAG de longa duração e investigar o impacto da duração da tarefa no estado final, faça upload do segundo DAG de amostra para seu ambiente. Neste tutorial, este DAG é chamado de long_running_create_large_txt_file_print_logs.

Esse DAG contém uma tarefa que executa as seguintes etapas:

1. Grava um arquivo localfile.txt de 1,5 GB no armazenamento de workers do Airflow.
2. Mostra o tamanho do arquivo criado usando o módulo os do Python.
3. Espera 1 hora e 15 minutos para imitar o tempo necessário para operações com o arquivo, por exemplo, leitura do arquivo.
4. Imprime a duração da execução do DAG a cada um minuto.

Aviso: este DAG simula um problema de falta de armazenamento, o que pode interromper as operações no seu ambiente.

import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import os
from datetime import timedelta
import time

default_args = {
    'start_date': airflow.utils.dates.days_ago(0),
    'retries': 0,
    'retry_delay': timedelta(minutes=10)
}

dag = DAG(
    'long_running_create_large_txt_file_print_logs',
    default_args=default_args,
    schedule_interval=None)


def consume():
    size = 1000**2  # bytes in 1 MB
    amount = 100

    def create_file():
        print(f"Start creating a huge file")
        with open("localfile.txt", "ab") as f:
            for j in range(15):
                f.write(os.urandom(amount) * size)
        print("localfile.txt size:", os.stat("localfile.txt").st_size / (1000**3), "GB")

    create_file()
    for k in range(75):
        time.sleep(60)
        print(f"{k+1} minute")

    print("Success!")


t1 = PythonOperator(
    task_id='create_huge_file',
    python_callable=consume,
    dag=dag,
    depends_on_past=False,
    retries=0)

Acionar DAGs de amostra

Acione o primeiro DAG, create_large_txt_file_print_logs:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na coluna Servidor da Web do Airflow, siga o link Airflow do ambiente.

3. Na interface da Web do Airflow, na página DAGs, na coluna Links do DAG, clique no botão Acionar DAG.

4. Clique em Gatilho.

5. Na página DAGs, clique na tarefa que você acionou e revise os registros de saída para verificar se o DAG começou a ser executado.

6. Aguarde até que a tarefa que você criou com o DAG create_large_txt_file_print_logs seja concluída. Isso pode levar alguns minutos.

   Observação: talvez você perceba que o armazenamento de workers do Airflow usado foi redefinido como zero após a conclusão da tarefa. O Cloud Composer depende do Autopilot do Google Kubernetes Engine, que fornece os recursos necessários. O escalonamento automático no Cloud Composer é baseado em métricas e controla a alocação de recursos por meio do gerenciamento de pods do GKE dentro de uma determinada cota.

7. Na página DAGs, clique na execução do DAG. Você verá que a tarefa tem um estado Success, mesmo que o limite de armazenamento tenha sido excedido.

Revise os registros da tarefa do Airflow:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

   1. Na lista de ambientes, clique no nome do ambiente. A página Detalhes do ambiente é aberta.

   2. Acesse a guia Registros e Todos os registros > Registros do Airflow > Workers > Ver na Análise de registros.

   3. Filtre os registros por tipo: mostre apenas mensagens de Erro.

Nos registros, serão exibidas mensagens semelhantes às seguintes:

Worker: warm shutdown (Main Process)

ou

A worker pod was evicted at 2023-12-01T12:30:05Z with message: Pod ephemeral
local storage usage exceeds the total limit of containers 1023Mi.

Esses registros indicam que o pod iniciou o processo de "encerramento com estado salvo" porque o armazenamento usado excedeu o limite e foi removido em 1 hora. No entanto, a execução do DAG não falhou porque foi concluída dentro do período de carência de encerramento do Kubernetes, que é explicado em mais detalhes neste tutorial.

Para ilustrar o conceito do período de carência da rescisão, analise o resultado do segundo DAG de amostra, long_running_create_large_txt_file_print_logs.

Acione o segundo DAG, long_running_create_large_txt_file_print_logs:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na coluna Servidor da Web do Airflow, siga o link Airflow do ambiente.

3. Na interface da Web do Airflow, na página DAGs, na coluna Links do DAG, clique no botão Acionar DAG.

4. Clique em Gatilho.

5. Na página DAGs, clique na tarefa que você acionou e revise os registros de saída para verificar se o DAG começou a ser executado.

6. Aguarde até que a execução do DAG long_running_create_large_txt_file_print_logs falhe. Isso vai levar cerca de uma hora.

Revise os resultados da execução do DAG:

1. Na página DAGs, clique na execução do DAG long_running_create_large_txt_file_print_logs. Você verá que a tarefa tem um estado Failed e que a duração da execução foi exatamente 1 hora e 5 minutos, o que é menos do que o período de espera da tarefa de 1 hora e 15 minutos.

2. Analise os registros da tarefa. Depois que o DAG cria o arquivo localfile.txt no contêiner do worker do Airflow, o registro mostra que o DAG começou a aguardar e a duração da execução é impressa nos registros de tarefas a cada um minuto. Neste exemplo, o DAG imprime o registro localfile.txt size: e o tamanho do arquivo localfile.txt será de 1,5 GB.

Quando o arquivo gravado no contêiner do worker do Airflow excede o limite de armazenamento, a execução do DAG falha. No entanto, a tarefa não falha imediatamente e continua em execução até atingir 1 hora e 5 minutos. Isso acontece porque o Kubernetes não encerra a tarefa imediatamente e continua em execução para permitir uma hora de tempo de recuperação, conhecido como "período de carência de encerramento". Quando um nó fica sem recursos, o Kubernetes não encerra o pod imediatamente para lidar com o encerramento de modo normal, a fim de que haja um impacto mínimo sobre o usuário final.

O período de carência do encerramento ajuda os usuários a recuperar arquivos após falhas nas tarefas. No entanto, pode causar confusão ao diagnosticar DAGs. Quando o limite de armazenamento do worker do Airflow é excedido, o estado da tarefa final depende da duração da execução do DAG:

• Se a execução do DAG exceder o limite de armazenamento do worker, mas for concluída em menos de uma hora, a tarefa será concluída com um status Success porque foi concluída dentro do período de carência do encerramento. No entanto, o Kubernetes encerra o pod, e o arquivo gravado é excluído do contêiner imediatamente.

• Se o DAG exceder o limite de armazenamento do worker e for executado por mais de uma hora, ele continuará em execução por uma hora e poderá exceder o limite de armazenamento em milhares de porcentagem antes que o Kubernetes elimine o pod e o Airflow marque a tarefa como Failed.

Observação: se você acionar um dos DAGs de amostra que excedem o limite de armazenamento simultaneamente com qualquer outro DAG de amostra, verá que, se uma das tarefas exceder o limite de armazenamento e falhar, todas as outras tarefas em execução também falharão, mesmo que não precisem de espaço de armazenamento.

Diagnosticar o DAG com falha

Se você estava executando várias tarefas no momento da falha, considere executar apenas uma tarefa e diagnosticar a pressão de recursos durante esse tempo para identificar quais tarefas causam pressão de recursos e quais você precisa aumentar.

Revise os registros de tarefas do segundo DAG, long_running_create_large_txt_file_print_logs:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na lista de ambientes, clique no nome do ambiente. A página Detalhes do ambiente é aberta.

3. Acesse a guia Registros e Todos os registros > Registros do Airflow > Workers > Ver na Análise de registros.

4. Filtre os registros por tipo: mostre apenas mensagens de Erro.

Nos registros, serão exibidas mensagens semelhantes às seguintes:

Container storage usage of worker reached 155.7% of the limit.

This likely means that the total size of local files generated by your DAGs is
close to the storage limit of worker.

You may need to decrease the storage usage or increase the worker storage limit
in your Cloud Composer environment configuration.

ou

Pod storage usage of worker reached 140.2% of the limit.
A worker pod was evicted at 2023-12-01T12:30:05Z with message: Pod ephemeral
local storage usage exceeds the total limit of containers 1023Mi.

This eviction likely means that the total size of dags and plugins folders plus
local files generated by your DAGs exceeds the storage limit of worker.

Please decrease the storage usage or increase the worker storage limit in your
Cloud Composer environment configuration.

Essas mensagens indicam que, à medida que a tarefa avança, os registros do Airflow começaram a imprimir erros quando o tamanho dos arquivos gerados pelo DAG excedeu o limite de armazenamento do worker e o período de carência de encerramento foi iniciado. Durante o período de carência de encerramento, o consumo de armazenamento não voltou ao limite, o que levou à remoção do pod após o término do período de carência.

Revise a integridade do ambiente e o monitoramento do consumo de recursos:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na lista de ambientes, clique no nome do ambiente. A página Detalhes do ambiente é aberta.

3. Acesse a guia Monitoramento e selecione Visão geral.

4. No painel Visão geral do ambiente, localize o gráfico Integridade do ambiente (DAG de monitoramento do Airflow). Ele contém uma área vermelha, que corresponde à hora em que os registros começaram a mostrar erros.

5. Selecione Workers e encontre o gráfico Uso total do disco de workers. Observe que a linha Uso de disco tem um pico e excede a linha Limite de disco no momento em que a tarefa estava em execução.

Figura 2. Gráfico de uso total do disco dos workers (clique para ampliar)

Aumentar o limite de armazenamento do worker

Observação: a alteração do armazenamento do worker reinicia os workers do Airflow, o que pode afetar as tarefas em execução. Recomendamos fazer isso quando nenhum DAG estiver em execução.

Aloque mais armazenamento de worker do Airflow para que o DAG de amostra seja bem-sucedido:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na lista de ambientes, clique no nome do ambiente. A página Detalhes do ambiente é aberta.

3. Acesse a guia Configuração do ambiente.

4. Encontre a configuração Resources > Workloads e clique em Edit.

5. Na seção Worker, no campo Armazenamento, especifique o novo limite de armazenamento para workers do Airflow. Neste tutorial, defina-o como 2 GB.

6. Salve as alterações e aguarde alguns minutos para que os workers do Airflow sejam reiniciados.

Teste o DAG com o novo limite de armazenamento

Acione o DAG long_running_create_large_txt_file_print_logs novamente e aguarde 1 hora e 15 minutos até que ele termine de ser executado.

1. Nos registros de saída da execução do DAG, você verá Marking task as SUCCESS, e o estado da tarefa indicará Sucesso, com duração de 1 hora e 15 minutos, que é igual ao tempo de espera definido no código DAG.

2. Revise a seção Visão geral do ambiente na guia Monitoramento e verifique se não há áreas vermelhas.

3. Clique na seção Workers e encontre o gráfico Uso total do disco de workers. Você verá que a linha Limite de disco reflete a alteração no limite de armazenamento, e a linha Uso de disco está dentro do intervalo permitido.

Resumo

Neste tutorial, você diagnosticou o motivo de uma falha do DAG e identificou o tipo de recurso que causa pressão depurando dois DAGs de exemplo que falham devido à falta de memória e armazenamento do worker. Você executou os DAGs com sucesso depois de alocar mais memória e armazenamento para os workers. No entanto, é recomendável otimizar os DAGs (fluxos de trabalho) para reduzir o consumo de recursos do worker em primeiro lugar, porque não é possível aumentar os recursos além de um determinado limite.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados neste tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Exclua o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

1. No Console do Google Cloud, acesse a página Gerenciar recursos.

   Acessar "Gerenciar recursos"

2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Excluir recursos individuais

Se você planeja ver vários tutoriais e guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

Exclua o ambiente do Cloud Composer. Você também vai excluir o bucket do ambiente durante este procedimento.

A seguir

• Escalonar ambientes
• Como resolver problemas de DAGs