處理排程分析規則中的擷取延遲
雖然 Microsoft Sentinel 可以從各種來源擷取資料，但每個資料來源的擷取時間可能會不同。
本文說明擷取延遲可能會對排程分析規則造成什麼影響，以及如何修正這些規則以彌補這些差距。
為什麼延遲很重要
舉例來說，您可以撰寫自訂偵測規則，設定 [執行間隔時間] 和 [查閱過去時間內的資料] 欄位，讓規則每隔五分鐘執行一次、查閱過去五分鐘的資料：
[查閱過去時間內的資料] 欄位會定義稱為「回溯」期間的設定。 在沒有發生延遲的理想情況下，此偵測不會遺漏任何事件，如下圖所示：
事件會在產生時送達，並包含在「回溯」期間內。
現在，假設您的資料來源出現一些延遲。 在此範例中，假設事件在「產生」後「擷取」了兩分鐘。 延遲時間為兩分鐘：
事件會在第一次執行期間產生，但不會在第一次執行時擷取至 Microsoft Sentinel 工作區中。 下次執行排程查詢時，它會擷取該事件，但產生時間篩選條件會移除這個事件，因為發生時間已超過五分鐘前。 在此情況下，規則不會引發警示。
如何處理延遲
注意
您可以使用下面所述的流程解決問題，或實作 Microsoft Sentinel 的近乎即時偵測 (NRT) 規則。 如需詳細資訊，請參閱使用 Microsoft Sentinel 中的近即時 (NRT) 分析規則來快速偵測威脅。
若要解決此問題，您需知道資料類型的延遲時間。 在此範例中，您已經知道延遲時間是兩分鐘。
針對您自己的資料，您可以使用 Kusto ingestion_time() 函式了解延遲時間，並計算 TimeGenerated 與擷取時間之間的差異。 如需詳細資訊，請參閱計算擷取延遲。
判斷出延遲時間後，可以依照下列方式解決問題：
延長回溯期間。 基本直覺告訴您，延長回溯期間會有所幫助。 因為您的回溯期間是五分鐘，而您的延遲時間是兩分鐘，所以將回溯期間設定為七分鐘有助於解決此問題。 例如，在規則設定中：
下圖顯示回溯期間現在包含遺漏事件的方式：
處理重複項目。 只有延長回溯期間才可能建立重複項目，因為回溯時段現在會重疊。 例如，不同的事件看起來可能如下圖所示：
由於事件 TimeGenerated 值可在兩個回溯期間中找到，因此這個事件會引發兩個警示。 您需要尋找解決重複項目的方法。
將事件與特定回溯期間建立關聯。 在第一個範例中，排程查詢執行時未擷取您的資料，因此遺漏了事件。 您延長了回溯期間以包含事件，但這會導致重複項目產生。 您必須將事件與延長的時段建立關聯，以包含該事件。
需藉由設定
ingestion_time() > ago(5m)來執行此動作，而不是設定原始規則look-back = 5m。 此設定會將事件與第一個回溯時段建立關聯。 例如：
擷取時間限制現在會修剪掉您新增至回溯期間的額外兩分鐘。 在第一個範例中，第二次執行回溯期間時，現在會擷取事件：
下列範例查詢摘要說明解決擷取延遲問題的解決方案：
let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)
計算擷取延遲
根據預設，Microsoft Sentinel 排程警示規則會設定為具有 5 分鐘的回溯期間。 不過，每個資料來源可能都有各自的擷取延遲。 聯結多個資料類型時，您必須知道每個資料類型的不同延遲時間，才能正確設定回溯期間。
Microsoft Sentinel 提供現成的工作區使用量報告，包含儀表板，可顯示流入工作區中不同資料類型的延遲時間。
例如：
下一步
如需詳細資訊，請參閱