共用方式為


選取目標 Azure 平台來裝載匯出的歷程資料

您在移轉程序期間所做的其中一個重要決策是決定儲存歷程記錄資料的位置。 若要做出此決策,您必須了解各種目標平台,並能進行比較。

本文會比較目標平台的效能、成本、可用性和額外的管理負荷。

注意

此表格中的考量僅適用於歷程記錄移轉,而不適用於其他案例,例如長期保留。

基本記錄/封存 Azure 資料總管 (ADX) Azure Blob 儲存體 ADX + Azure Blob 儲存體
能力 • 以較低成本套用大部分現有的 Azure 監視器記錄體驗。
• 基本記錄會保留八天,然後根據原始保留期間自動傳輸至封存。
• 使用搜尋作業在數 PB 的資料之間進行搜尋,並尋找特定事件。
• 如需針對特定時間範圍進行深入調查,請從封存還原資料。 資料接著會可以在經常性快取中取得,以便來做進一步分析。
• ADX 和 Microsoft Sentinel 都使用 Kusto 查詢語言 (KQL),這可讓您查詢、匯總這兩個平台中的資料,或使這些資料相互關聯。 例如,您可以從 Microsoft Sentinel 執行 KQL 查詢,以聯結 ADX 中儲存的資料與 Log Analytics 中儲存的資料
• 使用 ADX 時,您可以充分控制叢集大小和設定。 例如,您可以建立較大的叢集以達到較高的擷取輸送量,或建立較小的叢集來控制成本。
• Blob 儲存體經過最佳化,已能妥善儲存大量的非結構化資料。
• 提供競爭成本。
• 適用於貴組織未設定可及性或效能優先順序的案例,例如當組織必須符合合規性或稽核需求時。
• 資料會儲存在 Blob 儲存體中,其成本很低。
• 您可以使用 ADX 查詢 KQL 中的資料,這可讓您輕鬆存取資料。 了解如何使用 ADX 查詢 Azure 監視器資料
可用性 很棒

封存和搜尋選項都很容易使用,而且可從 Microsoft Sentinel 入口網站存取。 不過,資料無法立即用於查詢。 您必須執行搜尋來擷取資料,這可能需要一些時間,依所掃描和傳回的資料量而定。
很好

在 Microsoft Sentinel 的內容中相當容易使用。 例如,您可以使用 Azure 活頁簿將分散在 Microsoft Sentinel 和 ADX 之間的資料視覺化。 您也可以使用 ADX Proxy 從 Microsoft Sentinel 入口網站查詢 ADX 資料。


透過歷程記錄資料移轉,您可能必須處理數百萬個檔案,而這時探索資料就會成為挑戰。
普通

雖然在有大量 Blob 要參考的情況下,要使用 externaldata 運算子非常有挑戰性,但使用外部 ADX 資料表就可排除此問題。 外部資料表定義了解 Blob 儲存體資料夾結構,並可讓您以透明方式查詢包含在許多不同 Blob 和資料夾中的資料。
額外的管理負荷 完全受控

搜尋和封存選項完全受控,而且不會增加額外的管理負荷。


ADX 是在 Microsoft Sentinel 的外部,需要監視和維護。


雖然此平台只需要少量維護,但選取此平台會新增監視和設定工作,例如設定生命週期管理。


使用此選項,您就可以維護及監視 ADX 和 Azure Blob 儲存體,這兩者都是 Microsoft Sentinel 的外部元件。 雖然有時可以將 ADX 關閉,但請考慮使用此選項的額外管理負荷。
效能

您通常會使用搜尋作業來與封存內的基本記錄互動,這適用於您想要維護資料的存取權,但不需要立即存取資料的情況。
高到低

• ADX 叢集的查詢效能取決於叢集中的節點數目、叢集虛擬機器 SKU、資料分割等等。
• 當您將節點新增至叢集時,效便會改善,但同時成本也隨之增加。
• 如果您使用 ADX,建議您利用叢集大小的設定來平衡效能和成本。 此設定取決於您組織的需求,包括移轉完成的需要速度、存取資料的頻率,以及預期的回應時間。


提供兩個效能層級:進階或標準。 雖然這兩個層級都屬於長期儲存的選項,但標準層級更符點成本效益。 了解 效能和延展性限制


由於資料位於 Blob 儲存體中,因此效能受限於該平台。
成本

成本是由兩個元件所組成:
擷取成本。 每 GB 擷取到基本記錄的資料都會受限於 Microsoft Sentinel 和 Azure 監視器記錄擷取成本,其總和約為 1 美元/GB。 請參閱定價詳細資料
封存成本。 封存層中的資料成本總和約為每月 0.02 美元/GB。 請參閱定價詳細資料
除了這兩個成本元件之外,如果您需要經常存取資料,當您透過搜尋作業存取資料時,會產生額外的成本。
高到低

