正在加载

运行作业

Elastic Stack Serverless

异常检测作业包含执行机器学习分析所需的配置信息和元数据。它们可以针对特定时间段运行,也可以针对传入的数据连续运行。

在使用 Elastic Stack 机器学习功能之前,需要满足一些配置要求(例如安全权限)。请参阅设置和安全

注意

如果您的数据位于 Elasticsearch 之外,则无法使用 Kibana 创建作业,也无法使用数据馈送实时检索数据。将数据直接发布到异常检测作业已弃用,在将来的主要版本中,将需要数据馈送。

您可以使用创建异常检测作业 API 来创建异常检测作业。Kibana 还提供了向导来简化此过程,具体取决于您使用的是 Machine Learning 应用程序、Elastic Security 应用程序还是 Observability 应用程序。要打开异常检测,请在主菜单中找到 Machine Learning,或使用全局搜索字段

Create New Job
  • 单指标向导创建具有单个探测器的简单作业。探测器 将分析函数应用于数据中的特定字段。除了限制探测器的数量外,单指标向导还省略了许多更高级的配置选项。
  • 多指标向导创建可以有多个探测器的作业,这比对同一数据运行多个作业更有效。
  • 人口向导创建用于检测与人口行为相比不寻常的活动的作业。
  • 分类向导创建将日志消息分组到类别中并使用 countrare 函数来检测其中的异常的作业。
  • 高级向导创建可以有多个探测器的作业,并允许您配置所有作业设置。

Kibana 还可以识别某些类型的数据,并为该上下文提供专用向导。例如,有用于示例电子商务订单和示例 Web 日志数据集的异常检测作业,以及用于 Elastic Security 和 Observability 解决方案、Beats 和 Elastic Agent Integrations 生成的数据的异常检测作业。有关所有预配置作业的列表,请参阅提供的配置

当您在 Kibana 中创建异常检测作业时,作业创建向导可以根据您的数据特征提供建议。通过听取这些建议,您可以创建更有可能产生有见地的机器学习结果的作业。此处涵盖了最重要的概念;有关所有作业属性的说明,请参阅创建异常检测作业 API

机器学习功能使用存储桶的概念将时间序列划分为批次进行处理。

存储桶跨度是异常检测作业的配置信息的一部分。它定义了用于汇总和建模数据的时间间隔。这通常在 5 分钟到 1 小时之间,具体取决于您的数据特征。设置存储桶跨度时,请考虑要分析的粒度、输入数据的频率、异常的典型持续时间以及需要发出警报的频率。

存储桶跨度必须包含有效的时间间隔。在 Kibana 中创建异常检测作业时,您可以选择根据您的数据特征估算存储桶跨度值。如果您选择的值大于一天或与估计值明显不同,您将收到一条信息性消息。

每个异常检测作业必须有一个或多个探测器。探测器定义了将发生的分析类型以及要分析的字段。

探测器还可以包含影响哪些类型的实体或事件被认为是异常的属性。例如,您可以指定是相对于实体自己的先前行为还是相对于总体中的其他实体来分析实体。还有多个选项可以将数据拆分为类别和分区。

如果您的作业不包含探测器或探测器不包含有效函数,您将收到错误。如果作业包含重复的探测器,您也会收到错误。如果探测器具有相同的 functionfield_nameby_field_nameover_field_namepartition_field_name,则这些探测器是重复的。

当发生异常事件时,我们想知道原因。但是,要确定原因,您通常需要更广泛的领域知识。如果您怀疑数据集中的哪些实体可能导致异常,您可以在异常检测作业中将它们标识为影响因素。也就是说,影响因素是您怀疑包含有关影响或促成数据中异常的某人或某事物的信息的字段。影响因素可以是数据中的任何字段。

您可以使用高级作业向导在创建异常检测作业时选择影响因素。

强烈建议选择影响因素,原因如下

  • 它使您更容易为异常分配责任。
  • 它简化并聚合了结果。

