

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

# 關於監控 AWS Glue 串流任務
<a name="glue-streaming-monitoring"></a>

監控串流任務是建置 ETL 管道的極為關鍵的一環。除了使用 Spark UI 外，您也可以使用 Amazon CloudWatch 來監控指標。以下是 AWS Glue 架構發出的串流指標清單。如需所有 AWS Glue 指標的完整清單，請參閱[AWS Glue 使用 Amazon CloudWatch 指標進行監控](https://docs.aws.amazon.com/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html)。

AWS Glue 使用結構化串流架構來處理輸入事件。您可以直接在程式碼中使用 Spark API，也可使用發佈這些指標的 `GlueContext` 所提供的 `ForEachBatch`。若要了解這些指標，我們必須先了解何謂 `windowSize`。

**windowSize**：`windowSize`是指您提供的微批次間隔。如果您指定 60 秒的時段大小， AWS Glue 串流任務會等待 60 秒 （如果上一個批次尚未完成，則為更久），之後才會從串流來源讀取批次中的資料，並套用 中提供的轉換`ForEachBatch`。此間隔也稱為「觸發間隔」。

讓我們更深入地查看指標，以了解運作狀態和效能特性。

**注意**  
這些指標每 30 秒發出一次。如果您的 `windowSize` 小於 30 秒，則回報的指標會是彙總資料。舉例來說，假設您的 `windowSize` 是 10 秒，每個微批次固定處理 20 筆記錄。在這個案例中，為 numRecords 發出的指標值會是 60。  
如果沒有可用的資料，則不會發出指標。此外，如果是取用者延遲指標，則必須啟用該功能才能取得其指標。

# 視覺化 AWS Glue 串流指標
<a name="glue-streaming-monitoring-visualizing"></a>

若要繪製視覺化指標：

1. 前往 Amazon CloudWatch 主控台中的**指標**，然後選擇**瀏覽**索引標籤。接著在「自訂命名空間」下選擇 **Glue**。  
![\[螢幕擷取畫面顯示監控 AWS Glue 串流任務時，在 Amazon CloudWatch 主控台中存取指標。\]](http://docs.aws.amazon.com/zh_tw/glue/latest/dg/images/streaming-monitoring-1.png)

1. 選擇**任務指標**以顯示所有任務的指標。

1. 根據 JobName=glue-feb-monitoring 以及 JobRunId=ALL 來篩選指標。您可以按一下「\$1」符號 (如下圖所示)，將其新增至搜尋篩選條件。

1. 針對您感興趣的指標，選取其核取方塊。在下圖中，我們選取了 `numberAllExecutors` 和 `numberMaxNeededExecutors`。  
![\[螢幕擷取畫面顯示在監控串流任務時，將平均值套用至指標。\]](http://docs.aws.amazon.com/zh_tw/glue/latest/dg/images/streaming-monitoring-2.png)

1. 選取這些指標後，您可以前往**圖表化指標**索引標籤套用您的統計資料。

1. 由於指標每分鐘發出一次，您可以大於一分鐘的間隔為 `batchProcessingTimeInMs` 和 `maxConsumerLagInMs` 套用「平均值」。若為 `numRecords`，則可每分鐘套用一次「總和」。

1. 您可以使用**選項**索引標籤將 `windowSize` 水平註釋新增至圖表。  
![\[螢幕擷取畫面顯示在監控串流任務時，將 windowSize 註釋新增至圖表。\]](http://docs.aws.amazon.com/zh_tw/glue/latest/dg/images/streaming-monitoring-3.png)

1. 選取指標後，請建立並新增儀表板。以下是範例儀表板。  
![\[螢幕擷取畫面顯示監控串流任務的範例儀表板。\]](http://docs.aws.amazon.com/zh_tw/glue/latest/dg/images/streaming-monitoring-4.png)

# 使用 AWS Glue 串流指標
<a name="glue-streaming-monitoring-metrics"></a>

本節說明各項指標，以及各指標間相互的關聯。

## 記錄數目 (指標：streaming.numRecords)
<a name="glue-streaming-monitoring-metrics-num-records"></a>

此指標指出正在處理的記錄數目。

![\[螢幕擷取畫面顯示監控串流任務中的記錄數目。\]](http://docs.aws.amazon.com/zh_tw/glue/latest/dg/images/streaming-monitoring-5numrecords.png)


此串流指標可讓您了解在一段時間內處理的記錄數目。除了正在處理的記錄數目外，這項指標還能幫助您了解輸入流量的行為。
+ 指標 \$11 顯示了沒有任何暴增流量的穩定流量範例。一般來說，這會是像 IoT 感應器這類的應用程式，IoT 感應器會定期收集資料，並將資料傳送到串流來源。
+ 指標 \$12 顯示了在穩定的負載中突然出現暴增流量的範例。在遇到像黑色星期五之類的行銷活動，而出現點擊次數暴增時，點擊流應用程式就可能會發生這種情況
+ 指標 \$13 顯示了無法預測的流量範例。無法預測的流量表示存在問題，這只是輸入資料的本質問題。回到 IoT 感應器的例子，您可以想像有數百個感應器正在向串流來源傳送天氣變化事件。由於天氣變化是不可預測的，資料當然也無法預測。了解流量模式是調整執行器大小的關鍵。如果輸入流量會在瞬間達到高峰，您可以考慮使用自動調整功能 (之後會詳細說明)。

![\[螢幕擷取畫面顯示監控使用串流任務中的記錄數目和 Kinesis PutRecords 指標。\]](http://docs.aws.amazon.com/zh_tw/glue/latest/dg/images/streaming-monitoring-6putrecords.png)


您可以將這項指標與 Kinesis PutRecords 指標合併使用，以確保所擷取的事件數目和讀取的記錄數目幾近相同。當您試著要了解延遲情況時，這個做法更是格外有用。隨著擷取速率的增加， 的`numRecords`讀取方式也隨之增加 AWS Glue。

## 批次處理時間 (指標：streaming.batchProcessingTimeInMs)
<a name="glue-streaming-monitoring-metrics-batch-processing-time"></a>

「批次處理時間」指標可協助您判斷叢集是佈建不足或過度佈建。

![\[螢幕擷取畫面顯示監控串流任務中的批次處理時間。\]](http://docs.aws.amazon.com/zh_tw/glue/latest/dg/images/streaming-monitoring-7batchprocess.png)


這項指標表示處理每個微批次記錄所需的毫秒數。這項指標的主要目標是監控時間，以確保時間小於 `windowSize` 間隔。只要 `batchProcessingTimeInMs` 在之後的時段間隔恢復正常，暫時的升高並沒有關係。指標 \$11 顯示處理任務所花費較穩定或較不穩定的時間。但是，如果輸入記錄的數量增加，則處理任務所需的時間也會增加 (如指標 \$12 所示)。如果 `numRecords` 沒有增加，但處理時間卻上升，那麼您需要更深入地查看執行器所處理的任務。設定閾值和警示是個不錯的做法，可確保 `batchProcessingTimeInMs` 高出 120％ 的時間不會超過 10 分鐘。如需有關設定警示的詳細資訊，請參閱[使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。

## 取用者延遲 (指標：streaming.maxConsumerLagInMs)
<a name="glue-streaming-monitoring-metrics-consumer-lag"></a>

取用者延遲指標可協助您了解事件處理是否有延遲。如果延遲時間過高，即使您的 windowSize 正確，也可能會錯過業務所依賴的處理中 SLA。您必須使用 `emitConsumerLagMetrics` 連線選項明確啟用這項指標。如需詳細資訊，請參閱 [KinesisStreamingSourceOptions](https://docs.aws.amazon.com/glue/latest/webapi/API_KinesisStreamingSourceOptions.html)。

![\[螢幕擷取畫面顯示監控串流任務中的延遲時間。\]](http://docs.aws.amazon.com/zh_tw/glue/latest/dg/images/streaming-monitoring-8lag.png)


## 衍生指標
<a name="glue-streaming-monitoring-metrics-derived"></a>

若要取得更深入的分析數據，您可以建立衍生指標，以進一步了解 Amazon CloudWatch 中的串流任務。

![\[螢幕擷取畫面顯示監控串流任務中的衍生指標。\]](http://docs.aws.amazon.com/zh_tw/glue/latest/dg/images/streaming-monitoring-9derived.png)


您可以使用衍生指標建立圖形，以決定是否需要使用更多 DPU。雖然自動調整功能可協助您自動執行此作業，但您可以使用衍生指標來判斷自動調整功能是否有效運作。
+ **InputRecordsPerSecond** 表示取得輸入記錄的速率。此數值的計算方式為：輸入記錄數目 (glue.driver.streaming.numRecords)/windowSize。
+ **ProcessingRecordsPerSecond** 表示處理記錄的速率。此數值的計算方式為：輸入記錄數目 (glue.driver.streaming.numRecords)/batchProcessingTimeInMs。

如果輸入速率高於處理速率，則可能需要新增更多容量來處理任務或增加平行處理。

## 自動調整指標
<a name="glue-streaming-monitoring-metrics-autoscaling"></a>

若您的輸入流量會突然衝高，您應該考慮啟用自動調整功能並指定工作者數目上限。啟用此功能後，您會額外獲得兩個指標，`numberAllExecutors` 和 `numberMaxNeededExecutors`。
+ **numberAllExecutors** 是目前正在執行的任務執行器數量。
+ **numberMaxNeededExecutors** 是滿足目前負載所需的任務執行器最大數目 (正在執行中和擱置中)。

這兩個指標可協助您了解自動調整功能是否正常運作。

![\[螢幕擷取畫面顯示監控串流任務中的自動調整功能。\]](http://docs.aws.amazon.com/zh_tw/glue/latest/dg/images/streaming-monitoring-10autoscaling.png)


AWS Glue 會透過幾個微批次來監控`batchProcessingTimeInMs`指標，並執行下列兩項操作之一。如果 `batchProcessingTimeInMs` 接近 `windowSize`，便會擴展執行器；如果 `batchProcessingTimeInMs` 相對來說低於 `windowSize`，則會縮減執行器。此外，它會使用演算法來逐步調整執行器。
+ 指標 \$11 顯示運作中的執行器如何擴展以趕上所需的執行器數目上限，以便處理負載。
+ 指標 \$12 顯示當 `batchProcessingTimeInMs` 過低，運作中的執行器會如何縮減。

您可以使用這些指標來監控目前的執行器層級平行處理原則，並據此調整自動調整組態中的工作者數目上限。

## 如何獲得最佳效能
<a name="glue-streaming-monitoring-performance"></a>

Spark 會嘗試在 Amazon Kinesis 串流中為每個碎片建立一個任務以進行讀取。每個碎片中的資料即成為一個分割區。然後，它會根據每個工作者的核心數量 (每個工作者的核心數量取決於您選擇的工作者類型，`G.025X`、`G.1X` 等)，將這些任務分配給執行器/工作者。然而，任務的分配方式並無法確定。所有任務都會在各自的核心上平行執行。如果碎片超過可用執行器核心的數量，則會將任務排入佇列。

您可以合併使用上述指標和碎片數量，以佈建執行器提供穩定的負載，為突發流量預留空間。建議您為任務執行幾次反覆運算，以判斷工作者的大致數目。對於不穩定/突然達到尖峰的工作負載，您可以設定自動調整功能和工作者數目上限來完成相同的操作。

根據您業務的 SLA 要求來設定 `windowSize`。舉例來說，如果您的業務要求處理過的資料過時時間不能超過 120 秒，則您應將 `windowSize` 設定為至少 60 秒，以確保平均取用者延遲不超過 120 秒 (請參閱上述「取用者延遲」一節)。根據 `numRecords` 和碎片數量，您可以從這裡規劃 DPU 的容量，以確保您的 `batchProcessingTimeInMs` 在大多數時間皆小於 `windowSize` 的 70％。

**注意**  
熱碎片可能會導致資料扭曲，這表示有部分碎片/分割區比其他碎片大得多。這可能會導致某些平行執行的任務花費更長的時間，因而導致任務落後。因此，在前一批次的所有任務完成之前，無法開始下一批次，這將會使 `batchProcessingTimeInMillis` 和最大延遲受到影響。