Azure 監視器中的記錄資料擷取時間

發行項
12/04/2024

Azure 監視器是一種大規模的資料服務，服務對象為每月需傳送數 TB 資料 (且不斷成長) 的上千名客戶。而在收集記錄資料後，資料需要多久時間方能轉為可用狀態，是經常受到詢問的問題。本文會說明影響這種延遲的不同因素。

平均延遲

延遲是指在受監視的系統中建立資料所需的時間，以及轉變為可在 Azure 監視器中進行分析的時間。擷取記錄資料的延遲平均介於 20 秒到 3 分鐘之間。任何特定資料的特定延遲，都會隨著本文說明的幾項因素而有所不同。

影響延遲的因素

特定資料集的擷取時間總計可以細分成下列高階領域：

代理程式時間：探索事件、收集事件，然後將其傳送至資料收集端點作為記錄檔記錄所需的時間。在大多數情況下，此流程是由代理程式處理。網路可能會帶來更多延遲。
管線時間：擷取管線處理記錄檔記錄所需的時間。這包括剖析事件的屬性，以及可能新增計算資訊的時間。
編製索引的時間：將記錄檔記錄擷取至 Azure 監視器巨量資料存放區所花費的時間。

以下幾節詳細說明在此程序中導入的不同延遲。

代理程式收集延遲

時間會有所不同

代理程式和管理解決方案使用不同的策略來收集虛擬機器的資料，這可能會影響延遲。下表列出一些特定範例。

資料類型	收集頻率	備註
Windows 事件、Syslog 事件和效能計量	立即收集
Linux 效能計數器	以 30 秒的間隔輪詢
IIS 記錄和文字記錄	在其時間戳記變更後收集	對於 IIS 記錄，此排程會受到在 IIS 上設定的變換排程影響。
Active Directory 複寫解決方案	每隔五天進行評量	只有在評估完成後，代理程式才會收集記錄。
Active Directory 評定解決方案	每週評估 Active Directory 基礎結構	只有在評估完成後，代理程式才會收集記錄。

代理程式上傳頻率

不到 1 分鐘

為確保 Log Analytics 代理程式是輕量的，代理程式會緩衝記錄，並定期將其上傳至 Azure 監視器。上傳頻率在 30 秒到 2 分鐘之間，視資料類型而定。大部分的資料會在 1 分鐘內上傳。

網路

不定

網路狀況可能會加劇此資料到達資料收集端點的延遲。

Azure 計量、資源記錄、活動記錄

30 秒至 20 分鐘

Azure 資料需要更長的時間才能在資料收集端點上進行處理：

Azure 平台計量可在一分鐘內從計量資料庫中取得，但要匯出至資料收集端點還另需 3 分鐘。
資源記錄通常會增加 30-90 秒，視 Azure 服務而定。某些 Azure 服務 (具體而言，是 Azure SQL Database 和 Azure 虛擬網路) 目前會以 5 分鐘間隔回報記錄。我們正積極設法進一步縮短該時間。若要檢查您環境中的這項延遲，請參閱下方的查詢。
活動記錄 可在 3 到 20 分鐘內進行分析和警示。

管理解決方案集合

不定

某些解決方案不會從代理程式收集其資料，而且可能使用會造成更多延遲的收集方法。某些解決方案會定期收集資料，而不嘗試近乎即時的收集。具體範例包括：

Microsoft 365 解決方案使用管理活動 API 來輪詢活動記錄，該 API 目前不提供任何近乎即時的延遲保證。
解決方案以每日頻率收集 Windows Analytics 解決方案 (例如，更新合規性) 資料。

若要確認解決方案的收集頻率，請參閱每個解決方案的文件。

管理處理程序時間

30 至 60 秒

資料在資料收集端點上可供使用後，還需要 30 到 60 秒才可用於查詢。

記錄檔記錄擷取至 Azure 監視器管線後 (如 _TimeReceived 屬性中所識別)，將會寫入暫存儲存體，以確保租用戶隔離，並確保資料不會遺失。此程序通常會增加 5 到 15 秒。

某些解決方案會實作更繁重的演算法以彙總資料，並在資料流入時產生深入解析。例如，Application Insights 會計算應用程式對應資料；Azure 網路效能監視會以 3 分鐘的間隔彙總傳入的資料，而著實增加了 3 分鐘的延遲。

如果資料收集包括擷取時間轉換，則這會將一些延遲新增至管線。使用計量 [每分鐘記錄轉換期間] 來監視轉換查詢的效率。

