Monitoraggio

Quando esegui applicazioni di streaming in produzione, decidi di eseguire l'applicazione in modo continuo e indefinito. È fondamentale implementare il monitoraggio e i sistemi di avviso corretti di tutti i componenti, non solo dell'applicazione Flink, altrimenti rischi di non affrontare tempestivamente i problemi emergenti e di accorgerti di un evento operativo solo quando ormai è troppo difficile da mitigare. Gli aspetti generali da monitorare includono:

• L'origine sta importando dati?

• I dati vengono letti dall'origine (dal punto di vista dell'origine)?

• L'applicazione Flink riceve dati?

• L'applicazione Flink è in grado di restare al passo o è in ritardo?

• L'applicazione Flink mantiene i dati nel sink (dal punto di vista dell'applicazione)?

• Il sink riceve dati?

Successivamente, è necessario prendere in considerazione parametri più specifici per l'applicazione Flink. Questa CloudWatch dashboard offre un buon punto di partenza. Per ulteriori informazioni sui parametri da monitorare per le applicazioni di produzione, consulta Utilizzo degli CloudWatch allarmi con Amazon Managed Service per Apache Flink. Tali parametri includono:

• records_lag_max e millisbehindLatest: se l'applicazione consuma da Kinesis o Kafka, questi parametri indicano se è in ritardo e deve essere ridimensionata per restare al passo con il carico corrente. Si tratta di un parametro generico valido e facile da tracciare per tutti i tipi di applicazioni; tuttavia, può essere utilizzato solo per la scalabilità reattiva, ovvero quando l'applicazione è già in ritardo.

• CPUUtilization heapMemoryUtilizatione: queste metriche forniscono una buona indicazione dell'utilizzo complessivo delle risorse dell'applicazione e possono essere utilizzate per la scalabilità proattiva, a meno che l'applicazione non sia vincolata all'I/O.

• downtime: un tempo di inattività maggiore di zero indica un errore dell'applicazione. Se il valore è maggiore di 0, l'applicazione non sta elaborando alcun dato.

• lastCheckpointSizee lastCheckpointDuration— Queste metriche monitorano la quantità di dati archiviati nello stato e il tempo necessario per superare un checkpoint. Se i checkpoint aumentano di dimensioni o richiedono molto tempo, l'applicazione dedica continuamente tempo a effettuare checkpoint e ha meno cicli per l'elaborazione effettiva dei dati. In alcuni punti, i checkpoint possono diventare troppo grandi o impiegare così tanto tempo da non funzionare. Oltre ai valori assoluti, i clienti dovrebbero considerare la possibilità di monitorare la frequenza di modifica con RATE(lastCheckpointSize) e RATE(lastCheckpointDuration).

• numberOfFailedCheckpoint: questa metrica conta il numero di checkpoint non riusciti dall'avvio dell'applicazione. A seconda dell'applicazione, un malfunzionamento occasionale dei checkpoint può essere accettabile. Tuttavia, se i checkpoint falliscono regolarmente, è probabile che l'applicazione non sia integra e che necessiti di ulteriore attenzione. Si consiglia di controllare che il parametro RATE(numberOfFailedCheckpoints) evidenzi problemi sul gradiente e non su valori assoluti.