監視和降低節流，以減少 Azure 時間序列深入解析 Gen1 中的延遲

注意

時間序列深入解析服務將於 2024 年 7 月 7 日淘汰。 請考慮儘快將現有的環境移轉至替代解決方案。 如需淘汰和移轉的詳細資訊，請瀏覽我們的 檔。

謹慎

這是 Gen1 文章。

當傳入的數據量超過環境的設定時，您可能會在 Azure 時間序列深入解析中遇到延遲或節流。

您可以針對您想要分析的數據量正確設定環境，以避免延遲和節流。

您最有可能在下列情況下遇到延遲和限流：

• 新增事件來源，其中包含可能超過您分配輸入速率的舊數據（Azure 時間序列深入解析將需要趕上）。
• 將更多事件來源新增至環境，導致事件數量激增（可能超過您環境的負荷能力）。
• 將大量的歷史事件推送至事件來源，可能造成延遲（Azure 時間序列深入解析需要補上）。
• 將參考數據與遙測聯結，以產生較大的事件大小。 允許的封包大小上限為 32 KB;大於 32 KB 的數據封包會被截斷。

視頻

瞭解 Azure 時間序列資訊的數據攝取行為，以及如何進行規劃。

使用警示監視延遲和節流

警示可協助您診斷並減輕環境中發生的延遲問題。

1. 在 Azure 入口網站中，選取您的 Azure 時間序列深入解析環境。 然後選取 警示。

   

2. 選擇 + 新增警示規則。 [建立規則] 面板隨即顯示。 在 [條件] 底下，選取 [] 和在 [] 中新增 []。

   

3. 接下來，設定訊號邏輯的確切條件。

   

   您可以從該處使用下列一些條件來設定警示：

   度量	描述
   輸入接收的位元組	從事件來源讀取的原始位元組計數。 原始計數通常包含屬性名稱和值。
   入口收到無效訊息	從所有 Azure 事件中樞或 Azure IoT 中樞事件來源讀取的無效訊息計數。
   輸入接收的訊息	從所有事件中樞或 IoT 中樞的事件來源讀取的訊息數量。
   流入儲存位元組	儲存和可供查詢的事件大小總計。 大小只會根據屬性值來計算。
   進入儲存事件	已儲存且可供查詢的扁平化事件計數。
   輸入接收的訊息時間延遲	訊息在事件來源加入佇列的時間與在 Ingress 處理的時間之間的秒數差異。
   輸入接收的訊息計數延遲	事件來源數據分割中最後一個加入佇列訊息的序號與輸入中正在處理的訊息序號之間的差異。

   選擇 完成。

4. 設定所需的訊號邏輯之後，請以可視化方式檢閱所選的警示規則。

   

節流和入口管理

• 如果您的 Azure 時間序列深入解析環境受到限制，將會註冊一個 輸入接收的訊息時間延遲 的值，告知您 Azure 時間序列深入解析環境時間相對於訊息到達事件來源的實際時間延遲了多少秒（不包括大約30-60秒的編製索引時間）。

  輸入接收的訊息計數延遲 也應該有值，讓您判斷您背後的訊息數目。 趕上的最簡單方式是將您的環境容量提高到可讓您克服這些差距的大小。

  例如，如果您的 S1 環境經歷 5,000,000 則訊息的延遲，您可能會將環境的大小增加到六個單位，維持大約一天，以追上進度。 您可以進一步增加以加快趕上速度。 在一開始布建環境時，追補期間是常見的情況，特別是當您將其連接到一個已經有事件的事件來源，或當您大量上傳歷史數據時。

• 另一個技巧是設定 入口預存事件 警示 >= 臨界值略低於您的環境總容量，設定時間為 2 小時。 此警示可協助您瞭解您是否經常處於容量狀態，這表示延遲的可能性很高。

  例如，如果您已佈建三個 S1 單位（或每分鐘輸入容量 2100 個事件），您可以設定 輸入預存事件 警示，>= 1900 個事件 2 小時。 如果您持續超過此閾值，導致觸發警示，這可能表示您的資源配置不足。

• 如果您懷疑自己被限速，您可以比較 接收的流入訊息 與事件來源已傳出的訊息。 如果進入您的事件中樞的資料多於 收到輸入的訊息，您的 Azure 時間序列見解可能會受到限制。

改善效能

若要減少節流或遇到延遲，最佳方式是增加環境的容量。

您可以針對您想要分析的數據量正確設定環境，以避免延遲和節流。 如需進一步了解如何擴充環境的容量，請參閱 調整您的環境。

後續步驟

• 閱讀 診斷和解決 Azure 時間序列深入解析環境中的問題。

• 瞭解 如何調整 Azure 時間序列洞察環境。