另一個會增加延遲的程序是處理自訂記錄的程序。在某些情況下，對於代理程式收集自檔案的記錄，此程序可能會增加數分鐘的延遲。

新的自訂資料類型佈建

從自訂記錄或資料收集器 API 建立新類型的自訂資料時，系統會建立專用的儲存體容器。這種一次性的額外負荷只會在第一次出現此資料類型時發生。

突波保護

通常少於 1 分鐘，但也可能更久

Azure 監視器的首要任務是確保不會遺失客戶資料，因此系統具有內建的資料突波保護。此一保護包括緩衝區，以確保即使在巨大的負載下，系統仍可保持正常運作。在正常負載下，這些控制增加的延遲不到一分鐘。在極端條件下和失敗時，為了確保資料安全可能會使延遲時間大幅增加。

建立索引的時間

5 分鐘或以下

每個巨量資料平台在提供分析和進階搜尋功能之間，會達到內建的平衡，而不是提供對資料的即時存取權。透過 Azure 監視器，您可對數百萬筆記錄執行強大的查詢，並在幾秒鐘內獲得結果。此效能有可能實現，因為基礎結構在擷取過程中會大幅轉換資料，並將其儲存在唯一的壓縮結構中。系統會緩衝資料，直到有足夠的資料可用於建立這些結構。必須先完成此程序，記錄檔記錄才會出現在搜尋結果中。

目前，當資料量較少，此程序大約需要 5 分鐘，但若資料速率較高，所需時間就較短。這種行為似乎違反直覺，但此程序能讓大量生產工作負載的延遲達到最佳化。

檢查擷取時間

對於不同的資源，在不同的情況下，擷取時間可能不盡相同。您可以使用記錄查詢來識別您環境的特定行為。下表指定如何在記錄建立並傳送至 Azure 監視器時判斷記錄的不同時間。

步驟	屬性或函式	註解
在資料來源建立的記錄	TimeGenerated	TimeGenerated 值在收到的時間之前不能超過兩天，或未來超過一天。否則，Azure 監視器記錄會將 TimeGenerated 值取代為實際的接收時間。如果數據源未設定此值，Azure 監視器記錄會將值設定為與_TimeReceived相同的時間。
資料收集端點所接收的記錄	_TimeReceived	此欄位未針對大量處理進行最佳化，因此不應該用來篩選大型資料集。
儲存在工作區中且可用於查詢的記錄	ingestion_time()	如果只需要篩選在特定時間範圍內擷取的記錄，建議使用 `ingestion_time()`。在這種情況下，我們也建議您新增範圍較大的 `TimeGenerated` 篩選。

擷取延遲

您可以比較 ingestion_time() 函式與 TimeGenerated 屬性的結果，以測量特定記錄的延遲。這項資料可用於各種彙總，以探索擷取延遲的具體表現。檢查擷取時間的某個百分位數，以取得大量資料的深入解析。

例如，下列查詢會顯示前 8 小時有最高擷取時間的電腦：

Heartbeat
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer 
| top 20 by percentile_E2EIngestionLatency_95 desc

上述百分位數檢查很適合用來尋找延遲的一般趨勢。如需識別延遲中的短期峰值，則使用最大值 (max()) 可能更有效率。

如果您想要向下切入到特定電腦經過一段時間的擷取時間，請使用也會將圖形中過去一天資料視覺化的下列查詢：

Heartbeat 
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"  
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60 
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60 
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m) 
| render timechart

使用下列查詢，可依據電腦 IP 位址所在的國家/地區，來顯示電腦擷取時間：

Heartbeat 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry

來自代理程式的不同資料類型可能有不同的擷取延遲時間，因此先前的查詢無法搭配其他類型使用。下列查詢可以用來檢查各種 Azure 服務的擷取時間：

AzureDiagnostics 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

使用相同的查詢邏輯，診斷 Application Insights 資料的延遲狀況：

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp  > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
AppRequests
| where TimeGenerated  > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

上述兩個查詢可以與「要求」以外的任何其他 Application Insights 資料表配對。

停止回應的資源

在某些情況下，資源將會停止傳送資料。若要了解資源是否正在傳送資料，請查看可由標準 TimeGenerated 欄位識別的最新記錄。

Heartbeat 資料表可用來檢查 VM 的可用性，因為代理程式活動訊號會每分鐘傳送一次。可用下列查詢列出最近尚未回報活動訊號的使用中電腦：

Heartbeat  
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer  
| top 20 by NoHeartbeatPeriod desc

下一步

請閱讀 Azure 監視器的服務等級協定。

共用方式為