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 consuma da Kinesis o Kafka, questi parametri indicano se è in ritardo e deve essere dimensionata 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 il dimensionamento reattivo, 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. 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)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.
