Azure 時間序列深入解析 Gen2 事件來源

  • 發行項

注意

2025 年 3 月之後，時間序列深入解析 (TSI) 服務將不再受到支援。 請考慮盡快將現有 TSI 環境移轉至替代解決方案。 如需淘汰和移轉的詳細資訊，請瀏覽我們的文件。

您的 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 範本範例
EarliestAvailable 擷取所有儲存在 IoT 或事件中樞內的既有資料 "ingressStartAt": {"type": "EarliestAvailable"}
EventSourceCreationTime 開始擷取在事件來源建立後送達的資料。 在事件來源建立前串流的任何既有資料，都會被忽略。 這是 Azure 入口網站中的預設設定 "ingressStartAt": {"type": "EventSourceCreationTime"}
CustomEnqueuedTime 您的環境會從自訂排入佇列時間 (UTC) 開始擷取資料。 在自訂排入佇列時間或之後排入 IoT 或事件中樞佇列的所有事件，都會被擷取並儲存。 所有在自訂排入佇列時間之前送達的事件，都會被忽略。 請注意，「排入佇列的時間」是指事件送達 IoT 或事件中樞的時間 (UTC)。 這與事件主體中的自訂時間戳記屬性不同。 "ingressStartAt": {"type": "CustomEnqueuedTime", "time": "2021-03-01T17:00:00.20Z"}

重要

  • 如果您選取 EarliestAvailable，而且有許多既有資料，當 Azure 時間序列深入解析 Gen2 環境處理您所有的資料時，可能會發生高初始延遲。
  • 在資料已編製索引後，這種高延遲最終應會趨緩。 如果您遭遇持續高延遲的情況，請透過 Azure 入口網站提交支援票證。
  • EarliestAvailable

EarliestAvailable 圖表

  • EventSourceCreationTime

EventSourceCreationTime 圖表

  • CustomEnqueuedTime

CustomEnqueuedTime 圖表

串流擷取最佳做法

  • 一律為 Azure 時間序列深入解析 Gen2 環境建立唯一的取用者群組，以取用事件來源中的資料。 重複使用取用者群組可能會導致隨機中斷連線，且可能會導致資料遺失。

  • 在相同的 Azure 區域中設定您的 Azure 時間序列深入解析 Gen2 環境和 IoT 中樞和/或事件中樞。 雖然可以在不同的區域中設定事件來源，但此案例不受支援，且我們無法保證高可用性。

  • 勿超過環境的輸送量速率限制或每個分割區的限制。

  • 設定延遲警示，如此，您在處理資料時若遇到問題就會收到通知。 如需建議的警示條件，請參閱下方的生產工作負載。

  • 僅針對近乎即時和最近的資料使用串流擷取，不支援串流歷程記錄資料。

  • 了解屬性逸出的方式，以及 JSON 資料扁平化和儲存的方式。

  • 提供事件來源連接字串時，請遵循最低權限的原則。 對於事件中樞，請設定僅具有傳送宣告的共用存取原則，對於 IoT 中樞，則僅使用服務連線權限。

警告

如果您刪除了 IoT 中樞或事件中樞，然後使用相同的名稱重新建立新資源，您必須建立新的事件來源，並連結新的 IoT 中樞或事件中樞。 在您完成此步驟前，將不會擷取資料。

生產工作負載

除了上述最佳做法以外，建議您針對業務關鍵工作負載實行下列原則。

  • 將您的 IoT 中樞或事件中樞資料保留時間增加到最大值七天。

  • 在 Azure 入口網站中建立環境警示。 以平台計量為基礎的警示可讓您驗證端對端管線行為。 這裡提供了建立和管理警示的指示。 建議的警示條件：

    • IngressReceivedMessagesTimeLag 大於 5 分鐘
    • IngressReceivedBytes 為 0

  • 在 IoT 中樞或事件中樞分割區之間保持擷取的負載平衡。

歷程記錄資料擷取

Azure 時間序列深入解析 Gen2 中目前不支援使用串流管道來匯入歷史資料。 如果您需要將過去的資料匯入至您的環境，請遵循下列指導方針：

  • 請不要以平行方式串流即時和歷程記錄資料。 擷取不按順序的資料會導致查詢效能降低。
  • 依時間排序的方式擷取歷程記錄資料，以獲得最佳效能。
  • 保持在下列的擷取輸送量速率限制內。
  • 如果資料比您的溫存放區保留期間還舊，請停用溫存放區。

事件來源時間戳記

在設定事件來源時，系統會要求您提供時間戳記識別碼屬性。 時間戳記屬性可用來追蹤一段時間的事件，這是將在查詢 API 中用作時間戳記 $ts 的時間，也是在 Azure 時間序列深入解析總管中用來繪製序列的時間。 如果在建立時未提供屬性，或事件中遺漏了時間戳記屬性，則事件的 IoT 中樞或事件中樞排入佇列時間將會作為預設值。 時間戳記屬性值會以 UTC 格式儲存。

一般而言，使用者會選擇自訂時間戳記屬性，並使用感應器或標籤產生讀數時的時間，而不是使用預設的中樞排入佇列時間。 在裝置連線斷斷續續，且有一批延遲的訊息轉送至 Azure 時間序列深入解析 Gen2 時，更是需要這麼做。

如果您的自訂時間戳記位於巢狀 JSON 物件或陣列內，您就必須依據我們的扁平化和逸出命名慣例，提供正確的屬性名稱。 例如，這裡顯示的 JSON 承載的事件來源時間戳記應輸入為 "values.time"。

時區位移

時間戳記必須以 ISO 8601 格式傳送，並以 UTC 格式儲存。 如果提供了時區位移，則會套用位移，然後以 UTC 格式儲存和傳回時間。 如果位移的格式不正確，則會予以忽略。 如果您的解決方案可能沒有原始位移的內容，您可以另行在個別的事件屬性中傳送位移資料，以確保資料會保存，且您的應用程式可在查詢回應中加以參考。

時區位移應格式化為下列其中之一：

±HHMMZ
±HH:MM
±HH:MMZ

下一步