监控和排除规则执行问题
编辑监控和排除规则执行问题编辑
有几种工具可以帮助您深入了解检测规则的性能
请参阅下面的排除缺少警报的问题部分，以获取在规则未创建预期警报时调整规则的策略。
“规则监控”选项卡编辑
要查看所有规则执行的摘要，包括最近的失败和执行时间，请选择“规则”页面上的“规则监控”选项卡（“规则” → “检测规则 (SIEM)” → “规则监控”）。
在“规则监控”选项卡上，您可以像在“已安装的规则”选项卡上一样对规则进行排序和过滤。
要对规则列表进行排序，请单击任何列标题。要按降序排序，请再次单击列标题。
有关规则、其生成的警报和相关错误的详细信息，请在表中单击其名称。这还允许您执行“已安装的规则”选项卡上可用的相同操作，例如修改或删除规则、激活或停用规则、导出或导入规则以及复制预构建规则。
执行结果编辑
每次检测规则执行都会被记录，包括其成功或失败、任何警告或错误消息，以及它搜索数据、创建警报和完成所需的时间。这可以帮助您对未按预期运行的特定规则进行故障排除（例如，如果它未创建警报或运行时间过长）。
要访问规则的执行日志，请转到“规则” → “检测规则 (SIEM)”，单击规则的名称以打开其详细信息，然后向下滚动并选择“执行结果”选项卡。您可以通过单击一行末尾的箭头来展开长警告或错误消息。
您可以将鼠标悬停在每个列标题上以显示有关该列数据的工具提示。单击列标题以按该列对表格进行排序。
使用这些控件可以过滤日志表中包含的内容
-
“状态”下拉列表按规则执行状态过滤表格
- “成功”：规则已完成其定义的搜索。这并不一定意味着它生成了警报，只是它在没有错误的情况下运行。
- “失败”：规则遇到错误，阻止其运行。例如，机器学习规则，其对应的机器学习作业未运行。
- “警告”：没有任何东西阻止规则运行，但它可能返回了意外结果。例如，自定义查询规则尝试搜索在 Elasticsearch 中找不到的索引模式。
- 日期和时间选择器设置表格中包含的规则执行的时间范围。这与规则详细信息页面顶部的全局日期和时间选择器分开。
- “显示指标列”切换在表格中包含更多或更少的数据，这些数据与每次规则执行的时间有关。
- “操作”列允许您显示从给定规则执行生成的警报。单击过滤器图标（
）以根据规则执行的 ID 值创建全局搜索过滤器。这将替换任何先前应用的过滤器，将全局日期和时间范围更改为规则执行前后 24 小时，并显示确认通知。您可以通过单击通知中的“恢复以前的过滤器”来恢复此操作。
排除缺少警报的问题编辑
当规则未能在其计划时间附近运行时，可能会缺少一些警报。有多种方法可以尝试解决此问题
您还可以使用 Kibana 中的任务管理器来排除可能与缺少警报相关的后台任务和进程
排除最大警报数警告问题编辑
当规则在单个规则执行期间达到其可以生成的最大警报数时，规则的详细信息页面和规则执行日志中将显示以下警告：此规则已达到规则执行的最大警报限制。某些警报未创建。
如果您收到此警告，请转到规则的“警报”选项卡并检查是否有任何异常情况。意外警报可能是由数据源问题或范围过大的查询创建的。为了进一步减少警报量，您还可以添加规则例外或抑制警报。
排除间隔问题编辑
如果您在“规则监控”表格或少量规则的“规则详细信息”页面上的“间隔”列中看到值，则可以增加这些规则的“额外回溯时间”（“规则” → “检测规则 (SIEM)” → 规则的“所有操作”菜单（…）→ “编辑规则设置” → “计划” → “额外回溯时间”）。
建议将额外回溯时间设置为至少 1 分钟。这可确保在规则未在其计划时间完全运行时不会缺少任何警报。
Elastic 安全可防止重复。在额外回溯时间内发现的任何重复警报都不会被创建。
如果遇到间隔问题的规则是指标匹配规则，请参阅如何调整指标匹配规则。另请注意，Elastic 安全对指标匹配规则的支持有限。
如果您在众多规则中看到间隔
- 如果您在激活了许多规则时重新启动了 Kibana，请尝试停用它们，然后以交错的间隔分批重新激活它们。这可确保 Kibana 不会尝试同时运行所有规则。
- 考虑向您的环境中添加另一个 Kibana 实例。
排除摄取管道延迟问题编辑
即使您的规则在其计划时间运行，如果您的摄取管道延迟大于您的规则间隔 + 额外回溯时间，则仍可能缺少警报。在 Elastic Stack 版本 >=7.11.0 中，预构建规则的最小间隔 + 额外回溯时间为 6 分钟。为了避免因预构建规则而错过警报，请务必谨慎操作，以确保摄取管道延迟保持在 6 分钟以下。
此外，在创建自定义规则计划时要谨慎，以确保指定的间隔 + 额外回溯时间大于部署的摄取管道延迟。
您可以通过在规则创建或编辑期间在高级设置中将时间戳覆盖字段值指定为event.ingested 来减少因摄取管道延迟而错过的警报数量。检测引擎在执行规则时使用event.ingested字段中的值作为时间戳。
例如，假设事件发生在 10:00，但由于摄取管道延迟，直到 10:10 才被摄取到 Elasticsearch 中。如果您创建了一个规则来检测该事件，其间隔 + 额外回溯时间为 6 分钟，并且该规则在 10:12 执行，则它仍然会检测到该事件，因为event.ingested时间戳来自 10:10，仅比规则执行时间早 2 分钟，并且完全在规则的 6 分钟间隔 + 额外回溯时间内。
排除机器学习作业缺少警报的问题编辑
机器学习检测规则使用机器学习作业，这些作业依赖于 Beats 和 Elastic Agent 集成填充的数据字段。在 Elastic Stack 版本 8.3 中，发布了新的机器学习作业（以v3为前缀）以对当时可用的 ECS 字段进行操作。
如果您将 8.2 或更早版本的 Beats 或 Elastic Agent 与 Elastic Stack 版本 8.3 或更高版本一起使用，则可能需要在更新 Elastic 预构建规则之前复制预构建规则或创建新的自定义规则。更新预构建规则后，它们将仅使用v3机器学习作业。在更新之前复制相关的预构建规则可以通过允许您继续使用v1或v2作业（在重复的规则中）以及运行新的v3作业（在更新的预构建规则中）来确保持续的覆盖范围。
- 重复的规则可能会导致重复的异常检测和警报。
- 在更新 Elastic 预构建规则之前，请确保相关的
v3机器学习作业正在运行。
- 如果您只有8.3 或更高版本的 Beats 和 Elastic Agent：您可以下载或更新您的预构建规则并使用最新的
v3机器学习作业。无需采取其他操作。 - 如果您只有 8.2 或更早版本的 Beats 或 Elastic Agent，或者 新旧版本混合使用：要继续使用 8.3 之前版本预构建检测规则指定的
v1和v2机器学习作业，您必须在将受影响的预构建规则更新到最新规则版本*之前*复制它们。 复制的规则可以继续使用相同的v1和v2机器学习作业，而更新后的预构建机器学习规则将使用新的v3机器学习作业。 - 如果您有 非 Elastic 数据传送器，用于收集与 ECS 兼容的事件：您可以使用最新的
v3机器学习作业，无需执行任何其他操作，只要您的数据传送器使用最新的 ECS 规范即可。 但是，如果您要从使用v1/v2作业的机器学习规则进行迁移，请确保在更新 Elastic 预构建规则之前启动相关的v3作业。
以下 Elastic 预构建规则使用新的 v3 机器学习作业来生成警报。 如果您需要 v1/v2 机器学习作业提供持续的覆盖范围，请在更新之前复制其关联的 v1/v2 预构建规则
-
异常的 Linux 网络端口活动：
v3_linux_anomalous_network_port_activity -
Linux 群体中的异常进程：
v3_linux_anomalous_process_all_hosts -
异常的 Linux 用户名：
v3_linux_anomalous_user_name -
调用元数据服务的异常 Linux 进程：
v3_linux_rare_metadata_process -
调用元数据服务的异常 Linux 用户：
v3_linux_rare_metadata_user -
Linux 主机上的异常进程：
v3_rare_process_by_host_linux -
Windows 主机上的异常进程：
v3_rare_process_by_host_windows -
异常的 Windows 网络活动：
v3_windows_anomalous_network_activity -
异常的 Windows 路径活动：
v3_windows_anomalous_path_activity -
异常的 Windows 进程创建：
v3_windows_anomalous_process_creation -
Windows 群体中的异常进程：
v3_windows_anomalous_process_all_hosts -
异常的 Windows 用户名：
v3_windows_anomalous_user_name -
调用元数据服务的异常 Windows 进程：
v3_windows_rare_metadata_process -
调用元数据服务的异常 Windows 用户：
v3_windows_rare_metadata_user