此架構描述解決方案，可提供系統與使用者裝置遙測數據的即時監視和可觀察性。 它著重於媒體產業的使用案例。
Grafana 是其各自公司的商標。 使用此標記時不會隱含任何背書。
架構
下載此架構的 Visio 檔案。
資料流程
在圖表中顯示的可觀察系統中，原始遙測會透過 HTTP 和連接器串流至 Azure Blob 儲存體。 原始遙測會經過處理、轉換、正規化，並儲存在 Azure 數據總管中進行分析。 Grafana 和 Azure Metrics Advisor 等系統會從數據總管讀取數據，並提供用戶見解。
更具體來說，這些是圖表中系統的元素：
- 檢測。 檢測會透過安裝在系統中的探查或代理程式來監視數據。 這些代理程式會以各種形式出現。 例如，在視訊隨選串流平臺中，公司可能會使用開放式標準 dash.js 從客戶收集體驗品質計量。
- 擷取。 此原始遙測可以直接透過 HTTP 呼叫從終端用戶端取得。 或者，您可以透過第三方系統將它上傳至持續性記憶體和數據湖，例如 Blob 記憶體。 部落格記憶體支援上傳新檔案時叫用 Azure 函式的功能。 您可以使用此觸發機制，將原始遙測移至結構化數據倉儲。
- 轉換和持續性。 您可能需要轉換系統來正規化您的資料。 Azure Functions 應用程式會視需要轉換數據，然後將它寫入數據總管。 數據總管非常適合巨量數據分析，因為它專為大型數據集的高效能和輸送量而設計。
- 監視。 Azure Managed Grafana 支援與數據總管整合。 您可以使用 Grafana 的拖放功能，快速建置儀錶板和圖表。 Grafana 非常適合媒體監視，因為它提供儀錶板磚的次分鐘重新整理，也可用於警示。
- 異常偵測。 Grafana 儀錶板支援 NOC 中的手動監視。 不過，由於大型數據集和使用者基底分散在地理位置，並使用各種裝置，透過具有硬式編碼閾值的圖表和警示規則手動識別問題會變得沒有效率。 您可以使用 AI 來解決此問題。 Metrics Advisor 之類的服務會使用機器學習演算法，根據時間序列數據自動瞭解和偵測異常。 此外，Kusto 數據平臺具有內建的異常偵測功能，可考慮數據的季節性和基準趨勢。
元件
- 數據總 管是受控數據分析服務，可即時分析大量數據。 數據總管是處理需要高速且輸送量數據擷取的大型數據集的絕佳工具。 此架構會使用數據總管來儲存和查詢數據集進行分析。
- Blob 記憶體 可用來保存原始遙測。 此遙測可能來自您的應用程式和服務，或來自第三方廠商。 如果您稍後不需要執行更多分析，可以將數據視為暫時性。 來自 Blob 記憶體的數據會內嵌至數據總管叢集。
- Azure 事件方格 是事件傳遞系統。 它用來接聽 Blob 記憶體所發行的事件。 Azure 儲存體 事件可讓應用程式回應建立和刪除 Blob 等事件。 Azure 函式會訂閱事件方格所發佈的事件。
- Azure 事件中樞 是實時數據擷取服務，可讓您用來從任何來源每秒擷取數百萬個事件。 事件中樞代表事件管線的前門，通常稱為事件 擷取器。 事件擷取器是位於事件發行者和事件取用者之間的元件或服務。 它會將事件數據流的生產與事件的耗用量分離。
- Azure Functions 是無伺服器解決方案，可用來剖析和轉換透過 HTTP 和 Blob 端點擷取的數據，以及寫入數據總管叢集。
- Azure 受控 Grafana 可以輕鬆地連線到數據總管。 在此架構中，它會產生圖表和儀錶板，以可視化方式呈現遙測數據。 Azure 受控 Grafana 提供與 Microsoft Entra ID 的深入整合，讓您可以實作儀錶板和檢視的角色型存取。
- Metrics Advisor 是 Azure 套用 AI 服務的一部分。 它會使用 AI 在時間序列資料中執行數據監視和異常偵測。 Metrics Advisor 會將模型套用至數據的程式自動化，並提供一組 API 和 Web 型工作區來擷取數據、異常偵測和診斷。 即使您不知道機器學習，也可以使用它。
替代項目
Azure Data Factory 和 Azure Synapse Analytics 提供工具和工作區，可用來建置 ETL 工作流程，以及從圖形化介面追蹤和重試作業的能力。 請注意，Data Factory 和 Azure Synapse 兩者在擷取到持續性之間的延遲時間至少為 5 分鐘。 監視系統中可能會接受此延隔時間。 如果是，建議您考慮這些替代方案。
案例詳細資料
組織通常會部署各種大型技術來解決商務問題。 這些系統和用戶裝置會產生大量的遙測數據集。
此架構是以媒體產業的使用案例為基礎。 即時和視訊隨選播放的媒體串流需要近乎即時的識別和回應應用程式問題。 為了支援此即時案例，組織必須收集需要可調整架構的大規模遙測集。 收集數據之後，需要其他類型的分析，例如 AI 和異常偵測，才能有效率地識別大型數據集的問題。
部署大規模技術時，與它們互動的系統與用戶裝置會產生大量的遙測數據集。 在傳統案例中，這項數據會透過數據倉儲系統進行分析，以產生可用於支援管理決策的深入解析。 這種方法在某些案例中可能運作，但對於串流媒體使用案例而言，回應不夠。 若要解決此問題，監視伺服器、網路和與其互動的使用者裝置所產生的遙測數據需要即時深入解析。 攔截失敗和錯誤的監視系統很常見，但近乎即時地攔截它們很困難。 這就是此架構的重點。
在即時串流或視訊隨選設定中，遙測數據會從系統和異質用戶端（行動裝置、桌面和電視）產生。 解決方案牽涉到取得原始數據，並將內容與數據點產生關聯，例如地理位置、使用者操作系統、內容標識碼和 CDN 提供者等維度。 原始遙測會收集、轉換並儲存在數據總管中進行分析。 然後，您可以使用 AI 來了解數據，並將觀察和警示的手動程式自動化。 您可以使用 Grafana 和 Metrics Advisor 之類的系統，從數據總管讀取數據，以顯示互動式儀錶板和觸發警示。
考量
這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。
可靠性
可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性的設計檢閱檢查清單。
業務關鍵性應用程式必須在干擾性事件期間持續執行，例如 Azure 區域或 CDN 中斷。 在系統中建置備援有兩個主要策略和一個混合式策略：
- 使用中/主動。 重複的程式代碼和函式正在執行。 任一系統都可以在失敗期間接管。
- 作用中/待命。 只有一個節點是作用中/主要節點。 另一個節點已準備好接管，以防主要節點關閉。
- 混合。 某些元件/服務位於作用中/主動組態中，有些則處於作用中/待命狀態。
請記住，並非所有 Azure 服務都有內建備援。 例如，Azure Functions 只會在特定區域中執行函式應用程式。 Azure Functions 異地災害復原 說明您可以實作的各種策略，視函式的觸發方式而定（HTTP 與 pub/sub）。
擷取和轉換函式應用程式可以在作用中/主動模式中執行。 您可以在作用中/主動和主動/待命組態中執行數據總管。
Azure 受控 Grafana 支援 可用性區域備援。 建立跨區域備援的其中一個策略是在部署數據總管叢集的每個區域中設定 Grafana。
成本優化
成本優化是考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。
此架構的成本取決於輸入遙測事件數目、Blob 記憶體和數據總管中原始遙測的記憶體、Azure Managed Grafana 的每小時成本，以及 Metrics Advisor 中時間序列圖表數目的靜態成本。
您可以使用 Azure 定價計算機 來預估每小時或每月成本。
效能效率
效能效率是工作負載調整的能力，以符合使用者以有效率的方式滿足其需求。 如需詳細資訊，請參閱 效能效率的設計檢閱檢查清單。
根據傳入要求的規模和頻率而定，函式應用程式可能是瓶頸，原因有兩個：
- 冷啟動。 冷啟動是無伺服器執行的結果。 它是指在函式第一次開始執行之前啟動環境所需的排程和設定時間。 最多需要幾秒的時間。
- 要求的頻率。 假設您有 1,000 個 HTTP 要求，但只有單個線程伺服器來處理它們。 您無法同時服務所有 1,000 個 HTTP 要求。 若要及時提供這些要求，您需要部署更多伺服器。 也就是說，您需要水平調整。
我們建議您使用進階或專用 SKU 來：
- 消除冷啟動。
- 藉由相應增加或減少維護虛擬機的數目，來處理並行要求的需求。
如需詳細資訊，請參閱 選取 Azure 數據總管叢集的 SKU。
部署此案例
如需部署此案例的相關信息，請參閱 GitHub 上的即時監視和可觀察性 。 此程式代碼範例包含必要的基礎結構即程式代碼 （IaC）來啟動程序開發，以及 Azure 函式以內嵌和轉換 HTTP 和 Blob 端點的數據。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- John Hauppa |資深技術計劃經理
- Uffaz Nathaniel |首席軟體工程師
其他投稿人：
- Mick Alberts | 技術寫入員
- Dilmurod Makhamadaliev |軟體工程師
- 梅梅德·穆薩維 |首席軟體工程師主管
- Ayo Mustapha |主要技術計劃管理員
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。