• 因為 ADX 是虛擬機器的叢集,因此會根據計算、儲存體和網路使用量向您收費,還要加上 ADX 調漲 (查看定價詳細資料。 因此,您新增至叢集的節點越多、儲存的資料越多,成本就越高。
• ADX 也提供自動調整功能,以便視需要適應工作負載。 ADX 也可以受益於保留執行個體定價。 您可以在 Azure 定價計算機中執行自己的成本計算。


在最佳設定之下,Azure Blob 儲存體的成本最低。 為了提升效率並節省成本,您可以使用 Azure 儲存體生命週期管理將較舊的 Blob 自動放入較便宜的儲存層。


ADX 在此案例中只能做為 Proxy,因此叢集可能很小。 此外,您在不需要存取資料時可以關閉叢集,並只在需要資料存取時才啟動。
如何存取資料 搜尋作業 直接 KQL 查詢 externaldata 修改過的 KQL 查詢
案例: 偶爾存取

與不需要執行大量分析或觸發分析規則的案例相關,而且您只需要偶爾存取資料。
經常存取

與您需要經常存取資料的案例相關,而且您需要控制叢集的大小和設定方式。
合規性/稽核

• 最適合用來儲存大量非結構化資料。
• 與不需要快速存取資料或高效能的案例相關,例如合規性或稽核用途。
偶爾存取

與您想要受益於低成本 Azure Blob 儲存體的案例相關,同時維持較快的資料存取速度。
複雜度 非常低
整備度 GA GA GA GA

一般考量

現在您已深入了解可用的目標平台,請檢閱下列主要因素以完成您的決策。

使用已擷取的記錄

定義組織如何使用已擷取的記錄來引導您選取擷取平台。

請考慮下列三個案例:

  • 您的組織必須保留記錄,而這只是為了合規性或稽核用途。 在此情況下,您的組織很少會存取資料。 即使您的組織存取資料,高效能或容易使用也並非優先考量。
  • 您的組織需要保留記錄,好讓您的小組能夠簡單快速地存取記錄。
  • 您的組織需要保留記錄,好讓您的小組能夠偶爾存取記錄。 效能和方便使用與否都是次要的。

請參閱平台比較,以便了解哪些平台符合這些案例。

移轉速度

在某些案例中,您可能會需要符合緊迫的期限,例如,您的組織可能因為授權到期事件而緊急從先前的 SIEM 移動。

檢閱決定移轉速度的元件和因素。

資料來源

資料來源通常是本機檔案系統或雲端儲存體,例如 S3。 伺服器的儲存體效能取決於多項因素,例如磁碟技術 (SSD 與 HDD)、IO 要求的本質,以及每個要求的大小。

例如,Azure 虛擬機器效能從每秒 30 MB (較小 VM SKU 上) 到每秒 20 GB (某些使用 NVM Express (NVMe) 磁碟的儲存體優化 SKU) 都有。 了解如何設計 Azure VM 以達到高儲存體效能。 您也可以將大部分的概念套用至內部部署伺服器。

計算能力

在某些情況下,即使您的磁碟有能力快速複製資料,計算能力仍會是複製程式的瓶頸。 在這些情況下,您可以選擇下列其中一個調整選項:

  • 垂直調整。 您可以藉由新增更多 CPU 來增加單一伺服器的能力,或增加 CPU 速度。
  • 水平調整。 您可以新增更多伺服器,這會增加複製程序的平行處理原則。

目標平台

本節所討論的每個目標平台都有不同的效能設定檔。

  • Azure 監視器基本記錄。 根據預設,基本記錄能以每分鐘約 1 GB 的速率推送至 Azure 監視器。 此速率可讓您每天擷取大約 1.5 TB 、每月 43 TB 的資料。
  • Azure 資料總管。 擷取效能會根據您佈建的叢集大小以及您套用的批次處理設定而有所不同。 了解擷取最佳做法,包括效能和監視。
  • Azure Blob 儲存體。 Azure Blob 儲存體帳戶的效能可能會因檔案的數目和大小、作業大小、並行等等的因素而有所不同。 了解如何將使用 Azure 儲存體將 AzCopy 的效能最佳化

資料量

資料量是影響移轉程序持續時間的主要因素。 因此,您應該考慮如何根據您的資料集來設定環境。

若要判斷移轉的最小持續時間以及瓶頸何在,請考量目標平台的資料量和擷取速度。 例如,您選取了可每秒擷取 1 GB 的目標平台,而您必須移轉 100 TB。 在此情況下,您的移轉時間至少需要 100,000 (GB 數) 乘以 1 (移轉速度) 秒。 將秒數除以 3600,結果為 27 小時。 如果管線中的其餘元件 (例如本機磁碟、網路和虛擬機器) 都能以每秒 1 GB 的速度執行,那麼此計算才會成立。

下一步

在本文中,您已了解如何將移轉規則從 QRadar 對應至 Microsoft Sentinel。