Il servizio gestito da Amazon per Apache Flink era precedentemente noto come Analisi dei dati Amazon Kinesis per Apache Flink.
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à.
Monitoraggio in Managed Service per Apache Flink
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
records_lag_max e millisbehindLatest— Se l'applicazione utilizza Kinesis o Kafka, queste metriche indicano se l'applicazione è in ritardo e deve essere ridimensionata per stare 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 il dimensionamento reattivo, ovvero quando l'applicazione è già in ritardo.
cpuUtilizatione heapMemoryUtilization— Queste metriche forniscono una buona indicazione dell'utilizzo complessivo delle risorse dell'applicazione e possono essere utilizzate per una 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 completare 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)eRATE(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 non riescono 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.