如果您使用 Kibana,作业创建向导可以建议将哪些字段用作影响因素。最佳影响因素是您想要为异常负责的人或事物。在许多情况下,分类数据字段(如用户或客户端 IP 地址)是极好的影响因素。

Kibana 中的 异常浏览器 列出了作业的顶级影响因素,并显示了每个异常的最有影响力的值。它还使您能够按给定的影响因素过滤数据。

提示

不要选择过多的影响因素。例如,通常您不需要超过三个。如果您选择过多的影响因素,结果可能会让人不知所措,并且分析会产生少量的开销。

有关影响因素的更多详细信息,请参阅此博文

如果您的数据中存在相关实体的逻辑分组,机器学习分析可以创建数据模型并生成考虑这些分组的结果。例如,您可以选择按用户 ID 拆分数据,并检测用户访问资源的方式与他们通常的方式有何不同。

如果您用于拆分数据的字段具有许多不同的值,则作业会使用更多的内存资源。在 Kibana 中,如果 by_field_nameover_field_namepartition_field_name 的基数大于 1000,则作业创建向导会建议可能存在较高的内存使用率。同样,如果您正在执行人口分析,并且 over_field_name 的基数低于 10,则会建议您这可能不是一个合适的字段。

对于每个异常检测作业,您可以选择指定一个 model_memory_limit,这是分析处理所需的最大内存资源的大概数量。默认值为 1 GB。一旦接近此限制,数据修剪就会变得更加激进。一旦超过此限制,就不会对新实体进行建模。

您还可以选择指定 xpack.ml.max_model_memory_limit 设置。默认情况下,它未设置,这意味着对作业中可接受的 model_memory_limit 值没有上限。

提示

如果您将 model_memory_limit 设置得过高,则无法打开作业;作业无法分配给没有足够内存来运行它们的节点。

如果异常检测作业的估计模型内存限制大于作业的模型内存限制或集群的最大模型内存限制,Kibana 中的作业创建向导会生成警告。如果估计的内存需求仅略高于 model_memory_limit,则该作业可能会产生有用的结果。否则,您为解决这些警告而采取的操作会因集群中可用的资源而异。

  • 如果您使用的是 model_memory_limit 的默认值,并且集群中的机器学习节点具有大量内存,那么最佳做法可能是简单地增加作业的 model_memory_limit。但是,在执行此操作之前,请仔细检查所选的分析是否有意义。默认的 model_memory_limit 相对较低,以避免意外创建使用大量内存的作业。
  • 如果集群中的机器学习节点没有足够的内存来容纳估计大小的作业,则唯一的选择是
    • 向集群添加更大的机器学习节点,或者
    • 接受该作业将达到其内存限制,并且不一定能找到所有它可能找到的异常。

如果您使用的是 Elastic Cloud Enterprise 或 Elastic Cloud Hosted,则会设置 xpack.ml.max_model_memory_limit,以防止您创建无法分配给集群中任何机器学习节点的作业。如果您发现无法增加机器学习作业的 model_memory_limit,解决方案是增加集群中机器学习节点的大小。

对于每个异常检测作业,您可以选择指定一个专用索引来存储异常检测结果。 由于异常检测作业可能会产生大量结果(例如,具有许多时间序列、小 bucket span 或运行时间长的作业),建议使用专用结果索引,方法是在 Kibana 中选择“使用专用索引”选项,或者通过 创建异常检测作业 API 指定 results_index_name

如果您在 Kibana 中创建异常检测作业,您必须使用 datafeeds 从 Elasticsearch 检索数据以进行分析。 当您创建异常检测作业时,您选择一个数据视图,Kibana 会在后台为您配置 datafeed。

您只能将一个 datafeed 与每个异常检测作业相关联。 datafeed 包含一个以定义的间隔 (frequency) 运行的查询。 默认情况下,此间隔是相对于异常检测作业的 bucket span 计算的。如果您担心延迟数据,可以在每次间隔运行查询之前添加延迟。 请参阅 处理延迟数据

Datafeeds 也可以在将数据发送到异常检测作业之前聚合数据。 但是,存在一些限制,并且聚合通常只应用于低基数数据。 请参阅 聚合数据以获得更快的性能

