Azure 時間序列深入解析 Gen2 事件來源
注意
時間序列深入解析服務將於 2024 年 7 月 7 日淘汰。 請考慮儘快將現有的環境移轉至替代解決方案。 如需淘汰和移轉的詳細資訊,請瀏覽我們的 檔。
您的 Azure 時序洞察 Gen2 環境最多可有兩個串流事件來源。 支援兩種類型的 Azure 資源作為輸入:
事件必須以UTF-8編碼的JSON傳送。
建立或編輯事件來源
事件來源是您中樞與 Azure 時間序列深入解析 Gen2 環境之間的連結,而在您的資源群組中會建立 Time Series Insights event source
類型的個別資源。 IoT 中樞或事件中樞資源可以位於與您的 Azure 時間序列深入解析 Gen2 環境相同的 Azure 訂用帳戶中,或者位於不同的訂用帳戶中。 不過,最佳做法是將您的 Azure 時間序列深入解析環境和 IoT 中樞或事件中樞儲存在相同的 Azure 區域內。
您可以使用 Azure 入口網站、Azure CLI、Azure Resource Manager 範本,以及 REST API 來建立、編輯或移除環境的事件來源。
警告
請勿限制公用因特網存取時間序列深入解析所使用的中樞或事件來源,否則必要的連線將會中斷。
開始選項
建立事件來源時,您可以指定應該收集哪些預先存在的數據。 此設定是選擇性的。 有下列選項可供使用:
名字 | 描述 | Azure Resource Manager 範例 |
---|---|---|
最早可用 | 匯入所有儲存在 IoT 或事件中樞中的現有數據 | "ingressStartAt": {"type": "EarliestAvailable"} |
事件來源建立時間 | 開始擷取在建立事件來源之後抵達的數據。 在事件來源建立之前已經串流的任何現有資料都會被忽略。 這是 Azure 入口網站中的預設設定 | "ingressStartAt": {"type": "EventSourceCreationTime"} |
CustomEnqueuedTime | 您的環境會從自定義的加入佇列時間(UTC)開始向前匯入數據。 在自定義加入佇列的時間或之後,所有加入IoT或事件中樞的事件都會內嵌並儲存。 在您自訂的佇列時間之前抵達的所有事件都會被忽略。 請注意,「加入佇列的時間」是指事件抵達IoT或事件中樞的時間(UTC)。 這與您事件內容中的自定義 時間戳記屬性 不同。 | "ingressStartAt": {"type": "CustomEnqueuedTime", "time": "2021-03-01T17:00:00.20Z"} |
重要
- 如果您選取「EarliestAvailable」,而且有大量既有資料,當 Azure 時間序列深入解析 Gen2 環境處理所有資料時,可能會遇到初期高延遲。
- 當數據編製索引時,這種高延遲最終應該會逐漸消退。 如果您遇到持續高延遲,請透過 Azure 入口網站提交支援票證。
- 最早可用
- 事件來源創建時間
- CustomEnqueuedTime
資料串流擷取最佳做法
務必為您的 Azure 時間序列洞察 Gen2 環境建立唯一的消費者群組,以便從事件來源取用資料。 重複使用取用者群組可能會導致隨機中斷連線,並可能導致數據遺失。
在相同的 Azure 區域中配置 Azure 時間序列洞察 Gen2 環境,以及 IoT 中樞或事件中樞。 雖然可以在不同的區域中設定事件來源,但不支援此案例,我們無法保證高可用性。
請勿超出您環境的 輸送量速率限制 或每個分割區的限制。
僅針對近乎即時和最近的數據使用串流擷取,不支援串流歷程記錄數據。
瞭解屬性的逸出方式,以及 JSON 扁平化和儲存的數據。
提供事件來源連接字串時,請遵循最低許可權原則。 針對事件中樞,使用 只傳送 宣告來設定共用存取原則,而IoT中樞則僅使用 服務連線 許可權。
謹慎
如果您刪除IoT中樞或事件中樞,並使用相同的名稱重新建立新的資源,您必須建立新的事件來源,並附加新的IoT中樞或事件中樞。 在您完成此步驟之前,將不會導入資料。
生產工作負載
除了上述最佳做法之外,建議您針對業務關鍵工作負載實作下列專案。
將 IoT 中樞或事件中樞數據保留時間增加到最多七天。
在 Azure 入口網站中建立環境警示。 以平臺 計量為基礎的警示 可讓您驗證端對端管線行為。 建立和管理警示的指示在此處 。 建議的警示條件:
- IngressReceivedMessagesTimeLag 大於 5 分鐘
- IngressReceivedBytes 為 0
在 IoT 中樞或事件中樞分割區之間保持擷取負載平衡。
歷史資料擷取
Azure 時間序列深入解析 Gen2 目前不支援透過串流管線匯入歷史數據。 如果您需要將過去的數據匯入您的環境,請遵循下列指導方針:
- 請勿平行串流即時和歷程記錄數據。 輸入順序錯亂的數據會導致查詢效能降低。
- 以時間排序的方式擷取歷程記錄數據以獲得最佳效能。
- 請維持在以下的匯入吞吐率限制內。
- 如果資料超過您的暖存放區保留期間,請將暖存放區停用。
事件來源時間戳
設定事件來源時,系統會要求您提供時間戳標識符屬性。 timestamp 屬性是用來追蹤一段時間的事件,這是將在 查詢 API 中作為時間戳記 $ts
來使用的時間,以及用於在 Azure 時間序列 Insights 瀏覽器中繪製數列的時間。 如果在建立時未提供任何屬性,或事件遺漏了 timestamp 屬性,則會使用事件 IoT 中樞或事件中樞排入隊列的時間作為預設值。 Timestamp 屬性值會以 UTC 儲存。
一般而言,用戶會選擇自訂時間戳屬性,並使用感測器或標籤產生讀取的時間,而不是使用預設中樞排入佇列的時間。 當裝置發生間歇性連線中斷,且一批延遲的訊息會轉送至 Azure Time Series Insights Gen2 時,如此行為特別必要。
如果您的自定義時間戳位於巢狀 JSON 物件或陣列內,您必須遵循 扁平化和轉義命名慣例提供正確的屬性名稱。 例如,此處所顯示 JSON 承載的事件來源時間戳 應輸入為 "values.time"
。
時區位移
時間戳必須以 ISO 8601 格式傳送,並以 UTC 儲存。 如果提供時區位移,則會套用位移,然後以UTC格式儲存和傳回的時間。 如果位移的格式不正確,則會忽略它。 如果您的解決方案可能沒有原始偏移的上下文,您可以將偏移量資料傳送至一個單獨的事件屬性中,以確保它被保留,並且讓您的應用程式可以在查詢回應中進行參考。
時區位移應格式化成下列格式之一:
±HHMMZ
±HH:MM
±HH:MMZ
後續步驟
閱讀 JSON 扁平化和逸出規則 以瞭解事件儲存方式。
瞭解您環境的 輸送量限制