使用計量監視佇列擷取

在佇列擷取程式中，Azure 數據總管會根據可設定的擷取批處理原則，將傳入的小型數據區塊批處理成批次，以優化高輸送量的數據擷取。 批處理原則可讓您設定密封批次的觸發條件（數據大小、Blob 數目或經過的時間）。 然後，這些批次會以最佳方式內嵌以取得快速的查詢結果。

在本文中，您將瞭解如何在 Azure 入口網站 中使用計量來監視對 Azure 數據總管的佇列擷取。

批處理階段

本節所述的階段適用於所有批處理擷取。 針對 Azure 事件方格、Azure 事件中樞、Azure IoT 中樞 和 Cosmos DB 擷取，在數據排入佇列以擷取數據之前，數據連線會從外部來源取得數據，並執行初始數據重新排列。

佇列擷取會分階段進行：

1. Batching Manager 會接聽佇列以擷取訊息和處理要求。
2. Batching Manager 會採用它根據擷取批處理原則接收的小型輸入數據區塊，並將URL批處理，藉此優化擷取輸送量。
3. 擷取管理員會將擷取命令傳送至 Azure 資料總管記憶體引擎。
4. Azure 數據總 管記憶體引擎 會儲存內嵌的數據，使其可供查詢。

Azure 數據總管提供一組 Azure 監視器 擷取計量 ，讓您能夠監視佇列擷取程式的所有階段和元件的數據擷取。

Azure 數據總管擷取計量可提供下列詳細資訊：

• 佇列擷取的結果。
• 擷取的數據量。
• 佇列擷取的延遲及其發生位置。
• 批處理程式本身。
• 針對事件中樞、事件方格和 IoT 中樞 擷取：收到的事件數目。

在本文中，您將瞭解如何使用 Azure 入口網站 中的擷取計量來監視佇列擷取至 Azure 數據總管。

必要條件

• Azure 訂用帳戶。 建立免費的 Azure 帳戶。
• Azure 資料總管叢集和資料庫。 建立叢集和資料庫。
• 作用中佇列擷取，例如事件中樞、IoT 中樞 或事件方格。

使用 Azure 監視器計量總管建立計量圖表

以下是如何使用 Azure 監視器計量的一般說明，這些計量將在後續各節中實作。 使用下列步驟，在 Azure 入口網站 中使用 Azure 監視器計量總管建立計量圖表：

1. 登入 Azure 入口網站，並流覽至 Azure 數據總管叢集的概觀頁面。

2. 從左側導覽列選取 [計量 ]，以開啟 [計量] 窗格。

3. 開啟計量窗格右上方的時間選擇器面板，並將 [時間範圍] 變更為您想要分析的時間。 在本文中，我們會分析過去 48 小時內將數據擷取至 Azure 數據總管。

4. 選取範圍和計量命名空間：

   • 範圍是 Azure 數據總管叢集的名稱。 在下列範例中，我們將使用名為 demo11 的叢集。
   • 計量 命名空間 應設定為 Kusto 叢集標準計量。 這是包含 Azure 資料總管計量的命名空間。

   

5. 選取 [ 計量 名稱] 和相關的 [匯總 ] 值。

針對本文中的一些範例，我們將針對具有維度的計量選取 [新增篩選] 和 [套用分割]。 我們也會使用 [新增計量 ] 來繪製相同圖表中的其他計量，以及 [+ 新增] 圖表，在一個檢視中查看多個圖表 。

每次新增計量時，您都會重複步驟 4 和 5。

注意

若要深入瞭解如何使用計量來監視 Azure 數據總管，以及如何使用計量窗格，請參閱 使用計量監視 Azure 數據總管效能、健康情況和使用方式。

在本文中，您將瞭解哪些計量可用來追蹤佇列擷取，以及如何使用這些計量。

檢視擷取結果

擷取結果計量提供成功擷取的來源總數，以及無法擷取的來源總數的相關信息。

在此範例中，我們將使用此計量來檢視擷取嘗試的結果，並使用狀態資訊來協助針對任何失敗的嘗試進行疑難解答。

1. 在 Azure 監視器的 [ 計量] 窗格中，選取 [ 新增計量]。
2. 選取 [擷取結果] 作為 [計量] 值，然後選取 [總和] 作為 [匯總] 值。 此選取範圍會顯示一個圖表折線中一段時間的擷取結果。
3. 選取圖表上方的 [ 套用分割] 按鈕，然後選擇 [狀態 ] 以依擷取結果的狀態分割您的圖表。 選取分割值之後，按兩下 [遠離分割選取器] 將其關閉。

現在計量資訊會依狀態分割，我們可以看到擷取結果狀態的相關信息分割成三行：

