你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
处理计划分析规则中的引入延迟
虽然 Microsoft Sentinel 可以从各种源引入数据，但每个数据源的引入时间在不同情况下可能有所不同。
本文介绍了引入延迟可能会如何影响计划分析规则，以及如何修复这些规则以弥补这些缺陷。
为什么延迟非常重要
例如，你可以编写自定义检测规则，将“运行查询的频率”和“所查找数据的时段”字段设置为每 5 分钟运行一次规则，查找过去 5 分钟的数据 ：
“所查找数据的时段”字段定义了一个称为回溯期的设置。 理想情况下，如果没有延迟，此检测不会遗漏任何事件，如下图所示：
事件在生成后到达，并包含在回溯期中。
现在，假定数据源有一些延迟。 在此示例中，假设事件在生成 2 分钟后被引入 。 延迟为 2 分钟：
该事件在第一个回溯期内生成，但在第一次运行时不会引入 Microsoft Sentinel 工作区。 下次运行计划查询时，会引入该事件，但生成时间筛选器会删除该事件，因为其生成时间已超过 5 分钟。 在这种情况下，规则不会触发警报。
如何处理延迟
注意
可以使用下面所述的过程解决此问题，或者实现 Microsoft Sentinel 的近实时检测 (NRT) 规则。 有关详细信息，请参阅使用 Microsoft Sentinel 中的近实时 (NRT) 分析规则快速检测威胁。
若要解决此问题，需要了解数据类型的延迟。 在此示例中，已知道延迟为 2 分钟。
对于自己的数据，可以使用 Kusto ingestion_time() 函数了解延迟，并计算 TimeGenerated 与引入时间之间的差异。 有关详细信息，请参阅计算引入延迟。
确定延迟后，可以按如下方式解决问题：
增长回溯期。 基本直觉告诉你，增长回溯期将会有所帮助。 由于回溯期为 5 分钟，而延迟为 2 分钟，因此将回溯期设置为 7 分钟将有助于解决此问题。 例如，在规则设置中：
下图显示了回溯期现在包含丢失的事件的方式：
处理重复项。 只有增长回溯期才会造成重复，因为回溯期现在重叠了。 例如，另一个事件可能如下图所示：
由于在两个回溯期内都找到了事件 TimeGenerated 值，因此该事件会触发两个警报。 需要寻找一种方法来解决重复项。
将事件与特定的回溯期相关联。 在第一个示例中，你丢失了事件，因为计划查询运行时没有引入你的数据。 你扩展了回溯期以包含该事件，但这会导致重复。 必须将事件与扩展的时段相关联，以包含该事件。
为此，请设置
ingestion_time() > ago(5m)，而不是设置原始规则look-back = 5m。 此设置将事件与第一个回溯时段相关联。 例如：
引入时间限制现在可将添加到回溯期的额外 2 分钟剪裁掉。 现在，对于第一个示例，第二次运行回溯期将可以捕获事件：
以下示例查询汇总了解决引入延迟问题的解决方案：
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 中提供现成的工作区使用情况报表，其中包含一个仪表板，用于显示流入工作区的不同数据类型的延迟。
例如：
后续步骤
有关详细信息，请参阅：