重要提示

启用 Elasticsearch 安全功能后,datafeed 会存储创建或更新 datafeed 的用户的角色。 这意味着如果这些角色被更新,datafeed 随后会以与这些角色关联的新权限运行。 但是,如果在创建或更新 datafeed 后调整了用户的角色,则 datafeed 将继续以与原始角色关联的权限运行。

更新 datafeed 中存储的角色的一种方法是在不更改任何其他设置的情况下,将一个空的 JSON 文档 ({}) 提交到 更新 datafeed API

在 7.11.0 中已弃用

如果您要分析的数据未存储在 Elasticsearch 中,则无法使用 datafeeds。 但是,您可以使用 将数据发布到作业 API 将批量数据直接发送到作业。

必须打开异常检测作业,它才能准备好接收和分析数据。 在其整个生命周期中,它可以多次打开和关闭。

启动作业后,您可以启动 datafeed,它从您的集群中检索数据。 datafeed 在其整个生命周期中可以多次启动和停止。 当您启动它时,您可以选择指定开始时间和结束时间。 如果您不指定结束时间,datafeed 将持续运行。

您可以在 Kibana 中执行这两项任务,也可以使用 打开异常检测作业启动 datafeeds API。

通常,在打开作业后,下一步是 查看结果。 您可能会发现您需要更改作业配置或设置。

有时,您希望发生不寻常的活动,例如银行假日、“黑色星期五”或计划内的系统中断。 如果您提前识别出这些事件,则在该期间内不会生成任何异常。 机器学习模型不会受到不良影响,您也不会收到虚假结果。

您可以在 Kibana 中 Machine Learning 页面上的 设置 窗格中或使用 机器学习异常检测 API 创建日历和计划事件。

计划事件必须具有开始时间、结束时间和描述。 通常,计划事件的持续时间很短(通常持续几个小时到一天),并且很少发生。 如果您有定期发生的事件,例如每周维护期间,则无需为此类情况创建计划事件; 机器学习分析已经处理了它们。

您可以在日历中识别零个或多个计划事件。 异常检测作业随后可以订阅日历,并且机器学习分析会适当地处理所有后续计划事件。

如果您想一次添加多个计划事件,您可以在 Kibana 中导入 iCalendar (.ics) 文件,或在 向日历添加事件 API 中导入 JSON 文件。

注意
  • 您必须在异常检测作业分析该时间段的数据之前识别出计划事件。 机器学习结果不会追溯更新。
  • 如果您的 iCalendar 文件包含重复事件,则只会导入第一个事件。
  • Bucket 结果 在计划事件期间生成,但它们的异常得分为零。
  • 如果您使用长时间或频繁的计划事件,机器学习分析可能需要更长的时间来学习建模您的数据,并且可能会错过一些异常行为。

默认情况下,异常检测是无监督的,并且机器学习模型不知道您数据的域。 因此,当您了解更大的上下文时,异常检测作业可能会识别出在统计上重要但不有趣的事件。 机器学习自定义规则使您可以自定义异常检测。

自定义规则 – 或者 Kibana 称之为作业规则 – 指示异常检测器根据您提供的特定于域的知识来更改其行为。 创建规则时,您可以指定条件、范围和操作。 当满足规则的条件时,将触发其操作。

例如,如果您有一个分析 CPU 使用率的异常检测器,您可能决定只对 CPU 使用率大于某个阈值的异常感兴趣。 您可以定义具有条件和操作的规则,指示检测器在发生与低 CPU 使用率相关的异常事件时,不要生成机器学习结果。 您可能还会决定为该规则添加一个范围,使其仅适用于某些机器。 范围通过使用机器学习过滤器来定义。

过滤器 包含一个值列表,您可以使用这些值来包含或排除机器学习分析中的事件。 您可以在多个异常检测作业中使用相同的过滤器。

