# Sobre o monitoramento de trabalhos do AWS Glue Streaming
O monitoramento do trabalho de streaming corresponde a uma parte crítica do desenvolvimento do pipeline de ETL. Além de usar a interface de usuário do Spark, você também pode usar o Amazon CloudWatch para monitorar as métricas. Abaixo é apresentada uma lista de métricas de streaming emitidas pela estrutura do AWS Glue. Para obter uma lista completa de todas as métricas do AWS Glue, consulte [Monitorar o AWS Glue usando métricas do Amazon CloudWatch](https://docs.aws.amazon.com/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html).
O AWS Glue usa uma estrutura de streaming articulada para processar os eventos de entrada. É possível usar a API do Spark diretamente em seu código ou aproveitar o `ForEachBatch` fornecido por `GlueContext`, que publica essas métricas. Para compreender essas métricas, primeiro, é necessário compreender `windowSize`.
**windowSize**: `windowSize` corresponde ao intervalo de micro lote que você fornece. Se você especificar um tamanho da janela de 60 segundos, o trabalho de streaming do AWS Glue aguardará 60 segundos (ou mais, se o lote anterior ainda não tiver sido concluído) antes de ler os dados em um lote da fonte de streaming e aplicar as transformações fornecidas em `ForEachBatch`. Isso também é conhecido como intervalo de acionamento.
Analisaremos as métricas com mais detalhes para compreender as características de integridade e de performance.
**nota**
As métricas são emitidas a cada 30 segundos. Se o `windowSize` tiver menos de 30 segundos, as métricas relatadas corresponderão a uma agregação. Por exemplo, suponhamos que o `windowSize` tenha dez segundos e você esteja processando 20 registros por micro lote de forma contínua. Neste cenário, o valor da métrica emitida para numRecords seria 60.
Uma métrica não será emitida se não houver dados disponíveis para ela. Além disso, no caso de uma métrica de atraso do consumidor, é necessário habilitar o recurso para obter métricas para ela.
# Visualizar métricas de streaming do AWS Glue
Para traçar métricas visuais:
1. Acesse **Métricas** no console do Amazon CloudWatch e, em seguida, escolha a guia **Procurar**. Em seguida, selecione **Glue** em "Namespaces personalizados".
![\[A captura de tela mostra o acesso às métricas no console do Amazon CloudWatch ao monitorar trabalhos de streaming do AWS Glue.\]](http://docs.aws.amazon.com/pt_br/glue/latest/dg/images/streaming-monitoring-1.png)
1. Escolha **Métricas de trabalho** para que as métricas de todos os seus trabalhos sejam apresentadas.
1. Filtre as métricas com base em JobName=glue-feb-monitoring e, em seguida, em JobRunId=ALL. É possível clicar no sinal “\$1”, conforme mostrado na figura abaixo, para fazer adições ao filtro de pesquisa.
1. Selecione a caixa de seleção das métricas nas quais você tem interesse. Na figura abaixo, selecionamos `numberAllExecutors` e `numberMaxNeededExecutors`.
![\[A captura de tela mostra a aplicação de uma média às métricas durante o monitoramento de trabalhos de streaming.\]](http://docs.aws.amazon.com/pt_br/glue/latest/dg/images/streaming-monitoring-2.png)
1. Depois de selecionar essas métricas, é possível acessar a guia **Métricas em gráficos** e aplicar suas estatísticas.
1. Como as métricas são emitidas a cada minuto, você pode aplicar a “média” ao longo de um minuto para `batchProcessingTimeInMs` e `maxConsumerLagInMs`. Para `numRecords`, é possível aplicar a “soma” ao longo de cada minuto.
1. Você pode adicionar uma anotação horizontal `windowSize` à sua representação em gráfico usando a guia **Opções**.
![\[A captura de tela mostra a adição de uma anotação windowSize à sua representação em gráfico ao monitorar trabalhos de streaming.\]](http://docs.aws.amazon.com/pt_br/glue/latest/dg/images/streaming-monitoring-3.png)
1. Depois de selecionar as métricas, crie um painel e realize as adições. Veja a seguir um painel de amostra.
![\[A captura de tela mostra uma amostra de painel para monitorar trabalhos de streaming.\]](http://docs.aws.amazon.com/pt_br/glue/latest/dg/images/streaming-monitoring-4.png)
# Usar métricas do AWS Glue Streaming
Essa seção descreve cada uma das métricas e como elas se correlacionam entre si.
## Número de registros (métrica: streaming.numRecords)
Essa métrica indica quantos registros estão sendo processados.
![\[A captura de tela mostra o monitoramento do número de registros em trabalhos de streaming.\]](http://docs.aws.amazon.com/pt_br/glue/latest/dg/images/streaming-monitoring-5numrecords.png)
Essa métrica de streaming fornece visibilidade sobre o número de registros que você está processando em uma janela. Além do número de registros que estão sendo processados, ela ajudará você a compreender o comportamento do tráfego de entrada.
+ O indicador n.º 1 mostra um exemplo de tráfego estável sem aumentos. Normalmente, serão aplicações, como sensores de IoT, que coletam dados em intervalos regulares e os enviam para a fonte de streaming.
+ O indicador n.º 2 mostra um exemplo de um aumento repentino no tráfego em uma carga estável. Isso pode acontecer em uma aplicação de fluxo de cliques quando há um evento de marketing, como a Black Friday, e ocorre um aumento no número de cliques.
+ O indicador n.º 3 mostra um exemplo de tráfego imprevisível. O tráfego imprevisível significa que há um problema. É somente a natureza dos dados de entrada. Ao retornarmos ao exemplo do sensor de IoT, é possível imaginar centenas de sensores que enviam eventos de mudanças climáticas para a fonte de streaming. Como a mudança climática não é previsível, os dados também não o são. A compreensão do padrão de tráfego é fundamental para dimensionar seus executores. Se a entrada tiver um amplo aumento, considere usar o ajuste de escala automático (falaremos mais sobre isso posteriormente).
![\[A captura de tela mostra o monitoramento usando o número de registros e as métricas PutRecords do Kinesis em trabalhos de streaming.\]](http://docs.aws.amazon.com/pt_br/glue/latest/dg/images/streaming-monitoring-6putrecords.png)
É possível combinar essa métrica com a métrica PutRecords do Kinesis para garantir que o número de eventos que estão sendo ingeridos e o número de registros que estão sendo lidos sejam praticamente semelhantes. Isso é especialmente útil quando você está tentando compreender o atraso. À medida que a taxa de ingestão aumenta, o mesmo acontece com os `numRecords` lidos pelo AWS Glue.
## Tempo de processamento em lote (métrica: streaming.batchProcessingTimeInMs)
A métrica de tempo de processamento em lote ajuda a determinar se o cluster está com provisionamento insuficiente ou excessivo.
![\[A captura de tela mostra o monitoramento do tempo de processamento em lote em trabalhos de streaming.\]](http://docs.aws.amazon.com/pt_br/glue/latest/dg/images/streaming-monitoring-7batchprocess.png)
Essa métrica indica o número de milissegundos necessários para processar cada micro lote de registros. Aqui, o principal objetivo é monitorar esse tempo para garantir que seja menor que o intervalo de `windowSize`. Não há problema se `batchProcessingTimeInMs` for temporariamente desativado, desde que se recupere no intervalo de janela seguinte. O indicador n.º 1 mostra um tempo mais ou menos estável necessário para o processamento do trabalho. No entanto, se o número de registros de entrada estiver aumentando, o tempo necessário para o processamento do trabalho aumentará, conforme mostrado pelo indicador n.º 2. Se o `numRecords` não estiver aumentando, mas o tempo de processamento estiver, você precisará examinar o processamento do trabalho nos executores de forma mais aprofundada. É uma boa prática definir um limite e um alarme para garantir que `batchProcessingTimeInMs` não ultrapasse 120% por mais de dez minutos. Para obter mais informações sobre como configurar alarmes, consulte [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
## Atraso do consumidor (métrica: streaming.maxConsumerLagInMs)
A métrica de atraso do consumidor ajuda a entender se há um atraso no processamento de eventos. Se o atraso for muito elevado, você poderá perder o SLA de processamento do qual sua empresa depende, mesmo que tenha um windowSize correto. Você deve habilitar explicitamente essas métricas usando a opção de conexão `emitConsumerLagMetrics`. Para obter mais informações, consulte [KinesisStreamingSourceOptions](https://docs.aws.amazon.com/glue/latest/webapi/API_KinesisStreamingSourceOptions.html).
![\[A captura de tela mostra o atraso de monitoramento em trabalhos de streaming.\]](http://docs.aws.amazon.com/pt_br/glue/latest/dg/images/streaming-monitoring-8lag.png)
## Métricas derivadas
Para obter insights mais aprofundados, é possível criar métricas derivadas para compreender mais sobre os trabalhos de streaming no Amazon CloudWatch.
![\[A captura de tela mostra o monitoramento de métricas derivadas em trabalhos de streaming.\]](http://docs.aws.amazon.com/pt_br/glue/latest/dg/images/streaming-monitoring-9derived.png)
É possível desenvolver uma representação em gráfico com métricas derivadas para decidir se precisa usar mais DPUs. Embora o ajuste de escala automático ajude você a fazer isso automaticamente, é possível usar métricas derivadas para determinar se o ajuste de escala automático está funcionando de maneira eficaz.
+ **InputRecordsPerSecond** indica a taxa na qual você está obtendo registros de entrada. A derivação ocorre da seguinte forma: número de registros de entrada (glue.driver.streaming.numRecords)/WindowSize.
+ **ProcessingRecordsPerSecond** indica a taxa na qual os registros estão sendo processados. A derivação ocorre da seguinte forma: número de registros de entrada (glue.driver.streaming.numRecords)/batchProcessingTimeInMs.
Se a taxa de entrada for superior à taxa de processamento, talvez seja necessário adicionar mais capacidade para processar os trabalhos ou aumentar o paralelismo.
## Métricas do ajuste de escala automático
Quando o tráfego de entrada tiver um amplo aumento, considere habilitar o ajuste de escala automático e especificar o número máximo de trabalhadores. Com isso você obtém duas métricas adicionais, `numberAllExecutors` e `numberMaxNeededExecutors`.
+ **numberAllExecutors** corresponde ao número de executores de trabalhos em execução ativa.
+ **numberMaxNeededExecutors** corresponde ao número máximo de executores de trabalhos (em execução ativa e pendentes) necessários para satisfazer a carga atual.
Essas duas métricas ajudarão você a entender se o ajuste de escala automático está funcionando corretamente.
![\[A captura de tela mostra o monitoramento do ajuste de escala automático em trabalhos de streaming.\]](http://docs.aws.amazon.com/pt_br/glue/latest/dg/images/streaming-monitoring-10autoscaling.png)
O AWS Glue monitorará a métrica `batchProcessingTimeInMs` em alguns micro lotes e fará uma entre duas coisas. Ele aumentará a escala horizontalmente dos executores, se `batchProcessingTimeInMs` estiver mais próximo de `windowSize`, ou reduzirá a escala horizontalmente dos executores, se `batchProcessingTimeInMs` for comparativamente menor que `windowSize`. Além disso, ele usará um algoritmo para escalar os executores em etapas.
+ O indicador n.º 1 mostra como os executores ativos aumentaram a escala verticalmente para alcançar o número máximo de executores necessários para o processamento da carga.
+ O indicador n.º 2 mostra como os executores ativos reduziram a escala horizontalmente desde que `batchProcessingTimeInMs` estava baixo.
É possível usar essas métricas para monitorar o paralelismo atual no nível do executor e ajustar, adequadamente, o número máximo de trabalhadores em sua configuração de ajuste de escala automático.
## Como obter a melhor performance
O Spark tentará criar uma tarefa por fragmento para leitura no fluxo do Amazon Kinesis. Os dados em cada fragmento se tornam uma partição. Em seguida, ele distribuirá essas tarefas entre os executores e os trabalhadores, dependendo do número de núcleos em cada trabalhador (o número de núcleos por trabalhador depende do tipo de trabalhador que você selecionar, por exemplo, `G.025X`, `G.1X`, entre outros). No entanto, não é determinística a forma como as tarefas são distribuídas. Todas as tarefas são executadas em paralelo em seus respectivos núcleos. As tarefas serão enfileiradas se houver mais fragmentos do que o número de núcleos executores disponíveis.
É possível usar uma combinação das métricas acima e do número de fragmentos para provisionar os executores para uma carga estável com algum espaço para aumentos. É recomendável executar algumas iterações do seu trabalho para determinar o número aproximado de trabalhadores. Para uma workload instável ou com amplo aumento, é possível fazer o mesmo ao configurar o ajuste de escala automático e o número máximo de trabalhadores.
Defina o `windowSize` de acordo com os requisitos de SLA da sua empresa. Por exemplo, se sua empresa exigir que os dados processados não podem ficar obsoletos por mais de 120 segundos, defina `windowSize` para, no mínimo, 60 segundos, de modo que o atraso médio do consumidor seja inferior a 120 segundos (consulte a seção sobre atraso do consumidor acima). A partir desse ponto, dependendo dos `numRecords` e do número de fragmentos, planeje a capacidade em DPUs, certificando-se de que `batchProcessingTimeInMs` seja inferior a 70% do `windowSize` na maioria das vezes.
**nota**
Os fragmentos ativos podem causar distorção de dados, o que significa que alguns fragmentos e partições são muito maiores do que outros. Isso pode fazer com que algumas tarefas executadas em paralelo demorem mais, causando tarefas retardatárias. Como resultado, o próximo lote só poderá ser iniciado quando todas as tarefas do anterior forem concluídas. Isso afetará o `batchProcessingTimeInMillis` e o atraso máximo.