1. 成功擷取作業的藍色。
2. 由於找不到實體而失敗的擷取作業，則為 Orange。
3. 由於要求不正確，擷取作業失敗的紫色。

查看擷取結果的圖表時，請考慮下列事項：

• 使用事件中樞或IoT中樞擷取時，數據聯機組件中有事件預先匯總。 在擷取的這個階段，事件會被視為要內嵌的單一來源。 因此，在預先匯總之後，一些事件會顯示為單一擷取結果。
• 暫時性失敗會在有限的嘗試次數內部重試。 每個暫時性失敗都會回報為暫時性擷取結果。 這就是為什麼單一擷取可能會導致多個擷取結果的原因。
• 圖表中的擷取錯誤會依錯誤碼的類別列出。 若要查看依類別擷取錯誤碼的完整清單，並嘗試進一步瞭解可能的錯誤原因，請參閱 Azure 數據總管中的擷取錯誤碼。
• 若要取得擷取錯誤的詳細資訊，您可以設定 失敗的擷取診斷記錄。 不過，請務必考慮產生記錄會導致建立額外的資源，因而增加 COGS（銷售的商品成本）。

檢視擷取的數據量

Blob 已處理、Blob 已接收和 Blob 已卸除的計量會提供佇列擷取階段內嵌元件所處理、接收和卸除 Blob 數目的相關信息。

在此範例中，我們將使用這些計量來查看透過擷取管線傳遞的數據量、擷取元件接收的數據量，以及卸除的數據量。

已處理的 Blob

1. 在 Azure 監視器的 [ 計量] 窗格中，選取 [ 新增計量]。
2. 選取 [處理為計量] 值的 [Blob]，然後選取 [總和] 作為 [匯總] 值。
3. 選取 [ 套用分割] 按鈕，然後選擇 [元件類型 ]，依不同的擷取元件分割圖表。
4. 若要將焦點放在叢集中的特定資料庫，請選取 圖表上方的 [新增篩選] 按鈕，然後選擇繪製圖表時要包含的資料庫值。 在此範例中，我們會選取 [資料庫] 作為 [屬性]、[運算符] 和 [值] 下拉式清單中的 GitHub，來篩選傳送至 =資料庫的 Blob。 選取篩選值之後，按兩下 [離開篩選選取器] 以關閉它。

現在圖表會顯示在一段時間內每個擷取元件上已處理多少個傳送至 GitHub 資料庫的 Blob。

• 請注意，在 2 月 13 日，擷取至 GitHub 資料庫的 Blob 數目會隨著時間減少。 此外，請注意，在每一個元件上處理的 Blob 數目類似，這表示大約數據連接元件中的所有數據也會由 Batching Manager、擷取管理員和 Azure 數據總管記憶體引擎元件順利處理。 此數據已準備好進行查詢。

已接收的 Blob

為了進一步瞭解每個元件上收到的 Blob 數目與每個元件上成功處理的 Blob 數目之間的關聯性，我們將新增圖表：

1. 選取 [+ 新增圖表]。
2. 針對 [範圍]、 [計量命名空間] 和 [匯總] 選擇上述值，然後選取 [Blob 已接收的 計量]。
3. 選取 [ 套用分割] 按鈕，然後選擇 [ 元件類型 ] 以依元件類型分割 [Blob 接收的 計量]。
4. 選取 [ 新增篩選] 按鈕，並設定與之前相同的值，只篩選傳送至 GitHub 資料庫的 Blob。

• 比較圖表時，請注意，每個元件收到的 Blob 數目會與每個元件所處理的 Blob 數目緊密相符。 此比較表示擷取期間未卸除任何 Blob。

Blob 已卸除

若要判斷擷取期間是否已卸除 Blob，您應該分析 Blob 已卸除 的計量。 此計量顯示擷取期間已卸除的 Blob 數目，並協助您偵測特定擷取元件是否有問題處理。 針對每個已卸除的 Blob，您也會取得 擷取結果 計量，其中包含失敗原因的詳細資訊。

檢視擷取延遲

計量階段 延遲 和 探索延遲 監視擷取程式中的延遲，並告訴您 Azure 數據總管中是否有任何長時間的延遲，或數據到達 Azure 數據總管進行擷取之前。

• 階段延遲 表示 Azure 數據總管探索訊息的時間範圍，直到擷取元件收到訊息以供處理為止。
• 探索延遲 用於擷取具有數據連線的管線（例如事件中樞、IoT 中樞和事件方格）。 此計量提供從數據佇列到 Azure 數據總管數據連線探索的時間範圍相關信息。 這個時間範圍是上游至 Azure 數據總管，因此不會包含在「階段延遲」計量中，只測量 Azure 數據總管中的延遲。

注意

根據預設 批處理原則，預設批處理時間為五分鐘。 因此，如果批次未由其他觸發程式密封，批次將會在五分鐘后密封。