如果您正在分析 Web 流量,您可能会创建一个包含 IP 地址列表的过滤器。 例如,也许它们是您信任的将数据上传到您的网站或从防火墙后面发送大量数据的 IP 地址。 您可以定义规则的范围,使其仅在数据中的特定字段与过滤器中的某个值匹配时触发。 或者,您可以使其仅在字段值与任何过滤器值不匹配时触发。 因此,您可以更好地控制哪些异常事件会影响机器学习模型并出现在机器学习结果中。

有关更多信息,请参阅 使用自定义规则自定义检测器

Elastic Stack 机器学习功能计算正常行为的基线,然后推断异常事件。 这些基线是通过生成数据模型来实现的。

为确保在发生系统故障时具有弹性,每个异常检测作业的机器学习模型快照会保存到 Elasticsearch 集群中的内部索引。 保存这些快照所需的时间与模型在内存中的大小成正比。 默认情况下,快照大约每 3 到 4 小时捕获一次。 您可以在创建或更新作业时更改此间隔 (background_persist_interval)。

为了减少快照占用集群空间,每天结束时,旧的快照会自动删除。每个快照的年龄是相对于最新快照的时间戳计算的。默认情况下,如果存在早于最新快照一天以上的快照,则除了每天的第一个快照之外,所有这些快照都会被删除。此外,早于最新快照十天以上的所有快照也会被删除。您可以在创建或更新作业时更改这些保留设置(daily_model_snapshot_retention_after_daysmodel_snapshot_retention_days)。如果您想将特定快照从清理中排除,请使用 Kibana 或 更新模型快照 APIretain 设置为 true

您可以使用 获取模型快照 API 或在 Kibana 的作业管理页面上的 模型快照 选项卡中查看每个作业的模型快照列表。

Example screenshot with a list of model snapshots
提示

除了系统故障之外,在某些情况下,您可能希望 恢复 到使用特定的模型快照。机器学习功能对异常输入和数据中的新行为反应迅速。高度异常的输入会增加模型的方差,机器学习分析必须确定这是一种新的行为阶跃变化,还是一个一次性事件。如果您知道这种异常输入是一次性的,则可能适合将模型状态重置到该事件之前的时间点。例如,在黑色星期五促销日之后,您可以考虑恢复到已保存的快照。但是,如果您提前知道此类事件,则可以使用 日历和计划事件 来避免影响您的模型。

当分析历史数据时,无需停止数据源和/或关闭作业,因为当到达结束时间时,它们会自动停止和关闭。

如果您需要停止异常检测作业,有序关闭可确保

  • 数据源已停止
  • 缓冲区已刷新
  • 模型历史记录已修剪
  • 最终结果已计算
  • 模型快照已保存
  • 异常检测作业已关闭

此过程确保作业处于一致状态,以便您随后可以重新打开它们。

当您停止数据源时,它会停止从 Elasticsearch 检索数据。您可以使用 Kibana 或 停止数据源 API 停止数据源。例如,以下请求停止 feed1 数据源

 POST _ml/datafeeds/feed1/_stop 
注意

您必须拥有 manage_mlmanage 集群权限才能停止数据源。有关更多信息,请参见 安全权限

数据源可以在其生命周期中多次启动和停止。

如果您正在升级集群,可以使用以下请求停止所有数据源

 POST _ml/datafeeds/_all/_stop 

当您关闭异常检测作业时,它无法接收数据或执行分析操作。您可以使用 关闭异常检测作业 API 关闭作业。例如,以下请求关闭 job1 作业

 POST _ml/anomaly_detectors/job1/_close 
注意

您必须拥有 manage_mlmanage 集群权限才能停止异常检测作业。有关更多信息,请参见 安全权限

如果您提交关闭异常检测作业的请求,并且其数据源正在运行,则该请求首先尝试停止数据源。此行为等效于使用与关闭作业请求相同的 timeoutforce 参数调用 停止数据源 API

异常检测作业可以在其生命周期中多次打开和关闭。

如果您正在升级集群,可以使用以下请求关闭集群上所有打开的异常检测作业

 POST _ml/anomaly_detectors/_all/_close 
© . All rights reserved.