Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Informazioni sul monitoraggio dei lavori di AWS Glue streaming
Il monitoraggio dei processi di streaming è una parte fondamentale della creazione delle pipeline di ETL. Oltre a utilizzare l'interfaccia utente Spark, puoi anche utilizzare Amazon CloudWatch per monitorare le metriche. Di seguito è riportato un elenco delle metriche di streaming emesse dal framework. AWS Glue Per un elenco completo di tutte le AWS Glue metriche, consulta [Monitoraggio AWS Glue tramite i CloudWatch parametri Amazon](https://docs.aws.amazon.com/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html).
AWS Glue utilizza un framework di streaming strutturato per elaborare gli eventi di input. Puoi utilizzare l'API Spark direttamente nel tuo codice o sfruttare il valore `ForEachBatch` fornito da `GlueContext`, che pubblica questi parametri. Per comprendere questi parametri, dobbiamo prima capire `windowSize`.
**windowSize**: `windowSize` è l'intervallo di microbatch fornito. Se si specifica una dimensione della finestra di 60 secondi, il processo di AWS Glue streaming aspetterà 60 secondi (o più se il batch precedente non è stato completato entro tale data) prima di leggere i dati in un batch dalla sorgente di streaming e applicare le trasformazioni fornite in`ForEachBatch`. Questo valore viene chiamato anche intervallo di attivazione.
Esaminiamo i parametri in modo più dettagliato per comprendere le caratteristiche di integrità e prestazioni.
**Nota**
Questi parametri vengono emessi ogni 30 secondi. Se il valore `windowSize` fornito è inferiore a 30 secondi, i parametri riportati sono un'aggregazione. Ad esempio, supponiamo che il valore `windowSize` fornito sia di 10 secondi e che si stiano elaborando costantemente 20 record per microbatch. In questo scenario, il valore del parametro emesso per numRecords sarebbe 60.
Un parametro non viene emesso se per esso non sono disponibili dati. Inoltre, nel caso del parametro del ritardo del consumatore, è necessario abilitare la funzionalità per ottenere i parametri associati.
# Visualizzazione delle metriche di streaming AWS Glue
Per tracciare i parametri visivamente:
1. Vai a **Metrics** nella CloudWatch console Amazon, quindi seleziona la scheda **Sfoglia**. In "Spazi dei nomi personalizzati", scegli **Glue**.
![\[La schermata mostra l'accesso alle metriche nella CloudWatch console Amazon durante il monitoraggio dei lavori di AWS Glue streaming.\]](http://docs.aws.amazon.com/it_it/glue/latest/dg/images/streaming-monitoring-1.png)
1. Scegli **Parametri processo** per visualizzare i parametri di tutti i processi.
1. Filtra le metriche in base a JobName = glue-feb-monitoring e poi a =ALL. JobRunId Puoi fare clic sul segno "\$1", come mostrato nella figura seguente, per aggiungerlo al filtro di ricerca.
1. Seleziona la casella di controllo relativa ai parametri che ti interessano. Nella figura seguente abbiamo selezionato `numberAllExecutors` e `numberMaxNeededExecutors`.
![\[Lo screenshot mostra l'applicazione della media ai parametri durante il monitoraggio dei processi di streaming.\]](http://docs.aws.amazon.com/it_it/glue/latest/dg/images/streaming-monitoring-2.png)
1. Dopo aver selezionato questi parametri, puoi andare alla scheda **Parametri definiti** e applicare le tue statistiche.
1. Poiché i parametri vengono emesse ogni minuto, puoi applicare la "media" su un minuto per `batchProcessingTimeInMs` e `maxConsumerLagInMs`. Per `numRecords`, puoi applicare la "somma" per ogni minuto.
1. È possibile aggiungere un'annotazione `windowSize` orizzontale al grafico tramite la scheda **Opzioni**.
![\[Lo screenshot mostra l'aggiunta di un'annotazione windowSize al grafico durante il monitoraggio dei processi di streaming.\]](http://docs.aws.amazon.com/it_it/glue/latest/dg/images/streaming-monitoring-3.png)
1. Dopo aver selezionato i parametri, crea un pannello di controllo e aggiungilo. Di seguito è mostrato un pannello di controllo di esempio.
![\[Lo screenshot mostra un pannello di controllo di esempio per il monitoraggio dei processi di streaming.\]](http://docs.aws.amazon.com/it_it/glue/latest/dg/images/streaming-monitoring-4.png)
# Utilizzo delle metriche di AWS Glue streaming
Questa sezione descrive ciascuno dei parametri e il modo in cui sono correlati tra loro.
## Numero di record (parametro: streaming.numRecords)
Questo parametro indica quanti record sono in fase di elaborazione.
![\[Lo screenshot mostra il monitoraggio del numero di record nei processi di streaming.\]](http://docs.aws.amazon.com/it_it/glue/latest/dg/images/streaming-monitoring-5numrecords.png)
Questo parametro di streaming consente di visualizzare il numero di record in fase di elaborazione in una finestra. Oltre a specificare il numero di record in fase di elaborazione, agevola la comprensione del comportamento del traffico di input.
+ L'indicatore n. 1 mostra un esempio di traffico stabile senza picchi. In genere si tratta di applicazioni come i sensori IoT che raccolgono dati a intervalli regolari e li inviano all'origine di streaming.
+ L'indicatore n. 2 mostra un esempio di improvviso aumento del traffico su un carico altrimenti stabile. In un'applicazione clickstream, ciò può accadere in concomitanza con un evento di marketing come il Black Friday, quando si verifica un aumento esponenziale del numero di clic.
+ L'indicatore n. 3 mostra un esempio di traffico imprevedibile. L'imprevedibilità del traffico non indica un problema, ma è una caratteristica intrinseca dei dati di input. Tornando all'esempio del sensore IoT, immaginiamo centinaia di sensori che inviano eventi di cambiamenti meteorologici all'origine di streaming. Poiché i cambiamenti meteorologici non sono prevedibili, non lo sono nemmeno i dati. Comprendere l'andamento del traffico è fondamentale per dimensionare gli esecutori. Se l'input presenta molti picchi, potresti prendere in considerazione l'utilizzo del dimensionamento automatico, di cui parleremo più avanti.
![\[La schermata mostra il monitoraggio utilizzando il numero di record e le metriche PutRecords Kinesis nei lavori di streaming.\]](http://docs.aws.amazon.com/it_it/glue/latest/dg/images/streaming-monitoring-6putrecords.png)
Puoi combinare questa metrica con la metrica PutRecords Kinesis per assicurarti che il numero di eventi da inserire e il numero di record letti siano quasi gli stessi. Questo è particolarmente utile quando si cerca di comprendere il ritardo. All'aumentare del tasso di ingestione, aumenta anche il readby. `numRecords` AWS Glue
## Tempo di elaborazione in batch (metrica: streaming). batchProcessingTimeInMs)
Il parametro del tempo di elaborazione del batch consente di determinare se il provisioning del cluster è insufficiente o eccessivo.
![\[Lo screenshot mostra il monitoraggio del tempo di elaborazione del batch nei processi di streaming.\]](http://docs.aws.amazon.com/it_it/glue/latest/dg/images/streaming-monitoring-7batchprocess.png)
Questo parametro indica il numero di millisecondi necessari per elaborare ogni microbatch di record. L'obiettivo principale in questo caso è monitorare questo periodo per assicurarsi che sia inferiore all'intervallo `windowSize`. È accettabile che `batchProcessingTimeInMs` salga temporaneamente, purché torni alla normalità nell'intervallo di finestra successivo. L'indicatore n. 1 mostra un tempo più o meno stabile richiesto per elaborare il processo. Tuttavia, se il numero di record di input aumenta, il tempo necessario per elaborare il processo aumenta di conseguenza, come segnalato dall'indicatore n. 2. Se `numRecords` non aumenta ma il tempo di elaborazione sì, è necessario esaminare più a fondo l'elaborazione del processo sugli esecutori. È buona norma impostare una soglia e un allarme per assicurarsi che `batchProcessingTimeInMs` non superi il 120% per più di 10 minuti. Per ulteriori informazioni sull'impostazione degli allarmi, consulta [Using Amazon CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
## Ritardo dei consumatori (metrica: streaming). maxConsumerLagInMs)
Il parametro del ritardo dei consumatori aiuta a comprendere se sussiste un ritardo nell'elaborazione degli eventi. Se il ritardo è troppo elevato, potresti non rispettare lo SLA di elaborazione sottoscritto dalla tua azienda, anche se disponi di un windowSize corretto. È necessario abilitare esplicitamente questi parametri utilizzando l'opzione di connessione `emitConsumerLagMetrics`. Per ulteriori informazioni, consulta [KinesisStreamingSourceOptions](https://docs.aws.amazon.com/glue/latest/webapi/API_KinesisStreamingSourceOptions.html).
![\[Lo screenshot mostra il monitoraggio del ritardo nei processi di streaming.\]](http://docs.aws.amazon.com/it_it/glue/latest/dg/images/streaming-monitoring-8lag.png)
## Parametri derivati
Per ottenere informazioni più approfondite, puoi creare metriche derivate per saperne di più sui tuoi lavori di streaming in Amazon CloudWatch.
![\[Lo screenshot mostra il monitoraggio dei parametri derivati nei processi di streaming.\]](http://docs.aws.amazon.com/it_it/glue/latest/dg/images/streaming-monitoring-9derived.png)
Puoi creare un grafico con metriche derivate per decidere se è necessario utilizzarne di più. DPUs Sebbene il dimensionamento automatico ti aiuti a farlo automaticamente, puoi utilizzare parametri derivati per stabilire se il dimensionamento automatico funziona in modo efficace.
+ **InputRecordsPerSecond**indica la frequenza con cui vengono ricevuti i record di input. È derivato come segue: numero di record di input (glue.driver.streaming.numRecords)/. WindowSize
+ **ProcessingRecordsPerSecond**indica la velocità con cui vengono elaborati i record. È derivato come segue: numero di record di input (glue.driver.streaming.numRecords)/. batchProcessingTime InMs
Se la velocità di input è superiore a quella di elaborazione, potrebbe essere necessario incrementare la capacità per elaborare il processo oppure aumentare il parallelismo.
## Parametri di dimensionamento automatico
Se il traffico in entrata ha molti picchi, dovresti valutare l'abilitazione del dimensionamento automatico e specificare il numero massimo di worker. In tal caso ottieni due parametri aggiuntivi, `numberAllExecutors` e `numberMaxNeededExecutors`.
+ **numberAllExecutors**è il numero di esecutori di lavori che eseguono attivamente
+ **numberMaxNeededExecutor è il numero massimo di job executor** (in esecuzione attiva e in sospeso) necessari per soddisfare il carico corrente.
Questi due parametri ti aiuteranno a capire se il dimensionamento automatico funziona correttamente.
![\[Lo screenshot mostra il monitoraggio del dimensionamento automatico nei processi di streaming.\]](http://docs.aws.amazon.com/it_it/glue/latest/dg/images/streaming-monitoring-10autoscaling.png)
AWS Glue monitorerà la `batchProcessingTimeInMs` metrica su alcuni microbatch e farà una delle due cose. Aumenterà gli esecutori, se `batchProcessingTimeInMs` è più vicino a `windowSize`, oppure ridurrà gli esecutori, se `batchProcessingTimeInMs` è relativamente più basso di `windowSize`. Inoltre, utilizzerà un algoritmo per dimensionare gradualmente gli esecutori.
+ L'indicatore n. 1 mostra come gli esecutori attivi sono aumentati fino a raggiungere il numero massimo di esecutori necessari per elaborare il carico.
+ L'indicatore n. 2 mostra che gli esecutori attivi sono diminuiti rispetto a quando `batchProcessingTimeInMs` era basso.
È possibile utilizzare questi parametri per monitorare l'attuale parallelismo a livello di esecutore e regolare di conseguenza il numero massimo di worker nella configurazione di dimensionamento automatico.
## Come ottenere le prestazioni migliori
Spark cercherà di creare per ogni shard un'attività da cui leggere nel flusso Amazon Kinesis. I dati in ogni shard diventano una partizione. Quindi distribuirà queste attività tra gli esecutori/worker, a seconda del numero di core di ciascun worker (il numero di core per worker dipende dal tipo di worker selezionato, come `G.025X`, `G.1X` e così via). Tuttavia, il modo in cui le attività vengono distribuite non è deterministico. Tutte le attività vengono eseguite in parallelo sui rispettivi core. Se sono presenti più shard rispetto al numero di core esecutori disponibili, le attività vengono messe in coda.
È possibile utilizzare una combinazione dei parametri precedenti e del numero di shard per fornire agli esecutori un carico stabile con un certo margine per eventuali picchi. Si consiglia di eseguire alcune iterazioni del processo per determinare il numero approssimativo di worker. Per un unstable/spiky carico di lavoro puoi fare lo stesso impostando la scalabilità automatica e il numero massimo di lavoratori.
Imposta il valore di `windowSize` in base ai requisiti SLA della tua azienda. Ad esempio, se la tua azienda richiede che i dati elaborati non possano essere più vecchi di 120 secondi, imposta un valore di `windowSize` di almeno 60 secondi, in modo che il ritardo medio dei consumatori sia inferiore a 120 secondi (consulta la sezione precedente sul ritardo dei consumatori). Da lì, a seconda del numero `numRecords` e del numero di frammenti, pianifica la capacità in modo da DPUs assicurarti di occupare meno del 70% del tuo `batchProcessingTimeInMs` `windowSize` tempo per la maggior parte del tempo.
**Nota**
Gli hot shard possono causare la distorsione dei dati, il che significa che alcuni shards/partitions sono molto più grandi degli altri. Ciò può far sì che alcune attività eseguite in parallelo richiedano più tempo, cosicché alcune attività restano indietro. Di conseguenza, il batch successivo non può iniziare fino al completamento di tutte le attività del precedente, il che influirà sul valore di `batchProcessingTimeInMillis` e sul ritardo massimo.