當您看到長時間延遲直到數據準備好進行查詢時，分析 階段延遲 和 探索延遲 可協助您了解長時間延遲是因為 Azure 數據總管中的長時間延遲，還是上游至 Azure 數據總管。 當延遲位於 Azure 數據總管本身時，您也可以偵測負責長時間延遲的特定元件。

階段延遲 （預覽）

讓我們先看看佇列擷取的階段延遲。 如需每個階段的說明，請參閱 批處理階段。

1. 在 Azure 監視器的 [ 計量] 窗格中，選取 [ 新增計量]。
2. 選取 [階段延遲] 作為 [計量] 值，然後選取 [平均] 作為 [匯總] 值。
3. 選取 [ 套用分割] 按鈕，然後選擇 [元件類型 ]，依不同的擷取元件分割圖表。
4. 選取 [ 新增篩選] 按鈕，並篩選傳送至 GitHub 資料庫的數據。 選取篩選值之後，按兩下 [離開篩選選取器] 以關閉它。 現在圖表顯示擷取作業的延遲，這些作業會透過一段時間的擷取，在每個元件傳送至 GitHub 資料庫：

我們可以從此圖表中得知下列資訊：

• 事件中 樞數據連線 元件的延遲大約是 0 秒。 這很合理，因為 階段延遲 只會測量 Azure 數據總管探索到訊息時的延遲。
• 擷取程式中最長的時間（大約 5 分鐘）從 Batching Manager 元件接收數據到擷取管理員元件收到數據的時間。 在此範例中，我們會使用 GitHub 資料庫的預設批處理原則。 如前所述，預設批處理原則的延遲時間限製為5分鐘，因此這很可能表示幾乎所有的數據都是依時間批處理，而佇列擷取的大部分延遲時間都是因為批處理本身所致。
• 圖表中的記憶體引擎延遲代表數據儲存在 Azure 數據總管記憶體引擎中並準備好進行查詢的延遲。 您可以看到 Azure 數據總管的數據探索時間的平均總延遲，直到查詢就緒為 5.2 分鐘為止。

探索延遲

如果您搭配數據連線使用擷取，您可能會想要在 Azure 數據總管取得擷取數據之前，預估上游到 Azure 數據總管的延遲時間。 為此，您可以使用 探索延遲 計量。

1. 選取 [+ 新增圖表]。
2. 選取 [探索延遲] 作為 [計量] 值，然後選取 [平均] 作為 [匯總] 值。
3. 選取 [ 套用分割] 按鈕，然後選擇 [元件類型 ] 以依不同的數據聯機組件類型分割圖表。 選取分割值之後，按兩下 [遠離分割選取器] 將其關閉。

• 您可以看到，在大部分的持續時間中，探索延遲接近 0 秒，表示 Azure 數據總管在數據加入佇列之後取得數據。 大約 300 毫秒的最高尖峰是在 2 月 13 日 14：00 左右，表示目前 Azure 數據總管叢集在數據加入佇列後收到大約 300 毫秒的數據。

瞭解批處理程式

在佇列擷取流程的第二個階段中，Batching Manager 元件會根據擷取批處理原則所接收的數據，將擷取輸送量優化。

下列一組計量可協助您了解數據在擷取期間如何批處理：

• 已處理的批次：完成擷取的批次數目。
• 批次大小：針對擷取而匯總的批次中未壓縮數據的估計大小。
• 批次持續時間：從批次開啟到批次密封的那一刻起，每個個別批次的持續時間。
• 批次 Blob 計數：擷取已完成批次中的 Blob 數目。

已處理的批次

讓我們藉由查看 Batch 所處理 計量，從批處理程式的整體檢視開始。

1. 在 Azure 監視器的 [ 計量] 窗格中，選取 [ 新增計量]。
2. 選取 [處理批次] 作為 [計量] 值，然後選取 [總和] 作為 [匯總] 值。
3. 選取 [ 套用分割] 按鈕，然後選擇 [批處理類型 ]，根據批次密封的原因分割圖表。 如需批處理類型的完整清單，請參閱 批處理類型。
4. 選取 [ 新增篩選] 按鈕，並篩選傳送至 GitHub 資料庫的批次。 選取篩選值之後，按兩下 [離開篩選選取器] 以關閉它。

此圖表顯示密封批次的數目，其中數據會隨著時間傳送至 GitHub 資料庫，依批處理類型分割。

• 請注意，每個時間單位各有 2-4 個批次，而且所有批次都會依時間密封，如 [階段延遲] 區段中估計，您可以看到根據預設批處理原則來批處理數據大約需要 5 分鐘的時間。

批次持續時間、大小和 Blob 計數

現在讓我們進一步描述已處理的批次。

