本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Managed Service for Apache Flink 中的監控
<a name="monitoring"></a>

在生產環境中執行串流應用程式時，您著手持續且無限期地執行應用程式。它對實現所有元件的監控和適當報警至關重要，不只是對 Flink 應用程式。否則，您可能會較早就錯過新出現的問題，只在問題完全顯現並且更難以緩解之後才意識到操作事件。要監控的一般事項包括：
+ 來源是否正在擷取資料？
+ 是否已從來源讀取資料 (從來源角度看)？
+ Flink 應用程式是否正在接收資料？
+ Flink 應用程式能夠跟上還是落後？
+ Flink 應用程式是否將資料保存到接收器中 (從應用程式角度看)？
+ 接收器是否正在接收資料？

然後應該考慮針對 Flink 應用程式的更具體指標。此 [CloudWatch 儀表板](https://github.com/aws-samples/kda-metrics-dashboard)提供了一個不錯的起點。如需要為生產應用程式監控的指標之詳細資訊，請參閱[搭配 Amazon Managed Service for Apache Flink 使用 CloudWatch 警示](monitoring-metrics-alarms.md)。這些指標包括：
+ **records\$1lag\$1max** 和 **millisbehindLatest**：如果應用程式正在從 Kinesis 或 Kafka 取用，這些指標會指出應用程式是否落後，需要進行擴展以跟上目前的負載。這是一個很好的通用指標，很容易跟踪各種應用程式。但它只能用於被動式擴展，也就是說，當應用程式已經落後時。
+ **cpuUtilization** 和 **heapMemoryUtilization**：這些指標可清楚地指出應用程式的整體資源使用率，並且除非應用程式為 I/O 綁定，否則可用於主動擴展。
+ **downtime**：停機時間大於零表示應用程式失敗。如果值大於 0，表示應用程式未在處理任何資料。
+ **lastCheckpointSize** 和 *lastCheckpointDuration*：這些指標監控有多少資料存儲在狀態中以及需要多長時間執行檢查點。如果檢查點增長或花費較長時間，應用程式會持續花費時間在檢查點上，而且實際處理的週期較少。在某些時候，檢查點可能會變得太大或花費很長時間才會失敗。除了監控絕對值之外，客戶還應考慮使用 `RATE(lastCheckpointSize)` 和 `RATE(lastCheckpointDuration)` 監控變動率。
+ **numberOfFailedCheckpoint**：此指標會計算應用程式啟動後失敗的檢查點數目。根據應用程式的不同，如果檢查點偶爾失敗，該指標可以容忍。但是，如果檢查點經常出現故障，則應用程式可能運作不正常，需要進一步關注。我們建議監控 `RATE(numberOfFailedCheckpoints)` 以發出梯度警示，而不是絕對值。