Kibana Alerting: 突破扩展性限制，实现50倍规模提升

原创

点火三周

发布于 2025-04-23 07:53:05

970

文章被收录于专栏：Elastic Stack专栏Elastic Stack专栏

在过去的几年里，Kibana告警一直是许多大型组织的首选监控解决方案。随着使用的不断增加，用户创建的告警规则数量也在增长。越来越多的组织依赖Kibana进行大规模告警，我们看到了提高效率和确保未来工作负载性能的机会。

在Kibana 8.16到8.18之间，我们正面解决了这些问题，引入了关键的改进，突破了之前的扩展性限制。在这些改进之前，Kibana告警每分钟最多支持3,200个规则，而且至少需要16个Kibana节点，才能避免严重的性能瓶颈。到了Kibana 8.18，我们将每分钟规则的扩展能力提高了50倍，支持每分钟最多160,000个轻量级告警规则。这是通过让Kibana有效扩展超过16个节点，并将每个节点的处理能力从每分钟200个规则提升到最多3,500个规则来实现的。这些增强使所有告警规则运行得更快，延迟更少，效率更高。

本文将探讨我们克服的扩展挑战、实现这一目标的关键创新，以及如何利用这些改进高效地运行大规模的Kibana告警。

Kibana告警如何与任务管理器一起扩展

Kibana告警允许用户定义基于实时数据触发告警的规则。在幕后，Kibana任务管理器负责调度和运行这些规则。

任务管理器是Kibana内置的作业调度程序，旨在将异步后台任务与用户交互分开处理。它的主要职责包括：

运行一次性和周期性任务，例如告警规则、连接器操作和报告。
动态分配工作负载，当Kibana后台节点加入或离开集群时。
保持Kibana UI响应，通过将任务卸载到专用的后台进程。

每个告警规则都会转化为一个周期性后台任务。每个后台任务都是一个Elasticsearch文档，意味着它会被存储、获取和更新。随着告警规则数量的增加，Kibana需要管理的后台任务也在增加。然而，每个Kibana节点能够同时处理的任务数量是有限的。一旦达到容量，额外的任务就需要等待，导致延迟和任务运行时间变慢。

问题：为什么扩展受限

在这些改进之前，任务管理器面临一些扩展性限制，无法超过每分钟3,200个任务和16个Kibana节点。在这个规模上，我们观察到由于争用和资源低效，进一步扩展时收益递减。这些数字基于内部性能测试，使用一个基本的Elasticsearch查询告警规则进行无操作查询。观察到的收益递减包括：

任务争夺

任务管理器使用分布式轮询方式在Elasticsearch索引内认领任务。Kibana节点周期性查询任务并尝试使用Elasticsearch的乐观并发控制来认领任务，防止冲突的文档更新。如果另一个节点先更新了任务，原节点就会放弃它，降低整体效率。

当有太多Kibana节点争夺任务时，文档更新冲突急剧增加，效率受限于16个节点，系统吞吐量降低。

节点处理能力低效

每个Kibana节点都有一个默认的并发任务限制（默认：同时10个任务），以防止内存和CPU过载。这一保护措施常常导致CPU和内存未被充分利用，需要比必要的更多节点。

另外，轮询间隔（默认：3000ms）定义了任务管理器认领新任务的频率。较短的间隔减少任务延迟，但增加节点间的争夺。

资源低效

在运行大量告警规则时，Kibana节点执行重复的Elasticsearch查询，重复加载相同的对象和列表，消耗了比必要更多的CPU、内存和Elasticsearch资源。扩展需要昂贵的基础设施扩张以支持不断增加的请求负载。

为什么重要

打破这些限制对于Kibana的持续发展至关重要。提高扩展性可以实现：

成本优化：降低大规模运营的基础设施成本。
更快的恢复：提升Kibana从节点或集群故障中恢复的能力。
未来扩展：为额外的工作负载（如定时报告和事件驱动自动化）提供扩展能力。

Kibana任务管理器的关键创新

为了实现50倍的扩展提升，我们引入了几个创新：

Kibana发现服务：更智能的扩展

之前，Kibana节点彼此之间没有意识，导致任务分配效率低下。新的Kibana发现服务动态监控活跃节点并相应地分配任务分区，确保负载均匀分布，减少争夺。

任务分区：消除争夺

为了防止节点争夺相同的任务，我们引入了任务分区。任务现在分布在256个分区内，确保在任何给定时间只有一部分Kibana后台节点尝试认领相同的任务。默认情况下，每个分区分配给最多两个Kibana节点，而单个Kibana节点可以负责多个分区。

任务计费：更智能的资源分配

并不是所有后台任务都消耗相同的资源。我们实施了一个任务计费系统，根据CPU和内存使用情况分配任务权重。这使得任务管理器能够动态调整认领的任务数量，优化资源分配，确保高效性能。

新的任务认领算法

旧算法依赖于通过查询更新强制索引刷新来识别已认领的任务。这种方式效率低下，并且对Elasticsearch造成了不必要的负担。新算法避免了这一点，通过搜索任务而不需要立即刷新。相反，它在任务管理器索引上执行以下操作：一个_search来寻找候选任务，接着一个_mget，返回可能最近更新但尚未反映在刷新索引状态中的文档。通过比较_search和_mget结果中的文档版本，它在继续批量更新之前丢弃不匹配项。这种方法提高了Elasticsearch的效率，并提供了更细致的控制以支持任务计费。

通过考虑轮询间隔、任务并发和索引刷新率，我们可以计算预期冲突的上限，并相应调整_search页大小。这有助于确保检索到足够多的任务，以防_mget因文档版本不匹配而丢弃所有搜索结果。