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à.
# Risolvi i problemi dei consumatori di Kinesis Data Streams
**Topics**
+ [Errore di compilazione con il costruttore LeaseManagementConfig](#compilation-error-leasemanagementconfig)
+ [Alcuni record Kinesis Data Streams vengono ignorati quando si utilizza la Kinesis Client Library](#records-skipped)
+ [I record che appartengono allo stesso frammento vengono elaborati da diversi processori di record contemporaneamente](#records-belonging-to-the-same-shard)
+ [L'applicazione consumer sta leggendo a una velocità inferiore al previsto](#consumer-app-reading-slower)
+ [GetRecords restituisce un array di record vuoto anche quando ci sono dati nel flusso](#getrecords-returns-empty)
+ [Lo shard iterator scade in modo imprevisto](#shard-iterator-expires-unexpectedly)
+ [L'elaborazione dei record dei consumatori è in ritardo](#record-processing-falls-behind)
+ [Errore di autorizzazione della chiave KMS non autorizzata](#unauthorized-kms-consumer)
+ [DynamoDbException: il percorso del documento fornito nell'espressione di aggiornamento non è valido per l'aggiornamento](#dynamo-db-exception)
+ [Risolvi altri problemi comuni per i consumatori](#misc-troubleshooting-consumer)
## Errore di compilazione con il costruttore LeaseManagementConfig
Durante l'aggiornamento alla versione 3.x o successiva di Kinesis Client Library (KCL), è possibile che si verifichi un errore di compilazione relativo al costruttore. `LeaseManagementConfig` Se stai creando direttamente un `LeaseManagementConfig` oggetto per impostare le configurazioni anziché utilizzarlo `ConfigsBuilder` nelle versioni KCL 3.x o successive, potresti visualizzare il seguente messaggio di errore durante la compilazione del codice dell'applicazione KCL.
```
Cannot resolve constructor 'LeaseManagementConfig(String, DynamoDbAsyncClient, KinesisAsyncClient, String)'
```
KCL con versioni 3.x o successive richiede l'aggiunta di un altro parametro, ApplicationName (type: String), dopo il parametro TableName.
+ *Prima*: leaseManagementConfig = new LeaseManagementConfig (tableName, DBClient dynamo, kinesisClient, streamName, workerIdentifier)
+ *Dopo*: leaseManagementConfig = new LeaseManagementConfig (tablename**, applicationName, dynamo, kinesisClient**, streamNameDBClient, workerIdentifier)
Invece di creare direttamente un LeaseManagementConfig oggetto, consigliamo di utilizzarlo per impostare le configurazioni in KCL 3.x e versioni successive. `ConfigsBuilder` `ConfigsBuilder`offre un modo più flessibile e gestibile per configurare l'applicazione KCL.
Di seguito è riportato un esempio di utilizzo `ConfigsBuilder` per impostare le configurazioni KCL.
```
ConfigsBuilder configsBuilder = new ConfigsBuilder(
streamName,
applicationName,
kinesisClient,
dynamoClient,
cloudWatchClient,
UUID.randomUUID().toString(),
new SampleRecordProcessorFactory()
);
Scheduler scheduler = new Scheduler(
configsBuilder.checkpointConfig(),
configsBuilder.coordinatorConfig(),
configsBuilder.leaseManagementConfig()
.failoverTimeMillis(60000), // this is an example
configsBuilder.lifecycleConfig(),
configsBuilder.metricsConfig(),
configsBuilder.processorConfig(),
configsBuilder.retrievalConfig()
);
```
## Alcuni record Kinesis Data Streams vengono ignorati quando si utilizza la Kinesis Client Library
La causa più comune di record ignorati è un'eccezione non gestita generata da `processRecords`. La Kinesis Client Library (KCL) si basa sul codice `processRecords` per gestire eventuali eccezioni generate dall'elaborazione dei record di dati. Qualsiasi eccezione generata da `processRecords` viene assorbita dalla KCL. Per evitare infiniti tentativi su un errore ricorrente, la KCL non invierà nuovamente batch di record elaborati al momento dell'eccezione. La KCL quindi chiama `processRecords` per i successivi batch di record di dati senza riavviare il processore del record. Ciò avviene nelle applicazioni dei consumatori che osservano i record ignorati. Per impedire che i record vengano ignorati, è necessario gestire tutte le eccezioni all'interno di `processRecords` in modo appropriato.
## I record che appartengono allo stesso frammento vengono elaborati da diversi processori di record contemporaneamente
Per qualsiasi applicazione Kinesis Client Library (KCL) in esecuzione, una partizione ha un solo proprietario. Tuttavia, più processori di record possono elaborare temporaneamente lo stesso shard. Se un'istanza di lavoro perde la connettività di rete, KCL presume che il lavoratore irraggiungibile non stia più elaborando i record dopo la scadenza del tempo di failover e ordina ad altre istanze di lavoro di subentrare. Per un breve periodo, i nuovi processori record e i processori record dei lavoratori irraggiungibili possono elaborare i dati dello stesso shard.
Imposta un tempo di failover appropriato per la tua applicazione. Per le applicazioni a bassa latenza, l'impostazione predefinita di 10 secondi può rappresentare il tempo massimo che si desidera attendere. Tuttavia, nel caso in cui si prevedano problemi di connettività, ad esempio chiamate in aree geografiche dove la connettività potrebbe andare perduta con maggiore frequenza, questo numero può risultare troppo basso.
L'applicazione deve anticipare e gestire questo scenario, soprattutto perché la connettività di rete viene in genere ripristinata per il lavoratore precedentemente non raggiungibile. Se un record ha un processore shard assunto da un altro processore del record, è necessario gestire i seguenti due casi per eseguire un arresto regolare:
1. Una volta completata la chiamata corrente a`processRecords`, KCL richiama il metodo di spegnimento sul registratore indicando il motivo dello spegnimento «ZOMBIE». Si prevede che i tuoi processori record puliscano tutte le risorse in modo appropriato e quindi escano.
1. Quando provi a fare il checkpoint da un worker "zombie", la KCL genera `ShutdownException`. Dopo aver ricevuto questa eccezione, il tuo codice dovrebbe uscire in modo pulito dal metodo corrente.
Per ulteriori informazioni, consulta [Gestire i record duplicati](kinesis-record-processor-duplicates.md).
## L'applicazione consumer sta leggendo a una velocità inferiore al previsto
I motivi più comuni per cui il rendimento di lettura è più lento del previsto sono i seguenti:
1. Molteplici applicazioni consumatori hanno letture totali che superano i limiti per shard. Per ulteriori informazioni, consulta [Quote e limiti](service-sizes-and-limits.md). In questo caso, è possibile aumentare il numero di partizioni nel flusso di dati Kinesis.
1. Il [limite](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_GetRecords.html#API_GetRecords_RequestSyntax) che specifica il numero massimo di **GetRecords** per chiamata potrebbe essere stato configurato con un valore basso. Se utilizzi KCL, potresti aver configurato il lavoratore con un valore basso per la proprietà `maxRecords`. In generale, consigliamo di utilizzare i valori predefiniti del sistema per questa proprietà.
1. La logica all'interno della `processRecords` chiamata potrebbe impiegare più tempo del previsto per una serie di possibili ragioni; la logica potrebbe richiedere un uso intensivo della CPU, un I/O blocco o un rallentamento della sincronizzazione. Per verificare se ciò è vero, il test esegue processori di record vuoti e confronta il rendimento di lettura. Per informazioni su come gestire i dati in entrata, consulta [Usa il resharding, lo scaling e l'elaborazione parallela per modificare il numero di shard](kinesis-record-processor-scaling.md).
Se disponi di una sola applicazione consumer, puoi sempre leggere almeno due volte più velocemente della velocità di inserimento. Questo perché puoi scrivere fino a 1.000 record al secondo per scritture, con una velocità massima totale di scrittura dei dati pari a 1 MB al secondo (comprese le chiavi di partizioni). Ogni partizione può supportare fino a 5 transazioni al secondo, con una velocità di lettura totale massima di 2 MB al secondo. Considera che ogni lettura (chiamata **GetRecords**) ottiene un batch di record. La dimensione dei dati restituiti da **GetRecords** varia a seconda dell'utilizzo dello shard. La dimensione massima di dati che **GetRecords** può restituire è 10 MB. Se una chiamata restituisce tale limite, le chiamate successive effettuate entro i 5 secondi successivi generano un. `ProvisionedThroughputExceededException`
## GetRecords restituisce un array di record vuoto anche quando ci sono dati nel flusso
Consumare o ottenere record è un modello di pull. Ci si aspetta che gli sviluppatori effettuino chiamate [GetRecords](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_GetRecords.html)a ciclo continuo senza back-off. Ogni chiamata a **GetRecords** inoltre restituisce un valore `ShardIterator` che deve essere usato nella prossima iterazione del ciclo.
L'operazione **GetRecords** non si blocca. Al contrario, ritorna immediatamente; con uno dei record di dati pertinenti o con un elemento `Records` vuoto. Un elemento `Records` vuoto viene restituito a due condizioni:
1. Non ci sono più dati al momento nello shard.
1. Non ci sono dati vicino alla parte dello shard puntato dal `ShardIterator`.
Quest'ultima condizione è lieve, ma è un compromesso di progettazione necessario per evitare tempi di ricerca illimitati (latenza) per il recupero dei record. Pertanto, l'applicazione che consuma il flusso dovrebbe eseguire il ciclo e chiamare **GetRecords** nella gestione dei record vuoti normalmente.
In uno scenario di produzione, l'unica volta in cui il ciclo continuo deve essere chiuso è quando il valore `NextShardIterator` è `NULL`. Quando `NextShardIterator` è `NULL`, significa che l'attuale shard è stato chiuso e il valore `ShardIterator` punterebbe altrimenti oltre l'ultimo record. Se l'applicazione che consuma non chiama mai **SplitShard** o**MergeShards**, lo shard rimane aperto e le chiamate a **GetRecords** non restituiranno mai un valore `NextShardIterator` che è `NULL`.
Se utilizzi la Kinesis Client Library (KCL), il modello di consumo precedente viene riassunto automaticamente. Questo include la gestione automatica di un set di shard che cambia in modo dinamico. Con la KCL, lo sviluppatore fornisce solo la logica per elaborare i record in entrata. Questo è possibile perché la libreria genera continue chiamate ai **GetRecords** per te.
## Lo shard iterator scade in modo imprevisto
Un nuovo iteratore shard viene restituito da ogni richiesta **GetRecords** (come `NextShardIterator`), che utilizzerai nella prossima richiesta **GetRecords** (come `ShardIterator`). Di solito, questo iteratore shard non scade prima dell'uso. Tuttavia, è possibile che gli iteratori shard scadano perché non hai chiamato **GetRecords** per più di 5 minuti o perché hai eseguito un riavvio della tua applicazione consumer.
Se lo shard iterator scade immediatamente prima di poterlo utilizzare, ciò potrebbe indicare che la tabella DynamoDB utilizzata da Kinesis non ha una capacità sufficiente per archiviare i dati del lease. Questa situazione è più probabile se disponi di un numero elevato di shard. Per risolvere il problema, aumenta la capacità di scrittura assegnata alla tabella shard. Per ulteriori informazioni, consulta [Utilizza una tabella di leasing per tenere traccia degli shard elaborati dall'applicazione consumer KCL](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable).
## L'elaborazione dei record dei consumatori è in ritardo
Per la maggior parte dei casi d'uso, le applicazioni leggono i dati più recenti dal flusso. In alcune circostanze, le letture dei consumatori possono rimanere indietro, il che potrebbe non essere desiderato. Dopo aver identificato il punto in cui i consumatori stanno leggendo, guarda i motivi più comuni per cui i consumatori restano indietro.
Inizia con il parametro `GetRecords.IteratorAgeMilliseconds`, che monitora la posizione di lettura in tutti gli shard e i consumatori nel flusso. Nota che se l'età di un iteratore supera il 50% del periodo di conservazione (per impostazione predefinita 24 ore, configurabile fino a 7 giorni), sussiste il rischio di perdita di dati a causa della scadenza del record. Una rapida soluzione di ripiego consiste nell'aumentare il periodo di conservazione. Ciò interrompe la perdita di dati importanti man mano che si risolve il problema. Per ulteriori informazioni, consulta [Monitora il servizio Amazon Kinesis Data Streams con Amazon CloudWatch](monitoring-with-cloudwatch.md). Successivamente, identifica il ritardo con cui la tua applicazione consumer sta leggendo ogni shard utilizzando una CloudWatch metrica personalizzata emessa dalla Kinesis Client Library (KCL),. `MillisBehindLatest` Per ulteriori informazioni, consulta [Monitora la libreria client Kinesis con Amazon CloudWatch](monitoring-with-kcl.md).
Ecco i motivi più comuni per cui i consumatori possono rimanere indietro:
+ Grandi aumenti improvvisi di `GetRecords.IteratorAgeMilliseconds` o `MillisBehindLatest` in genere indicano un problema transitorio, come i guasti delle operazioni API su un'applicazione downstream. Esamina questi aumenti improvvisi se una delle metriche mostra costantemente questo comportamento.
+ Un aumento graduale di questi parametri indica che un consumer non è al passo con lo streaming perché non sta elaborando i record abbastanza velocemente. Le cause principali più comuni di questo comportamento sono risorse fisiche insufficienti o logica di elaborazione dei record che non è stata ridimensionata con un aumento del rendimento del flusso. Puoi verificare questo comportamento esaminando le altre CloudWatch metriche personalizzate emesse da KCL associate all'`processTask`operazione, tra cui`RecordProcessor.processRecords.Time`, e. `Success` `RecordsProcessed`
+ Se ottieni un aumento del parametro `processRecords.Time` correlato con l'aumento del rendimento, devi analizzare la logica di elaborazione dei record per identificare il motivo per cui non si ridimensiona con il rendimento aumentato.
+ Se ottieni un aumento per i valori `processRecords.Time` che non sono correlati con un maggiore rendimento, controlla se stai effettuando chiamate di blocco nel percorso critico, che sono spesso causa di rallentamenti nell'elaborazione dei record. Un approccio alternativo è aumentare il parallelismo aumentando il numero di shard. Infine, verifica di disporre di una quantità adeguata di risorse fisiche (memoria, utilizzo della CPU, tra le altre) sui nodi di elaborazione sottostanti durante i picchi di domanda.
## Errore di autorizzazione della chiave KMS non autorizzata
Questo errore si verifica quando un'applicazione consumer legge da un flusso crittografato senza autorizzazioni sulla chiave. AWS KMS Per assegnare le autorizzazioni a un'applicazione per accedere a una chiave KMS, consulta [Utilizzo delle policy della chiave in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) e [Utilizzo delle policy IAM con AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html).
## DynamoDbException: il percorso del documento fornito nell'espressione di aggiornamento non è valido per l'aggiornamento
Quando si utilizza KCL 3.x con AWS SDK per Java le versioni da 2.27.19 a 2.27.23, è possibile riscontrare la seguente eccezione DynamoDB:
«software.amazon.awssdk.services.dynamodb.model. DynamoDbException: Il percorso del documento fornito nell'espressione di aggiornamento non è valido per l'aggiornamento (Service:, Status Code: 400, Request ID: xxx)» DynamoDb
Questo errore si verifica a causa di un problema noto AWS SDK per Java che riguarda la tabella di metadati DynamoDB gestita da KCL 3.x. Il problema è stato introdotto nella versione 2.27.19 e riguarda tutte le versioni fino alla 2.27.23. Il problema è stato risolto nella versione 2.27.24. AWS SDK per Java Per prestazioni e stabilità ottimali, consigliamo l'aggiornamento alla versione 2.28.0 o successiva.
## Risolvi altri problemi comuni per i consumatori
+ [Perché il trigger del flusso di dati Kinesis non è in grado di richiamare la mia funzione Lambda?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-lambda-invocation/)
+ [Come posso rilevare e risolvere le ReadProvisionedThroughputExceeded eccezioni in Kinesis Data Streams?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-readprovisionedthroughputexceeded/)
+ [Perché riscontro problemi di latenza elevata con il flusso di dati Kinesis?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-stream-latency-issues/)
+ [Perché il mio flusso di dati Kinesis restituisce un errore interno del server 500?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-stream-500-error/)
+ [Come posso risolvere un'applicazione KCL bloccata per il flusso di dati Kinesis?](https://aws.amazon.com/premiumsupport/knowledge-center/kcl-kinesis-data-streams/)
+ [Posso usare diverse applicazioni Amazon Kinesis Client Library con la stessa tabella Amazon DynamoDB?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-kcl-apps-dynamodb-table/)