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
<a name="monitoring"></a>

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](https://github.com/aws-samples/kda-metrics-dashboard) offre un buon punto di partenza. Per ulteriori informazioni sui parametri da monitorare per le applicazioni di produzione, consulta [Usa gli CloudWatch allarmi con Amazon Managed Service per Apache Flink](monitoring-metrics-alarms.md). Tali parametri includono:
+ **records\$1lag\$1max** 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 **heapMemoryUtilization****e: 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.
+ **lastCheckpointSize**e *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 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.