Ao executar o pipeline usando o serviço gerenciado do Dataflow, use a interface do usuário de monitoramento do Dataflow baseada na Web para visualizar todos os jobs. A interface de monitoramento permite visualizar e interagir com suas tarefas do Dataflow.
É possível acessar a interface de monitoramento do Dataflow usando o console do Google Cloud. A interface de monitoramento mostra:
- Uma lista de todos os jobs do Dataflow em andamento e já executados nos últimos 30 dias;
- uma representação gráfica de cada pipeline;
- detalhes do status, tipo e versão do SDK do job;
- links para informações sobre os serviços do Google Cloud executando seu pipeline, como o Compute Engine e o Cloud Storage;
- quaisquer erros ou avisos que ocorrem durante um job.
- Diagnósticos adicionais para um job.
É possível visualizar os gráficos de monitoramento de jobs na interface de monitoramento do Dataflow. Esses gráficos exibem métricas ao longo da duração de um job de pipeline e incluem as seguintes informações:
- Visibilidade em nível de etapa para ajudar a identificar quais etapas podem estar causando atraso no pipeline.
- Informações estatísticas que podem apresentar comportamento anômalo.
- Métricas de E/S que podem ajudar a identificar os gargalos nas suas fontes e coletas.
Como acessar a interface de monitoramento do Dataflow
Para acessar a interface de monitoramento do Dataflow, siga estas etapas:
- Faça login no console do Cloud.
- Selecione seu projeto do Google Cloud.
- Abra o Menu de navegação.
- Em Big Data, clique em Dataflow.
Uma lista de jobs do Dataflow é exibida junto com o status deles. Se você não vir nenhum job, precisará executar um novo. Para saber como executar um job, consulte o guia de início rápido do Dataflow.
Um job pode ter os seguintes status:
- —: a interface de monitoramento ainda não recebeu um status do serviço Dataflow.
- Em execução: o job está em execução.
- Iniciando...: o job é criado, mas o sistema precisa de tempo para se preparar antes da inicialização.
- Em fila: um job do FlexRS está na fila ou um job do modelo flexível está sendo iniciado (o que pode levar vários minutos).
- Cancelando...: o job está sendo cancelado.
- Cancelado: o job foi cancelado.
- Drenando...: o job está sendo drenado.
- Drenado: o job foi drenado.
- Atualizando...: o job está sendo atualizado.
- Atualizado: o job está atualizado.
- Com êxito: o job foi concluído com sucesso.
- Com falha: o job não foi concluído.
Para mais informações sobre um pipeline, clique no Nome do job.
Como acessar gráficos de monitoramento de jobs
Para acessar os gráficos de monitoramento de um job, clique no job Nome na interface de monitoramento do Dataflow. A página Detalhes do job é exibida com as seguintes informações:
- Gráfico do job: a representação visual do pipeline
- Detalhes da execução: ferramenta para otimizar o desempenho do pipeline
- Métricas do job: métricas sobre a execução do job
- Painel de informações do Job: informações descritivas sobre seu pipeline
- Registros do job: registros gerados pelo serviço Dataflow no nível do job
- Logs do worker: registros gerados pelo serviço do Dataflow no nível do worker
- Diagnóstico: tabela que mostra onde ocorreram erros ao longo do cronograma escolhido e possíveis recomendações para o pipeline
- Seletor de tempo: ferramenta que permite ajustar o período de suas métricas
Na página Detalhes do job, é possível alternar a visualização de jobs com as métricas Gráfico do job, Detalhes da execução e Métricas do job..
Como criar alertas do Cloud Monitoring
O Dataflow é totalmente integrado ao Cloud Monitoring, o que permite criar alertas para quando seu job exceder um limite definido pelo usuário. Para criar um alerta do Cloud Monitoring a partir de um gráfico de métricas, clique em Criar política de alertas.
Para instruções sobre como criar esses alertas, leia a página Como usar o Cloud Monitoring para pipelines do Dataflow. Se não for possível ver os gráficos de monitoramento ou criar alertas, talvez sejam necessárias outras permissões do Monitoring.
Modo tela cheia
Para visualizar um gráfico de métricas em tela cheia, clique em fullscreen.
Como usar a ferramenta de seleção de horário
É possível ajustar o período das métricas com a ferramenta de seleção de horário. É possível selecionar uma duração predefinida ou um intervalo de tempo personalizado para analisar seu job.
Para jobs em lote de streaming ou durante a veiculação, a exibição padrão dos gráficos mostra as seis horas anteriores de métricas desse job. Para jobs de fluxo interrompido ou concluídos, a exibição padrão dos gráficos mostra todo o ambiente de execução da duração do job.
Métricas da etapa e do worker
É possível visualizar os gráficos na guia Job metrics da IU do Dataflow. Cada métrica é organizada nos seguintes painéis:
Métricas de visão geral
Métricas de streaming (somente pipelines de streaming)
- Atualização de dados (com e sem o Streaming Engine)
- Latência do sistema (com e sem Streaming Engine)
- Bytes do backlog (com e sem o Streaming Engine)
- Paralelismo (somente Streaming Engine)
- Cópias (somente Streaming Engine)
Métricas de entrada
Métricas de saída
Para acessar mais informações nesses gráficos, clique no botão de alternância para "Expandir legenda de gráfico".
Alguns desses gráficos são específicos apenas para pipelines de streaming. Uma lista de cenários em que essas métricas podem ser úteis para depuração pode ser encontrada na seção Como usar as métricas de monitoramento do Dataflow.
Escalonamento automático
O serviço Dataflow escolhe automaticamente o número de instâncias de worker obrigatórias na execução do job de escalonamento automático. O número de instâncias de worker pode mudar com o tempo de acordo com os requisitos do job.
Para ver o histórico das alterações de escalonamento automático, clique no botão Mais histórico. Uma tabela com informações sobre o histórico de worker do pipeline é exibida.
Capacidade
A capacidade é o volume de dados processados a qualquer momento. Essa métrica por etapa é exibida como o número de elementos por segundo. Para visualizar essa métrica em bytes por segundo, role para baixo até o gráfico Capacidade (bytes/segundo).
Contagem do registro de erros do worker
A contagem de registros de erros do worker mostra a taxa de erros observada em todos os workers a qualquer momento.
Uso da CPU
O uso da CPU é a quantidade de CPU usada dividida pela quantidade de CPU disponível para processamento. Essa métrica por worker é exibida como uma porcentagem. O painel inclui estes quatro gráficos:
- Uso da CPU (todos os workers)
- Uso da CPU (estatísticas)
- Uso da CPU (Superior 4)
- Uso da CPU (Inferior 4)
Atualização de dados (com e sem o Streaming Engine)
A atualização de dados é o tempo em segundos desde a marca-d'água de saída mais recente. Cada etapa do pipeline tem uma marca-d'água de dados de saída. Uma marca-d'água de dados de saída de T indica que todos os elementos com um tempo de evento antes de T foram processados para computação. A marca-d'água de dados de saída é limitada pela primeira marca-d'água de dados de entrada de todas as computações upstream. Se alguns dados de entrada ainda não foram processados, a marca-d'água de saída talvez seja retida, o que afeta a atualização de dados.
Latência do sistema (com e sem Streaming Engine)
A latência do sistema é o número máximo atual de segundos que um item de dados ficou processando ou aguardando processamento. Essa métrica indica quanto tempo um elemento aguarda dentro de qualquer fonte no pipeline. A duração máxima é ajustada após o processamento. Os casos a seguir são considerações extras:
- Para várias fontes e coletores, a latência do sistema é o tempo máximo que um elemento aguarda dentro de uma fonte antes de ser gravado em todos os coletores.
- Às vezes, uma fonte não fornece um valor do período de tempo em que um elemento aguarda dentro da fonte. Além disso, o elemento pode não ter metadados para definir o horário do evento. Nesse cenário, a latência do sistema é calculada desde o momento em que o pipeline recebe o elemento pela primeira vez.
Bytes do backlog (com e sem o Streaming Engine)
O gráfico Bytes de backlog mostra a quantidade de entradas não processadas conhecidas de um estágio em bytes. Esta métrica compara os bytes restantes a serem consumidos por cada estágio em relação aos estágios upstream. Para que essa métrica seja informada com precisão, cada origem ingerida pelo pipeline precisa ser configurada corretamente. Origens nativas, como o Pub/Sub e o BigQuery, já são compatíveis imediatamente. No entanto, algumas origenspersonalizadas precisam de implementação extra. Para mais detalhes, consulte escalonamento automático para fontes ilimitadas personalizadas.
Paralelismo (somente Streaming Engine)
O gráfico Processamento paralelo mostra o número aproximado de chaves em uso para o processamento de dados de cada estágio. O Dataflow é escalonável com base no paralelismo de um pipeline. No Dataflow, o paralelismo de um pipeline é uma estimativa do número de linhas de execução necessárias para processar os dados com mais eficiência em um determinado momento. O processamento de qualquer chave é serializado para que o número total de chaves em um estágio represente o paralelismo máximo disponível no estágio. As métricas de paralelismo podem ser úteis para encontrar teclas de atalho ou gargalos em pipelines lentos ou travados.
Cópias (somente Streaming Engine)
O gráfico Cópias mostra o número de mensagens processadas por uma fase específica que foram filtradas como cópias.
O Dataflow é compatível com muitas origens e coletores que garantem a entrega de at least once. A desvantagem da exibição de at least once é que ela pode resultar em cópias.
O Dataflow garante a entrega exactly once, o que significa que as cópias são filtradas automaticamente.
Os estágios downstream são salvos do reprocessamento dos mesmos elementos, o que garante que o estado e as saídas não sejam afetados.
Para otimizar o pipeline para recursos e desempenho, reduza o número de cópias produzidas em cada estágio.
Métricas de entrada e saída
As métricas de entrada e de saída serão exibidas se o job de streaming do Dataflow ler ou gravar registros usando o Pub/Sub.
Todas as métricas de entrada do mesmo tipo são combinadas, e todas as métricas de saída também são combinadas. Por exemplo, todas as métricas do Pub/Sub são agrupadas em uma seção. Cada tipo de métrica é organizado em uma seção separada. Para mudar as métricas exibidas, selecione a seção à esquerda que melhor representa as métricas que você está procurando. As imagens a seguir mostram todas as seções disponíveis.
Os três gráficos a seguir são exibidos nas seções Métricas de entrada e Métricas de saída.
Solicitações por segundo
Solicitações por segundo é a taxa de solicitações de API para ler ou gravar dados pela origem ou coletor ao longo do tempo. Se essa taxa cair para zero ou diminuir significativamente por um período prolongado em relação ao comportamento esperado, o pipeline talvez esteja impedido de executar determinadas operações. Além disso, talvez não haja dados para ler. Nesse caso, analise as etapas do job que tiverem uma marca d'água de sistema alta. Examine também os registros de worker para verificar se há erros ou indicações sobre o processamento lento.
Erros de resposta por segundo de acordo com o tipo de erro
A taxa de erros de resposta por segundo por tipo de erro é a taxa de solicitações de API para ler ou gravar dados com falha por origem ou por coletor ao longo do tempo. Se esses erros ocorrerem com frequência, essas solicitações de API podem atrasar o processamento. As solicitações de API com falha precisam ser investigadas. Para ajudar a resolver esses problemas, consulte a documentação do código de erro de E/S e qualquer documentação de código de erro específica usada pela origem ou pelo coletor, como os códigos de erro do Pub/Sub.
Como usar o Metrics Explorer
É possível visualizar as seguintes métricas de E/S do Dataflow no Metrics Explorer:
job/pubsub/write_count: solicitações de publicação do Pub/Sub de PubsubIO.Write em jobs do Dataflow.job/pubsub/read_count: solicitações de envio do Pub/Sub de Pubsub.IO.Read em jobs do Dataflow.job/bigquery/write_count: solicitações de publicação do BigQuery do BigQueryIO.Write em jobs do Dataflow. As métricasjob/bigquery/write_countestão disponíveis em pipelines do Python usando a transformação WriteToBigQuery commethod='STREAMING_INSERTS'ativado no Apache Beam v2.28.0 ou posterior.
Para acessar a lista completa de métricas do Dataflow, consulte a documentação sobre métricas do Google Cloud.
Alterações futuras nas métricas do Pub/Sub (somente Streaming Engine)
O Streaming Engine usa o Pull síncrono para consumir dados do Pub/Sub. No entanto, a partir de fevereiro de 2022, migraremos para o Pull de streaming para melhorar o desempenho. As métricas e os gráficos existentes de Solicitações por segundo e Erros de resposta por segundo são apropriados apenas para o pull síncrono. Vamos adicioinar uma métrica sobre a integridade das conexões de pull de streaming e quaisquer erros que encerram essas conexões.
A migração não exigirá qualquer envolvimento dos usuários. Durante a migração, um job pode estar usando o pull síncrono por um período de tempo e o pull de streaming por outro período. Portanto, o mesmo job pode mostrar as métricas de pull síncrono por um período de tempo e as métricas de pull de streaming por outro período. Após a conclusão da migração, as métricas de pull síncrono serão removidas da IU.
A migração também afetará as métricas job/pubsub/read_count e
job/pubsub/read_latencies no Cloud Monitoring. Esses contadores não serão
incrementados enquanto um job estiver usando o pull de streaming.
Os jobs de streaming que não usam o Streaming Engine não serão migrados para o Streaming Pull e não serão afetados por essa alteração. Eles continuarão a exibir as métricas de pull síncrono.
Para mais informações sobre a migração do pull de streaming, acesse a página Streaming com o Pub/Sub.
Se você tiver dúvidas sobre essa alteração, entre em contato com sua equipe de conta.
Como visualizar um pipeline
Quando você seleciona um job específico do Dataflow, a interface de monitoramento mostra informações sobre o pipeline desse job. Essas informações incluem uma representação gráfica do pipeline à medida que ele é executado no serviço Dataflow, um resumo do job, um registro do job e informações sobre cada etapa do pipeline.
A interface de monitoramento do Dataflow fornece uma representação gráfica do pipeline: o gráfico de execução. O gráfico de execução de um pipeline representa cada transformação no pipeline como uma caixa. Cada caixa contém o nome da transformação e as informações sobre o status do job, que incluem o seguinte:
- Em execução: a etapa está em execução.
- Em fila: a etapa em que um job do FlexRS entra na fila.
- Com êxito: a etapa foi concluída com sucesso.
- Parado: a etapa foi interrompida porque o job parou.
- Desconhecido: a etapa falhou ao informar o status.
- Com falha: a etapa não foi concluída.
Gráfico de execução básica
Código do pipeline:Java
// Read the lines of the input text.
p.apply("ReadLines", TextIO.read().from(options.getInputFile()))
// Count the words.
.apply(new CountWords())
// Write the formatted word counts to output.
.apply("WriteCounts", TextIO.write().to(options.getOutput()));
Python
(
pipeline
# Read the lines of the input text.
| 'ReadLines' >> beam.io.ReadFromText(args.input_file)
# Count the words.
| CountWords()
# Write the formatted word counts to output.
| 'WriteCounts' >> beam.io.WriteToText(args.output_path))
|
Gráfico de execução:
|
Transformações compostas
No gráfico de execução, as transformações compostas (aquelas que contêm várias subtransformações aninhadas) são expansíveis. Transformações compostas expansíveis são marcadas com uma seta no gráfico. Clique na seta para expandir a transformação e visualizar as subtransformações internas.
Código do pipeline:Java
// The CountWords Composite Transform
// inside the WordCount pipeline.
public static class CountWords
extends PTransform<PCollection<String>, PCollection<String>> {
@Override
public PCollection<String> apply(PCollection<String> lines) {
// Convert lines of text into individual words.
PCollection<String> words = lines.apply(
ParDo.of(new ExtractWordsFn()));
// Count the number of times each word occurs.
PCollection<KV<String, Long>> wordCounts =
words.apply(Count.<String>perElement());
return wordCounts;
}
}
Observação: na imagem à direita, Python
# The CountWords Composite Transform inside the WordCount pipeline.
@beam.ptransform_fn
def CountWords(pcoll):
return (
pcoll
# Convert lines of text into individual words.
| 'ExtractWords' >> beam.ParDo(ExtractWordsFn())
# Count the number of times each word occurs.
| beam.combiners.Count.PerElement()
# Format each word and count into a printable string.
| 'FormatCounts' >> beam.ParDo(FormatCountsFn()))
|
Gráfico de execução:
|
Nomes de transformação
O Dataflow tem algumas maneiras diferentes para chegar ao nome da transformação mostrado no gráfico de execução de monitoramento:
Java
- O Dataflow pode usar um nome já atribuído quando você aplica a transformação. O primeiro
argumento fornecido para o método
applyé o nome da transformação. - O Dataflow pode inferir o nome da transformação, seja do nome da classe, se você criou uma transformação personalizada, ou do nome do objeto de função
DoFn, se você estiver usando uma transformação básica, comoParDo.
Python
- O Dataflow pode usar um nome já atribuído quando você aplica a transformação. Para definir o nome da transformação, especifique o argumento
labeldela. - O Dataflow pode inferir o nome da transformação, seja do nome da classe, se você criou uma transformação personalizada, ou do nome do objeto de função
DoFn, se você estiver usando uma transformação básica, comoParDo.
Como interpretar as métricas
Tempo decorrido real
Quando você clica em uma etapa, a métrica de Tempo decorrido é exibida no painel Informações da etapa. Esta métrica fornece o tempo total aproximado gasto por meio de todas as linhas de execução em todos os workers nas ações a seguir:
- Inicialização da etapa
- Processamento dos dados
- Embaralhamento dos dados
- Finalização da etapa
Para etapas compostas, o tempo decorrido informa a soma do tempo gasto nas etapas do componente. Essa estimativa pode ajudar a identificar etapas lentas e diagnosticar qual parte do pipeline está demorando mais tempo do que o necessário.
Métricas de entrada secundária
As métricas de entrada secundária mostram como os algoritmos e os padrões de acesso de entradas secundárias (em inglês) afetam o desempenho do pipeline. Quando o pipeline usa uma entrada secundária, o Dataflow grava a coleção em uma camada permanente (como um disco) e as transformações são lidas nessa coleção permanente. Essas leituras e gravações afetam o tempo de execução do job.
A interface de monitoramento do Dataflow exibe métricas de entrada secundária quando você seleciona uma transformação que cria ou consome uma coleção de entrada secundária. É possível ver as métricas na seção Métricas de entrada secundária do painel Informações da etapa.
Transformações que criam uma entrada secundária
Se a transformação selecionada criar uma coleção de entrada secundária, a seção Métricas de entrada secundária exibirá o nome da coleção, junto com as seguintes métricas:
- Tempo gasto na gravação: o tempo gasto gravando a coleção de entrada secundária.
- Bytes gravados: o número total de bytes gravados na coleção de entrada secundária.
- Tempo de leitura da entrada secundária e bytes lidos: uma tabela que contém outras métricas para todas as transformações que consomem a coleção de entradas secundárias, chamadas de consumidores de entrada secundária.
A tabela Tempo de leitura da entrada secundária e bytes lidos exibe as seguintes informações para cada consumidor de entrada secundária:
- Consumidor de entrada secundária: o nome da transformação do consumidor de entrada secundária.
- Tempo gasto lendo: o tempo que esse consumidor gastou lendo a coleção de entrada secundária.
- Bytes lidos: o número de bytes que este consumidor leu da coleção de entrada secundária.
Se o pipeline tiver uma transformação composta que crie uma entrada secundária, expanda a transformação composta até que a subtransformação específica que cria a entrada secundária esteja visível. Depois, selecione essa subtransformação para visualizar a seção Métricas de entrada secundária.
A Figura 5 mostra as métricas de entrada secundária de uma transformação que cria uma coleção de entrada secundária.
MakeMapView). A subtransformação que cria a
entrada secundária (CreateDataflowView) está selecionada e as
métricas de entrada secundária podem ser visualizadas no painel lateral Informações da etapa.Transformações que consomem uma ou mais entradas secundárias
Se a transformação selecionada consumir uma ou mais entradas secundárias, a seção Métricas de entrada secundária exibirá a tabela Tempo de leitura da entrada secundária e bytes lidos. Nesta tabela, as seguintes informações para cada coleção de entrada secundária são exibidas:
- Coleção de entrada secundária: o nome da coleção de entrada secundária.
- Tempo gasto na leitura: o tempo que a transformação gastou lendo a coleção de entrada secundária.
- Bytes lidos: o número de bytes que a transformação leu da coleção de entrada secundária.
Se o pipeline tiver uma transformação composta que crie uma entrada secundária, expanda a transformação composta até que a subtransformação específica que lê a entrada secundária esteja visível. Depois, selecione essa subtransformação para visualizar a seção Métricas de entrada secundária.
A Figura 6 mostra as métricas de entrada secundária de uma transformação que lê uma coleção de entrada secundária.
JoinBothCollections faz leituras em uma coleção de entradas secundárias. JoinBothCollections está
selecionada no gráfico de execução e as métricas de entrada secundária podem ser
visualizadas no painel lateral Informações da etapa.Como identificar problemas de desempenho de entrada secundária
A reiteração é um problema comum de desempenho da entrada secundária. Se a entrada secundária PCollection for muito grande, os workers não poderão armazenar em cache a coleção inteira na memória.
Como resultado, os workers leem repetidamente a coleção de entrada secundária permanente.
Na figura 7, as métricas de entrada secundária mostram que o total de bytes lidos da coleção de entrada secundária é muito maior que o tamanho da coleção (total de bytes gravados).
Para melhorar o desempenho desse pipeline, recrie o algoritmo para evitar iterar ou refazer os dados de entrada secundária. Neste exemplo, o pipeline cria o produto cartesiano de duas coleções. O algoritmo itera toda a coleção de entrada secundária para cada elemento da coleção principal. Você pode melhorar o padrão de acesso do pipeline ao agrupar vários elementos da coleção principal. Essa alteração reduz o número de vezes que os workers releem a coleção de entrada secundária.
Outro problema comum de desempenho pode ocorrer se o pipeline executar uma mesclagem aplicando uma ParDo com uma ou mais entradas secundárias grandes. Nesse caso,
os workers dedicam uma grande porcentagem do tempo de processamento para a operação de junção que leem as
coleções de entrada secundárias.
A Figura 8 mostra um exemplo de métricas de entrada secundária para esse problema:
JoinBothCollections tem
um tempo de processamento total de 18 minutos e 31 segundos. Os workers passam a
maior parte desse tempo (10 minutos e 3 segundos) na leitura da
coleção de entrada secundária de 10 GB.Para melhorar o desempenho desse canal, use CoGroupByKey em vez de entradas secundárias.
Recomendações e diagnósticos
O Dataflow fornece recomendações para melhorar o desempenho do job, reduzir custos e solucionar erros. Esta seção explica como analisar e interpretar as recomendações. Lembre-se de que algumas recomendações podem não ser relevantes para seu caso de uso.
Diagnósticos
A guia Diagnóstico em Registros coleta e exibe determinadas entradas de registro produzidas nos pipelines. Isso inclui mensagens que indicam um provável problema com o pipeline e mensagens de erro com stack traces. As entradas de registros coletadas são eliminadas e combinadas em grupos de erros.
O relatório de erros inclui as seguintes informações:
- uma lista de erros com mensagens de erro;
- o número de vezes que ocorreu cada erro;
- um histograma indicando quando ocorreu cada erro;
- a hora em que o erro ocorreu recentemente.
- a hora em que o erro ocorreu pela primeira vez.
- O status do erro.
Para visualizar o relatório de um erro específico, clique na descrição na coluna Erros. Será exibida a página Relatórios de erros. Se o erro for relacionado a um erro no serviço, um link adicional com a documentação de mais etapas será exibido ("Guia de solução de problemas").
Para saber mais sobre a página, consulte Como visualizar erros.
Silenciar um erro
Para desativar o silenciamento de uma mensagem, abra a guia Diagnóstico, clique no erro que você quer silenciar e abra o menu de status da resolução (identificado como: Abrir | Reconhecido | Resolvido | Silenciado) e selecione Silenciado.
Recomendações
A guia Recomendações exibe insights do Dataflow sobre o pipeline. O objetivo desses insights é identificar situações em que possam ser feitas melhorias no custo e no desempenho.
A coluna Data de atualização indica a última vez que um insight foi observado. As recomendações serão armazenadas por 30 dias a partir da data de atualização.
Acesso programático a recomendações
Para acesso programático a recomendações, use a API Recommender.
Dispensar uma recomendação
É possível dispensar uma recomendação no hub de recomendações do seu projeto.
Para dispensar uma recomendação, clique no menu de navegação no canto superior esquerdo do console do Cloud e selecione Página inicial > Recomendações. No card "Diagnóstico do Dataflow", clique em Ver tudo, selecione a recomendação que você quer dispensar e clique em Dispensar.
A seguir
Leia como usar Detalhes da execução para otimizar um job do Dataflow
Explore o Cloud Monitoring para criar alertas e visualizar métricas do Dataflow, incluindo métricas personalizadas.
Saiba mais sobre como criar pipelines de dados prontos para produção