監視和降低節流,以減少 Azure 時間序列深入解析 Gen1 中的延遲
注意
時間序列深入解析服務將於 2024 年 7 月 7 日淘汰。 請考慮儘快將現有的環境移轉至替代解決方案。 如需淘汰和移轉的詳細資訊,請造訪我們的文件。
警告
這是 Gen1 文章。
當傳入的數據量超過環境的設定時,您可能會在 Azure 時間序列深入解析 遇到延遲或節流。
您可以針對您想要分析的數據量正確設定環境,以避免延遲和節流。
您最有可能在下列情況下遇到延遲和節流:
- 新增事件來源,其中包含可能超過您分配輸入速率的舊數據(Azure 時間序列深入解析 需要趕上)。
- 將更多事件來源新增至環境,導致其他事件的尖峰(可能超過您環境的容量)。
- 將大量的歷史事件推送至事件來源,導致延遲(Azure 時間序列深入解析 需要趕上)。
- 將參考數據與遙測聯結,以產生較大的事件大小。 允許的封包大小上限為 32 KB;大於 32 KB 的數據封包會被截斷。
影片
瞭解 Azure 時間序列深入解析 數據輸入行為,以及如何規劃數據輸入行為。
使用警示監視延遲和節流
警示可協助您診斷並減輕環境中發生的延遲問題。
在 Azure 入口網站 中,選取您的 Azure 時間序列深入解析 環境。 然後選取 [ 警示]。
選取 [+ 新增警示規則]。 然後會顯示 [ 建立規則 ] 面板。 選取 [條件] 底下的 [新增]。
接下來,設定訊號邏輯的確切條件。
您可以從該處使用下列一些條件來設定警示:
計量 描述 輸入接收的位元組 從事件來源讀取的原始位元組計數。 原始計數通常包含屬性名稱和值。 輸入收到無效的訊息 從所有 Azure 事件中樞 或 Azure IoT 中樞 事件來源讀取的無效訊息計數。 輸入接收的訊息 從所有事件中樞或 IoT 中樞 事件來源讀取的訊息計數。 輸入預存位元組 儲存和可供查詢的事件大小總計。 大小只會計算在屬性值上。 輸入預存事件 已儲存且可供查詢的扁平化事件計數。 輸入接收的訊息時間延遲 訊息在事件來源中加入佇列的時間與在輸入中處理時間之間的秒數差異。 輸入接收的訊息計數延遲 事件來源數據分割中最後一個加入佇列訊息的序號與輸入中正在處理的訊息序號之間的差異。 選取完成。
設定所需的訊號邏輯之後,請以可視化方式檢閱所選的警示規則。
節流和輸入管理
如果您要進行節流處理,則會註冊輸入接收的訊息時間延隔時間延遲值,通知您 Azure 時間序列深入解析 環境背後的秒數,從訊息到達事件來源的實際時間(不包括 appx 的編製索引時間。30-60 秒)。
輸入接收的訊息計數延遲 也應該有值,讓您判斷您背後的訊息數目。 趕上最簡單的方式是將環境容量提高到可讓您克服差異的大小。
例如,如果您的 S1 環境示範延遲 5,000,000 則訊息,您可能會將環境的大小增加到大約一天六個單位來趕上。 您可以進一步增加以加快趕上速度。 一開始布建環境時,追趕期間是常見的情況,特別是當您將它連線到事件來源時,該來源已經有事件,或當您大量上傳許多歷程記錄數據時。
另一個技巧是設定 輸入預存事件 警示 >= 臨界值略低於您的環境總容量 2 小時。 此警示可協助您瞭解您是否經常處於容量狀態,這表示延遲的可能性很高。
例如,如果您已佈建三個 S1 單位(或每分鐘輸入容量 2100 個事件),您可以針對 = 1900 事件設定 2 小時輸入預存事件 警示 >。 如果您持續超過此閾值,因此觸發警示時,可能會布建不足。
如果您懷疑自己正在進行節流,您可以比較輸入 已接收的訊息 與事件來源的輸出訊息。 如果輸入至事件中樞大於您的輸入已接收訊息,您的 Azure 時間序列深入解析 可能會受到節流。
改善效能
若要減少節流或遇到延遲,最佳方式是增加環境的容量。
您可以針對您想要分析的數據量正確設定環境,以避免延遲和節流。 如需如何將容量新增至環境的詳細資訊,請參閱 調整您的環境。
下一步
閱讀診斷和解決您 Azure 時間序列深入解析 環境中的問題。
瞭解如何調整 Azure 時間序列深入解析 環境。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應