Perché la mia applicazione Amazon Kinesis Data Analytics si sta riavviando?

Risoluzione

Quando un'attività ha esito negativo, l'applicazione Apache Flink riavvia l'operazione non riuscita e altre attività interessate per riportare il processo a uno stato normale.

Di seguito sono riportate alcune delle cause e i relativi passaggi di risoluzione dei problemi per questa condizione:

• Gli errori di codice, come l'Eccezione NullPointer e la tipologia DataCast, vengono generati nel task manager e inviati al job manager. L'applicazione viene quindi riavviata dall'ultimo checkpoint. Per rilevare i riavvii delle applicazioni dovuti a eccezioni non gestite nell'applicazione, controlla i parametri di Amazon CloudWatch come i tempi di inattività. Questo parametro visualizza un valore diverso da zero durante i periodi di riavvio. Per identificare le cause di questa condizione, eseguire una query dei registri dell'applicazione per cambiare lo stato dell'applicazione da RUNNING a FAILED. Per ulteriori informazioni, vedere Analizzare gli errori: errori relativi alle attività dell'applicazione.

• Quando si ottengono eccezioni di memoria esaurita, il task manager non può inviare segnali heartbeat di integrità al job manager, portando a un riavvio dell'applicazione. In tal caso, potresti visualizzare errori, come TimeoutException, FlinkException o RemoteTransportException nei registri dell'applicazione. Verifica se l'applicazione è sovraccaricata a causa della pressione della CPU o delle risorse di memoria.

  • Assicurati che i parametri di CloudWatch fullRestarts ei tempi di inattività riportino valori diversi da zero.
  • Controlla i parametri cpuUtilization e heapMemoryUtilization per individuare picchi insoliti.
  • Verifica la presenza di eccezioni non gestite nel codice della tua applicazione.
  • Verifica la presenza di errori di checkpoint e savepoint. Monitora i parametri di CloudWatch numOFFailedCheckpoints, lastCheckpointSize e lastCheckpointDuration per rilevare picchi e aumenti fissi.
    Per risolvere il problema, completa la seguente operazione:
  • Se sono stati abilitati i registri debug per l'applicazione, il consumo di risorse dell'applicazione potrebbe essere elevato. Ridurre la quantità di registrazione abilitando temporaneamente i registri debug solo quando si analizzano i problemi.
  • Analizza il dump del thread di TaskManager nel pannello di controllo di Apache Flink. Ad esempio, è possibile identificare i processi ad alta intensità della CPU dal dump del thread.
  • Esamina i grafici Flame che vengono creati campionando più volte le tracce della pila. È possibile utilizzare i grafici Flame per eseguire le seguenti operazioni: visualizzare l’integrità generale dell'applicazione, identificare i metodi che consumano la maggior parte delle risorse della CPU e identificare la serie di chiamate nella pila che hanno portato all'esecuzione di un particolare metodo. Controlla le chiamate bloccate usando i grafici Flame al di fuori dalla CPU.

• Se l'applicazione non esegue il provisioning di una fonte o di un sink, l'applicazione potrebbe riscontrare errori di limitazione durante la lettura e la scrittura su servizi di streaming come Kinesis Data Streams. Questa condizione potrebbe portare a un arresto dell'applicazione. Controlla la velocità effettiva per l'origine e il sink utilizzando i parametri di CloudWatch come WriteProvisionedThroughputExceeded e ReadProvisionedThroughputExceeded. Valuta la possibilità di aumentare i flussi di dati per adattarli al volume di dati aumentando il numero di partizione.

• FlinkKinesisProducer utilizza la Kinesis Producer Library (KPL) per trasmettere i dati da un flusso Flink a un flusso di dati Kinesis. Gli errori, come il timeout, causano errori in KPL che potrebbero portare al riavvio dell'applicazione Flink. In questi casi, potresti notare un aumento del tempo di buffering e del numero di tentativi. È possibile ottimizzare le seguenti configurazioni per KPL in modo tale che il registro non termini: RecordMaxBufferedTime, RecordTtl e RequestTimeout. Inoltre, monitora importanti parametri KPL come ErrorsByCode, RetriesPerRecord, eUserRecordsPending. Quando questi parametri indicano che l'applicazione è in fase di riavvio, utilizza i filtri in CloudWatch Logs Insights per conoscere i motivi esatti degli errori che hanno portato al riavvio.

• Tieni presente che non tutti gli errori comportano un riavvio immediato dell'applicazione. Ad esempio, gli errori nel codice dell'applicazione potrebbero causare l'errore del flusso di lavoro del DAG. In questo caso, il grafo aciclico diretto (DAG) per la tua applicazione non viene creato. L'applicazione si chiude e non si riavvia immediatamente. Inoltre, l'applicazione non si riavvia immediatamente quando viene visualizzato un errore di «accesso negato».

Se il problema persiste, contatta AWS Support e fornisci le seguenti informazioni:

• Applicazione ARN
• Informazioni sull'origine e sul sink della tua applicazione
• Registri CloudWatch della tua applicazione
• Ora del problema in UTC
• Rilevanti dump di thread dal pannello di controllo di Flink

Informazioni correlate

L'applicazione viene riavviata