大规模使用异常检测
编辑大规模使用异常检测
编辑异常检测作业有许多高级配置选项,其中一些选项会显著影响性能或资源使用情况。本指南包含一系列注意事项,可帮助您规划大规模使用异常检测。
在本指南中,您将学习如何
- 了解配置选项对异常检测作业性能的影响
先决条件
- 本指南假设您已经熟悉如何创建异常检测作业。如果不是,请参阅异常检测。
以下建议并非按顺序排列 - 数字仅有助于在列表项之间导航;您可以按任何顺序对其中一个或多个项采取操作。您可以在现有作业上实现其中一些更改;其他更改需要您克隆现有作业或创建新作业。
1. 考虑自动扩展、节点大小调整和配置
编辑异常检测作业在单个节点上运行,并且需要足够的资源才能将其模型保存在内存中。打开作业时,它将被放置在当时具有最多可用内存的节点上。
机器学习原生进程可用的内存大致可以认为是机器总 RAM 减去操作系统、Elasticsearch 以及在同一机器上运行的任何其他软件所需的内存。
节点上用于机器学习的可用内存必须足以容纳最大模型的大小。所有机器学习节点上的总可用内存必须足以容纳所有同时打开的作业的内存需求。
在 Elastic Cloud 中,专用机器学习节点在配置时,大部分 RAM 都会自动提供给机器学习原生进程。如果部署自管理型,那么我们建议部署专用机器学习节点并将 xpack.ml.max_machine_memory_percent
的值从默认的 30% 增加。默认值 30% 必须设置得较低,以防其他软件在同一机器上运行,并为也是数据节点的机器学习节点上的 OS 文件系统缓存保留可用内存。如果您使用建议的专用机器学习节点,并且不在其上运行任何其他软件,那么在具有至少 24GB RAM 的机器上,使用 2GB JVM 堆并将 xpack.ml.max_machine_memory_percent
设置为 90% 是合理的。这将最大限度地提高可以运行的机器学习作业数量。
增加节点数量将允许分配作业处理并提高容错能力。如果运行许多作业,即使是小内存作业,也请考虑增加环境中的节点数量。
在 Elastic Cloud 中,您可以启用 自动扩展,以便集群中的机器学习节点根据当前的机器学习内存和 CPU 需求进行向上或向下扩展。Elastic Cloud 基础设施允许您创建机器学习作业,其大小最大可达到集群可以扩展到的最大节点大小(通常在 58GB 到 64GB 之间),而不是当前集群可以容纳的大小。如果您尝试在 Elastic Cloud 之外使用自动扩展,则设置 xpack.ml.max_ml_node_size
以定义机器学习节点的最大可能大小。不允许创建模型内存限制大于最大节点大小的机器学习作业,因为自动扩展无法添加足够大的节点来运行该作业。在自管理部署中,您可以根据机器学习节点的可用资源设置 xpack.ml.max_model_memory_limit
。这可以防止您创建模型内存限制太高而无法在集群中打开的作业。
2. 使用专用结果索引
编辑对于大型作业,请使用专用结果索引。这可确保来自单个大型作业的结果不会主导共享结果索引。它还可以确保可以更有效地删除作业和结果(如果设置了 results_retention_days
),并提高重新规范化性能。默认情况下,异常检测作业结果存储在共享索引中。要更改为使用专用结果索引,您需要克隆或创建新作业。
3. 禁用模型图
编辑默认情况下,在 Kibana 中创建作业时会启用模型图。但是,如果您有大型作业,请考虑禁用它。您可以使用更新异常检测作业 API禁用现有作业的模型图。
模型图计算并存储每个已分析实体的模型边界,包括异常实体和非异常实体。这些边界用于在“单指标查看器”图表中显示阴影区域。模型图为每个存储桶的每个拆分字段值创建一个结果文档。如果您有高基数字段和/或短存储桶跨度,禁用模型图可以减少处理工作负载和存储的结果。
4. 了解检测器配置如何影响模型内存
编辑以下因素对增加作业所需的内存影响最大
by
或partition
字段的高基数- 多个检测器
- 存储桶内影响因素的高不同计数
通过仅选择相关的“影响因素”字段和检测器来优化您的异常检测作业。
如果您有高基数 by
或 partition
字段,请确保您有足够的可用内存资源来运行作业。或者,考虑是否可以使用数据源查询将作业拆分为较小的作业。对于非常高的基数,使用人口分析可能更合适。
要更改分区字段、影响因素和/或检测器,您需要克隆或创建新作业。
5. 优化存储桶跨度
编辑短存储桶跨度和高基数检测器是资源密集型的,需要更多的系统资源。
存储桶跨度通常介于 15 分钟和 1 小时之间。推荐值始终取决于数据、用例和警报所需的延迟。具有较长存储桶跨度的作业使用较少的资源,因为需要处理的存储桶更少,并且写入的结果也更少。每小时或每天的合理分隔符的存储桶跨度效果最佳,因为大多数周期性模式都有一个每日周期。
如果您的用例适合,请考虑增加存储桶跨度以减少处理工作负载。要更改存储桶跨度,您需要克隆或创建新作业。
6. 设置数据源的 scroll_size
编辑此注意事项仅适用于不使用聚合的数据源。数据源的 scroll_size
参数指定从 Elasticsearch 搜索返回的匹配数。scroll_size
越高,单次搜索返回的结果就越多。当您的异常检测作业具有高吞吐量时,增加 scroll_size
可能会缩短作业分析传入数据所需的时间,但也可能会增加集群的压力。您不能将 scroll_size
增加到大于 index.max_result_window
的值,默认值为 10,000。如果您更新数据源的设置,则必须停止并启动数据源才能应用更改。
7. 设置模型内存限制
编辑model_memory_limit
作业配置选项设置分析处理所需的大致最大内存资源量。当您在 Kibana 中创建异常检测作业时,它会为此限制提供一个估计值。该估计值基于作业的分析配置详细信息和基数估计值,这些估计值是通过在特定时间点对源索引运行聚合得出的。
如果您更改机器学习节点上可用的资源或对数据的特征或基数进行重大更改,则模型内存需求也可能会发生变化。您可以在作业关闭时更新作业的模型内存限制。但是,如果要将限制降低到当前模型内存使用量以下,则必须克隆并重新运行该作业。
您可以使用获取异常检测作业统计信息和获取模型快照 API 查看当前模型大小统计信息。您还可以通过运行估计异常检测作业模型内存 API随时获得模型内存限制估计值。但是,您必须提供自己的基数估计值。
当作业接近其模型内存限制时,内存状态为 soft_limit
,并且会更积极地修剪较旧的模型以释放空间。如果您有分类作业,则不会存储更多示例。当作业超出其限制时,内存状态为 hard_limit
,并且该作业不再为新实体建模。因此,为每个作业设置适当的内存模型限制非常重要。如果您达到硬限制并且担心缺少数据,请确保您有足够的资源,然后克隆并重新运行该作业,并增加模型内存限制。
8. 预聚合您的数据
编辑您可以通过使用聚合来汇总数据以加快分析速度。
异常检测作业使用为每个存储桶计算的汇总统计信息。统计信息可以在作业本身中计算,也可以通过聚合计算。尽可能使用聚合更有效,因为在这种情况下,数据节点会执行繁重的工作,而不是机器学习节点。
当您的数据源使用聚合时,您可能需要使用 chunking_config
来调整您的搜索速度。在这些情况下,将 chunking_config.mode
设置为 manual
并尝试 time_span
值。增加它可以加快搜索速度。但是,分块 time_span
越高,搜索响应中包含的存储桶数就越高。因此,如果您达到 search.max_buckets
限制,请减小 time_span
以减少每个响应的存储桶数。
在某些情况下,您无法进行聚合以提高性能。例如,分类作业使用完整的日志消息来检测异常,因此无法聚合此数据。如果您有许多“影响因素”字段,则使用聚合可能也没有好处。这是因为每个存储桶中只有几个文档可能具有所有不同“影响因素”字段的组合。
请参考聚合数据以提高性能以了解更多信息。
9. 优化结果保留
编辑设置结果保留窗口以减少存储的结果量。
默认情况下,异常检测结果会无限期保留。结果会随着时间的推移而累积,您的结果索引可能会非常大。大型结果索引查询速度慢,并且会占用集群上的大量空间。请考虑您希望保留结果的时间,并相应地设置 results_retention_days
,例如 30 天或 60 天,以避免不必要的大型结果索引。删除旧结果不会影响模型的行为。您可以为现有作业更改此设置。
10. 优化重新归一化窗口
编辑减少重新归一化窗口以减少处理工作负载。
当新的异常的分数远高于过去任何异常的分数时,异常分数会根据新数据在 0 到 100 的范围内进行调整。这称为重新归一化。它可能意味着在结果索引中重写大量文档。默认情况下,重新归一化发生在过去 30 天或 100 个存储桶跨度的结果中(以较长者为准)。当您大规模工作时,请将 renormalization_window_days
设置为较低的值,以减少工作负载。您可以为现有作业更改此设置,并且更改将在作业重新打开后生效。
11. 优化模型快照保留
编辑会定期创建模型快照,以确保在发生系统故障时具有弹性,并允许您手动还原到特定时间点。这些快照以压缩格式存储在内部索引中,并根据配置的保留策略进行保留。在索引模型快照时,集群会承受负载,并且随着保留多个快照,索引大小会增加。
当处理大型模型时,请考虑使用 background_persist_interval
创建模型快照的频率。默认值是每 3 到 4 小时。增加此间隔会减少集群上的定期索引负载,但在发生系统故障时,您可能需要还原到较旧版本的模型。
还要考虑使用 model_snapshot_retention_days
和 daily_model_snapshot_retention_after_days
保留快照的时间。保留较少的快照会大大减少模型状态的索引存储需求,但也会降低可以从中还原的模型快照的粒度。
有关更多信息,请参阅模型快照。
12. 优化搜索查询
编辑如果您在大规模操作,请确保您的数据馈送查询尽可能高效。编写 Elasticsearch 查询有不同的方法,其中一些方法比其他方法更有效。请参阅调整搜索速度,以了解有关 Elasticsearch 性能调整的更多信息。
如果要优化现有作业的搜索查询,则需要克隆或重新创建该作业。
13. 考虑使用群体分析
编辑群体分析比单独分析每个序列更节省内存。它会构建一个“典型”实体在指定时间段内执行操作的概要,然后识别出何时某个实体的行为与群体相比异常。如果您预计群体中的实体通常以相同的方式行为,请使用群体分析来分析高基数字段。
14. 降低预测成本
编辑创建预测时,需要考虑两个主要的性能因素:索引负载和内存使用情况。检查集群监控数据以了解索引速率和内存使用情况。
对于每个存储桶的每个预测元素,预测都会将新文档写入结果索引。具有高分区或按字段基数的作业会创建更多的结果文档,具有小存储桶跨度和较长预测持续时间的作业也会如此。单个作业只能运行三个并发预测。
要减少索引负载,请考虑缩短预测持续时间和/或尽量避免并发预测请求。通过查看作业配置可以实现进一步的性能提升;例如,使用专用结果索引、增加存储桶跨度和/或降低分区字段的基数。
默认情况下,预测的内存使用量限制为 20 MB。从 7.9 开始,您可以通过将 max_model_memory
设置为更高的值来扩展此限制。最大值为异常检测作业内存限制的 40% 或 500 MB。如果预测需要的内存超过提供的值,则会溢出到磁盘。溢出到磁盘的预测通常运行较慢。如果需要加速预测,请增加预测的可用内存。无法启动需要超过 500 MB 才能运行的预测,因为这是预测允许使用的最大磁盘空间限制。