1. 選取每個圖表的 [ + 新增圖表 ] 按鈕，為 [計量 ] 值 [批次持續時間]、 [批次大小] 和 [批次 Blob 計數] 建立更多圖表。
2. 使用 Avg 作為 匯總 值。
3. 如上一個範例所示，選取 [ 新增篩選] 按鈕，並篩選傳送至 GitHub 資料庫的數據。

從批次持續時間、批次大小和 Batch Blob 計數圖表中，我們可以得出一些深入解析：

• 平均批次持續時間為五分鐘（根據預設批處理原則）。 在查看總擷取延遲時，您應該將此納入考慮。

• 在 [ 批次大小] 圖表中，您可以看到批次的平均大小在一段時間內約為 200-500 MB。 要擷取之數據的最佳大小是 1 GB 的未壓縮數據，而且預設批處理原則也會將此大小定義為密封條件。 由於沒有 1 GB 的數據會隨著時間進行批處理，因此不會看到任何依大小密封的批次。

• 批次中的 Blob 平均數目大約是一段時間內的 160 個 Blob，然後減少到 60-120 個 Blob。 根據預設批處理原則，當 Blob 計數為 1000 個 Blob 時，批次可以密封。 由於我們未到達此數位，因此不會看到依計數密封的批次。

比較接收的事件與傳送來擷取的事件

套用事件中樞、IoT 中樞或事件方格擷取時，比較 Azure 數據總管所接收的事件數目與從事件來源傳送至 Azure 數據總管的事件數目相當有用。 「已接收的事件」、「已處理的事件」和「已卸除的事件」計量可讓您進行這項比較。

已接收的事件

1. 在 Azure 監視器的 [ 計量] 窗格中，選取 [ 新增計量]。
2. 選取 [已接收的事件] 作為 [計量] 值，然後選取 [總和] 作為 [匯總] 值。
3. 選取圖表上方的 [新增篩選] 按鈕，然後選擇 [屬性值元件名稱] 來篩選叢集上定義之特定數據連線所收到的事件。 在此範例中，我們會篩選 GitHubStreamingEvents 數據連線。 選取篩選值之後，按兩下 [離開篩選選取器] 以關閉它。

現在圖表會顯示所選取資料連接在一段時間內收到的事件數目：

• 在此圖表中 ，GitHubStreamingEvents 數據聯機會隨著時間單位接收大約 200-500 個事件。

已處理的事件和已卸除的事件

若要查看 Azure 數據總管是否捨棄任何事件，請使用 [已處理的事件] 和 [已卸除的事件] 計量。

1. 在您已建立的圖表上，選取 [ 新增計量]。
2. 選取 [已處理的事件] 作為 [計量] 值，然後選取 [總和] 作為 [匯總] 值。
3. 再次選取 [新增計量]，然後選取 [已卸除的事件] 作為 [計量] 值，然後選取 [總和] 作為 [匯總] 值。

此圖表現在會顯示 GitHubStreamingEvents 數據連線在一段時間內接收、處理和卸除的事件數目。

• 幾乎所有已接收的事件都由數據連線成功處理。 有一個已卸除的事件，這與失敗的擷取結果相容，因為檢視擷取結果計量時看到的要求不正確。

比較 Azure 數據總管中收到的事件與事件中樞的傳出訊息

您也可以藉由比較事件接收和傳出訊息計量，比較從事件中樞傳送至 Azure 數據總管的事件數目。

1. 在您已為 [已接收的事件] 建立的圖表上，選取 [ 新增計量]。

2. 選取 [範圍 ]，然後在 [選取範圍 ] 對話框中，流覽並選取傳送數據至數據連線的事件中樞命名空間。

   

3. 選取 [套用]

4. 選取 [傳出訊息] 作為 [計量] 值，然後選取 [總和] 作為 [匯總] 值。

單擊 [遠離設定] 以取得完整圖表，以比較 Azure 數據總管數據連線所處理的事件數目與從事件中樞傳送的事件數目。

• 請注意，從事件中樞傳送的所有事件都會由 Azure 數據總管數據連線成功處理。
• 如果您在事件中樞命名空間中有多個事件中樞，您應該依 [實體名稱] 維度篩選 [傳出訊息] 計量，以只從事件中樞命名空間中所需的事件中樞取得數據。

注意

沒有選項可監視每個取用者群組的傳出訊息。 外 寄訊息 計量會計算所有取用者群組所取用的訊息總數。 因此，如果您的事件中樞內有幾個取用者群組，您可能會得到比收到的事件更大的傳出訊息數目。

相關內容

• 使用計量監視 Azure 數據總管的效能、健康情況和使用方式
• 使用診斷記錄監視 Azure 數據總管擷取、命令、查詢和數據表
• 使用 Azure 監視器深入解析