# Acerca de la supervisión de los trabajos de AWS Glue Streaming
Supervisar el trabajo de transmisión es una parte fundamental de la creación de su canalización de ETL. Además de usar la interfaz de usuario de Spark, también puede usar Amazon CloudWatch para supervisar las métricas. A continuación se muestra una lista de las métricas de transmisión que emite el marco de AWS Glue. Para obtener una lista completa de todas las métricas de AWS Glue, consulte [Supervisión de AWS Glue mediante métricas de Amazon CloudWatch](https://docs.aws.amazon.com/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html).
AWS Glue usa un marco de transmisión estructurado para procesar los eventos de entrada. Puede usar la API de Spark directamente en el código o aprovechar `ForEachBatch` que proporciona `GlueContext`, que publica estas métricas. Para entender estas métricas, primero debemos entender `windowSize`.
**windowSize**: `windowSize` es el intervalo de microlotes que usted proporciona. Si especifica un tamaño de ventana de 60 segundos, el trabajo de transmisión de AWS Glue esperará 60 segundos (o más si el lote anterior no se ha completado para entonces) antes de leer los datos de un lote procedentes del origen de transmisión y aplicar las transformaciones incluidas en `ForEachBatch`. Esto también se denomina intervalo de activación.
Revisemos las métricas con más detalle para comprender las características de estado y rendimiento.
**nota**
Estas métricas se emiten cada 30 segundos. Si `windowSize` tiene menos de 30 segundos, las métricas informadas son una agregación. Por ejemplo, supongamos que `windowSize` tiene 10 segundos y que está procesando 20 registros de forma constante por microlote. En este escenario, el valor métrico emitido de numRecords sería 60.
No se emite una métrica si no hay datos disponibles para ella. Además, en el caso de la métrica de retraso de consumo, debe habilitar la característica para obtener las métricas correspondientes.
# Visualización de métricas de AWS Glue Streaming
Para trazar métricas visuales:
1. Vaya a **Métricas** en la consola de Amazon CloudWatch y, a continuación, seleccione la pestaña **Examinar**. Luego elija **Glue** en “Espacios de nombres personalizados”.
![\[En la captura de pantalla se muestra el acceso a las métricas en la consola Amazon CloudWatch cuando se supervisan los trabajos de transmisión de AWS Glue.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/streaming-monitoring-1.png)
1. Seleccione **Métricas de trabajo** para ver las métricas de todos sus trabajos.
1. Filtre las métricas en función de JobName=glue-feb-monitoring y, a continuación, JobRunId=ALL. Puede hacer clic en el signo “\$1”, como se muestra en la siguiente figura, para agregarlo al filtro de búsqueda.
1. Seleccione la casilla de verificación de las métricas que le interesen. En la siguiente figura, hemos seleccionado `numberAllExecutors` y `numberMaxNeededExecutors`.
![\[En la captura de pantalla se muestra cómo aplicar un promedio a las métricas al supervisar los trabajos de transmisión.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/streaming-monitoring-2.png)
1. Una vez que haya seleccionado estas métricas, puede ir a la pestaña **Métricas diagramadas** y aplicarlas.
1. Como las métricas se emiten cada minuto, puede aplicar el “promedio” a lo largo de un minuto para obtener `batchProcessingTimeInMs` y `maxConsumerLagInMs`. Para `numRecords`, puede aplicar la “suma” a cada minuto.
1. Puede agegar una anotación horizontal de `windowSize` a su gráfico mediante la pestaña **Opciones**.
![\[En la captura de pantalla se muestra cómo agregar una anotación de windowSize al gráfico cuando se supervisan los trabajos de transmisión.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/streaming-monitoring-3.png)
1. Una vez que haya seleccionado las métricas, cree un panel y agréguelo. A continuación, se ofrece un panel de ejemplo.
![\[En la captura de pantalla se muestra un panel de ejemplo para supervisar los trabajos de transmisión.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/streaming-monitoring-4.png)
# Uso de métricas de AWS Glue Streaming
En esta sección, se describe cada una de las métricas y cómo se relacionan entre sí.
## Número de registros (métrica: streaming.numRecords)
Esta métrica indica cuántos registros se están procesando.
![\[En la captura de pantalla se muestra cómo se supervisa el número de registros en los trabajos de transmisión.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/streaming-monitoring-5numrecords.png)
Esta métrica de transmisión proporciona la visibilidad del número de registros que se están procesando en una ventana. Además de la cantidad de registros que se están procesando, también lo ayudará a comprender el comportamiento del tráfico de entrada.
+ El indicador n.º 1 es un ejemplo de un tráfico estable sin ráfagas. Por lo general, se trata de aplicaciones como los sensores de IoT que recopilan datos en intervalos regulares y los envían al origen de transmisión.
+ El indicador n.º 2 es un ejemplo de una ráfaga repentina de tráfico en una carga que, por lo demás, es estable. Esto podría ocurrir en una aplicación de secuencias de clics cuando se lleva a cabo un evento de marketing, como el Black Friday, y se produce un aumento en el número de clics.
+ El indicador n.º 3 es un ejemplo de tráfico impredecible. El tráfico impredecible no significa que hay un problema. Es simplemente la naturaleza de los datos de entrada. Volviendo al ejemplo de los sensores de IoT, puede pensar en cientos de sensores que envían eventos de cambio climático al origen de transmisión. Como el cambio climático no es predecible, tampoco lo son los datos. Comprender el patrón de tráfico es clave para ajustar el tamaño de los ejecutores. Si la entrada tiene muchos picos, puede considerar usar el escalado automático (hablaremos de esto más adelante).
![\[En la captura de pantalla se muestra cómo se supervisa el número de registros y las métricas PutRecords de Kinesis en los trabajos de transmisión.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/streaming-monitoring-6putrecords.png)
Puede combinar esta métrica con la métrica PutRecords de Kinesis para asegurarse de que el número de eventos que se ingiere y el número de registros que se leen son prácticamente iguales. Esto es útil en especial cuando se trata de entender el retraso. A medida que aumenta la tasa de ingesta, también lo hace la lectura de `numRecords` por parte de AWS Glue.
## Tiempo de procesamiento por lotes (métrica: streaming.batchProcessingTimeInMs)
La métrica del tiempo de procesamiento por lotes lo ayuda a determinar si el clúster está infra o sobreaprovisionado.
![\[En la captura de pantalla se muestra cómo se supervisa el tiempo de procesamiento por lotes en los trabajos de transmisión.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/streaming-monitoring-7batchprocess.png)
Esta métrica indica el número de milisegundos que se tardó en procesar cada microlote de registros. El objetivo principal aquí es supervisar este tiempo para asegurarse de que sea inferior al intervalo de `windowSize`. No hay problema si `batchProcessingTimeInMs` se suspende temporalmente, siempre y cuando se recupere en el siguiente intervalo. El indicador n.º 1 representa un tiempo más o menos estable que se tarda en procesar el trabajo. Sin embargo, si el número de registros de entrada aumenta, el tiempo necesario para procesar el trabajo aumentará, tal como se muestra en el indicador n.º 2. Si `numRecords` no aumenta, pero el tiempo de procesamiento sí, entonces tendrá que analizar más a fondo el procesamiento de los trabajos en los ejecutores. Es una buena práctica establecer un umbral y una alarma para garantizar que `batchProcessingTimeInMs` no supere el 120 % durante más de 10 minutos. Para obtener más información acerca de la configuración de alarmas, consulte [Uso de alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
## Retraso de consumo (métrica: streaming.maxConsumerLagInMs)
La métrica de retraso de consumo lo ayuda a comprender si hay un retraso en el procesamiento de los eventos. Si el retraso es demasiado alto, es posible que no cumpla con el SLA de procesamiento del que depende su empresa, aunque tenga un windowSize correcto. Tiene que habilitar estas métricas de forma explícita mediante la opción de conexión de `emitConsumerLagMetrics`. Para obtener más información, consulte [KinesisStreamingSourceOptions](https://docs.aws.amazon.com/glue/latest/webapi/API_KinesisStreamingSourceOptions.html).
![\[En la captura de pantalla se muestra cómo se supervisa el retraso en los trabajos de transmisión.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/streaming-monitoring-8lag.png)
## Métricas derivadas
Para obtener información más detallada, puede crear métricas derivadas para comprender mejor sus trabajos de transmisión en Amazon CloudWatch.
![\[En la captura de pantalla se muestra cómo se supervisan las métricas derivadas en los trabajos de transmisión.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/streaming-monitoring-9derived.png)
Puede crear un gráfico con métricas derivadas para decidir si necesita usar más DPU. Si bien el escalado automático lo ayuda a hacerlo automáticamente, puede usar métricas derivadas para determinar si el escalado automático funciona de manera eficaz.
+ **InputRecordsPerSecond** indica la velocidad a la que se obtienen los registros de entrada. Se deriva de la siguiente manera: número de registros de entrada (glue.driver.streaming.numRecords)/ WindowSize.
+ **ProcessingRecordsPerSecond** indica la velocidad a la que se procesan los registros. Se deriva de la siguiente manera: número de registros de entrada (glue.driver.streaming.numRecords)/ batchProcessingTimeInMs.
Si la velocidad de entrada es superior a la velocidad de procesamiento, es posible que necesite agregar más capacidad para procesar el trabajo o aumentar el paralelismo.
## Métricas de escalado automático
Si el tráfico de entrada tiene picos, debería considerar la posibilidad de habilitar el escalado automático y especificar el número máximo de trabajos. Con eso, obtiene dos métricas adicionales: `numberAllExecutors` y `numberMaxNeededExecutors`.
+ **numberAllExecutors** es el número de ejecutores de trabajo que se ejecutan activamente.
+ **numberMaxNeededExecutors** es el número máximo de ejecutores de trabajos (en ejecución activa y pendientes) necesarios para satisfacer la carga actual.
Estas dos métricas lo ayudarán a entender si el escalado automático funciona correctamente.
![\[En la captura de pantalla se muestra cómo se supervisa el escalado automático en los trabajos de transmisión.\]](http://docs.aws.amazon.com/es_es/glue/latest/dg/images/streaming-monitoring-10autoscaling.png)
AWS Glue supervisará la métrica `batchProcessingTimeInMs` en unos pocos microlotes y hará una de las siguientes dos cosas: Si `batchProcessingTimeInMs` está más cerca de `windowSize`, escalará horizontalmente los ejecutores; si `batchProcessingTimeInMs` es inferior a `windowSize`, reducirá horizontalmente los ejecutores. Además, usará un algoritmo para escalar de forma escalonada los ejecutores.
+ El indicador n.º 1 representa cómo los ejecutores activos se escalaron verticalmente a fin de alcanzar el máximo número de ejecutores necesarios para procesar la carga.
+ El indicador n.º 2 representa cómo se redujeron horizontalmente los ejecutores activos debido a que `batchProcessingTimeInMs` era inferior.
Puede usar estas métricas para supervisar el paralelismo actual a nivel de ejecutor y ajustar el número máximo de trabajos en la configuración de escalado automático en consecuencia.
## Cómo obtener el mejor rendimiento
Spark intentará crear una tarea por fragmento para poder leerla en el flujo de Amazon Kinesis. Los datos de cada fragmento se convierten en una partición. Luego, distribuirá estas tareas entre los ejecutores o trabajos, en función del número de núcleos de cada trabajo (el número de núcleos por trabajo depende del tipo de trabajo que seleccione, como `G.025X`, `G.1X`, etc.). Sin embargo, la forma en que se distribuyen las tareas no es determinista. Todas las tareas se ejecutan en paralelo en sus respectivos núcleos. Si hay más fragmentos que el número de núcleos ejecutores disponibles, las tareas se ponen en cola.
Puede usar una combinación de las métricas anteriores y el número de fragmentos para aprovisionar los ejecutores a fin de garantizar una carga estable con espacio para las ráfagas. Se recomienda realizar algunas iteraciones del trabajo para determinar el número aproximado de trabajos. Para una carga de trabajo inestable o con picos, puede hacer lo mismo al configurar el escalado automático y el número máximo de trabajos.
Configure `windowSize` de acuerdo con los requisitos de SLA de su empresa. Por ejemplo, si su empresa exige que los datos procesados no puedan estar inactivos durante más de 120 segundos, configure `windowSize` en al menos 60 segundos, de forma que el retraso promedio de consumo sea inferior a 120 segundos (consulte la sección anterior acerca del retraso de consumo). A partir de ahí, en función de `numRecords` y del número de fragmentos, planifique la capacidad de las DPU asegurándose de que `batchProcessingTimeInMs` sea inferior al 70 % de `windowSize` la mayor parte del tiempo.
**nota**
Los fragmentos activos pueden distorsionar los datos, lo que significa que algunos fragmentos o particiones son mucho más grandes que otros. Esto puede provocar que algunas tareas que se ejecutan en paralelo tarden más tiempo, lo que genera que las tareas queden rezagadas. Como resultado, el siguiente lote no puede comenzar hasta que se hayan completado todas las tareas del anterior, lo que afectará `batchProcessingTimeInMillis` y el retraso máximo.