作者：来自 Elastic Mike Cote
Kibana 警报现在的扩展能力提升了 50 倍，每分钟可处理多达 160,000 条规则。了解任务管理器中的关键创新、更智能的资源分配以及性能优化如何帮助我们突破限制，实现显著的效率提升。
过去几年里，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 Alerting 如何通过 Task Manager 实现扩展
Kibana Alerting 允许用户基于实时数据定义规则并触发警报。在背后，Kibana 的 Task Manager 负责调度和运行这些规则。
Task Manager 是 Kibana 内置的任务调度器，专为处理异步后台任务而设计，与用户交互逻辑分离。它的主要职责包括：
-
运行一次性或周期性的任务，例如警报规则、连接器操作和报表
-
在 Kibana 背景节点加入或离开集群时动态分配工作负载
-
通过将任务卸载到专门的后台进程，保持 Kibana UI 的响应性
每条警报规则都会被转换为一个周期性的后台任务。每个后台任务都是一个 Elasticsearch 文档，也就是说，它以 Elasticsearch 文档的形式进行存储、获取和更新。随着警报规则数量的增加，Kibana 需要管理的后台任务数量也会增加。然而，每个 Kibana 节点在同一时间能处理的任务数量是有限的。一旦达到容量上限，多余的任务就必须等待，导致延迟增加和任务执行变慢。
问题所在：为何扩展能力受限
在这些改进之前，Task Manager 面临多项可扩展性限制，无法突破每分钟 3,200 个任务和 16 个 Kibana 节点的上限。在这个规模下，我们观察到边际效益递减，因为资源争用和效率低下限制了进一步扩展。这些数据是基于内部性能测试得出的，测试使用的是执行空操作的基础 Elasticsearch 查询型警报规则。观察到的边际效益递减主要包括：
任务争抢冲突
Task Manager 使用分布式轮询方式在 Elasticsearch 索引中争抢任务。Kibana 节点会定期查询任务，并通过 Elasticsearch 的乐观并发控制机制尝试争抢任务，以防止文档更新冲突。如果另一个节点先更新了任务，原节点就会放弃该任务，从而降低整体效率。
当过多的 Kibana 节点竞争任务时，文档更新冲突会急剧上升，导致在超过 16 个节点之后效率下降，系统吞吐量受限。
每个节点的吞吐效率低下
每个 Kibana 节点在同一时间能并发运行的任务数量是有限的（默认值为 10 个），以防止内存和 CPU 过载。虽然这是一个保护机制，但它常常导致 CPU 和内存资源未被充分利用，从而需要部署比实际更多的节点。
此外，轮询间隔（默认值为 3000 毫秒）决定了 Task Manager 多频繁争抢新任务。较短的轮询间隔虽然可以减少任务延迟，但也会加剧节点间的争抢，导致更多的更新冲突。
资源使用低效
在运行大量警报规则时，Kibana 节点会执行大量重复的 Elasticsearch 查询，每次运行警报规则时都会重复加载相同的对象和列表，消耗了比实际所需更多的 CPU、内存和 Elasticsearch 资源。为了支撑不断增加的请求负载，扩展系统往往需要代价高昂的基础设施扩容。
重要性所在
突破这些瓶颈对 Kibana 的持续发展至关重要。可扩展性的提升带来了以下优势：
-
成本优化：降低大规模运行所需的基础设施成本；
-
更快恢复能力：提升 Kibana 在节点或集群故障后的恢复速度；
-
面向未来的扩展能力：为计划任务、事件驱动自动化等更多工作负载提供扩展基础。
Kibana Task Manager 的关键创新
为了实现 50 倍的可扩展性提升，我们引入了多项创新：
Kibana 发现服务：更智能的扩展方式
此前，各 Kibana 节点彼此之间并不感知对方的存在，导致任务分配效率低下。全新的 Kibana 发现服务可以动态监控活跃节点，并相应地分配任务分区，实现负载均衡并降低争用。
任务分区：消除争抢
为防止多个节点争抢相同任务，我们引入了任务分区机制。现在，所有任务被划分到 256 个分区中，确保在任意时刻只有一小部分 Kibana 背景节点尝试争抢同一组任务。默认情况下，每个分区最多只被分配给两个 Kibana 节点，而单个节点可以负责多个分区。
任务成本评估：更智能的资源分配
并非所有后台任务的资源消耗都相同。我们引入了一套任务成本系统，根据 CPU 和内存使用情况为任务分配权重。这样，Task Manager 就可以动态调整每次争抢的任务数量，优化资源分配，确保高效性能。
全新的任务争抢算法
旧算法依赖 update-by-query 配合强制索引刷新来识别已争抢的任务。这种方式效率低下，同时会对 Elasticsearch 造成不必要的负载。新的算法则避免了这种做法，而是采用以下流程操作 Task Manager 索引：
-
首先使用
[_search](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html "_search")查询候选任务； -
然后使用
[_mget](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-multi-get.html "_mget")获取这些任务的最新文档版本（包括尚未体现在刷新后的索引状态中的更新）； -
通过比较
[_search](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html "_search")和[_mget](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-multi-get.html "_mget")的文档版本，筛除不匹配的文档； -
最后再进行批量更新。
这种方法不仅提高了 Elasticsearch 的效率，还为任务成本评估提供了更精细的控制能力。
通过综合考虑轮询间隔、任务并发数和索引刷新速率，我们能够计算出预期冲突的上限，并相应调整 [_search](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html "_search") 的分页大小。这可以确保即使有版本不匹配，也能检索到足够多的有效任务，避免 [_mget](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-multi-get.html "_mget") 因文档版本冲突而丢弃全部查询结果。
更频繁的任务轮询
通过任务分区和全新轻量级任务争抢算法，确保固定数量的节点竞争相同的任务，Task Manager 现在可以更频繁地轮询任务，而不会给 Elasticsearch 增加额外压力。这减少了任务完成与下一个任务开始之间的延迟，提升了整体系统吞吐量。
Kibana 警报中的性能优化
在使用 Elastic APM 进行优化之前，我们分析了警报规则的性能，发现警报框架每运行一个警报规则需要至少 20 次 Elasticsearch 查询。经过优化后，我们将查询次数减少到了仅 3 次，减少了 85%，显著提高了运行时间并降低了 CPU 开销。
此外，Elasticsearch 之前依赖资源密集型的 pbkdf2 哈希算法进行 API 密钥认证，这在大规模使用时会带来过多的开销。我们通过切换到更高效的 SHA-256 算法来优化认证，从而消除了因并发使用大量 API 密钥而导致的 Elasticsearch 内部缓存限制。
影响：用户的受益
早期的使用表明：
-
规则运行时间提高了 50%，减少了整体系统负载；
-
任务容量增加，使得更多任务可以在现有基础设施上运行；
-
较少出现资源不足的集群，减少了为满足需求而扩展基础设施的需要；
由于每个节点的吞吐量增加，并且集群得到了适当配置，平均任务延迟有所降低。
由于警报框架优化，规则运行时间大幅减少。
由于警报框架优化，Elasticsearch 请求数量大幅减少。
入门：如何高效扩展
升级到 Kibana 8.18 后，大部分好处将自动解锁。为了进一步优化，考虑调整 xpack.task_manager.capacity 设置，以最大化每个节点的吞吐量，同时确保 p999 资源使用率（内存、CPU 和事件循环利用率）保持在 80% 以下，事件循环延迟保持在 500 毫秒以下。
默认情况下，Kibana 设置了 32,000 条警报规则每分钟的保护限制。如果计划超过此限制，可以相应地修改 xpack.alerting.rules.maxScheduledPerMinute 设置。
新的 xpack.task_manager.capacity 设置使 Kibana 更有效地处理工作负载分配，以下设置在大多数情况下已不再需要，应从你的 kibana.yml 配置中移除：
-
xpack.task_manager.max_workers -
xpack.task_manager.poll_interval
如果你在本地运行 Kibana，并希望将后台任务隔离到专用节点上，可以使用 node.roles 设置，将负责 UI 提供的节点与处理后台任务的节点分开。如果你在 Elastic Cloud Hosted (ECH) 上使用 Kibana，升级到 8GB 或更高内存将自动启用这种隔离。
接下来是什么？
我们不会停留在 50 倍扩展能力上。我们的路线图目标是实现 100 倍以上的可扩展性，进一步消除 Elasticsearch 的瓶颈。
除了扩展能力，我们还专注于在大规模环境下改进系统监控。即将推出的集成将为系统管理员提供更深入的后台任务性能洞察，帮助他们更容易决定何时以及如何进行扩展。
此外，借助任务成本评估，我们计划在 Elastic Cloud Hosted (ECH) 客户端配置更多 CPU 和内存时（例如 Kibana 集群使用 2GB、4GB 或 8GB+ 内存），增加任务并发数。
请继续关注更多进展，我们将继续突破 Kibana 可扩展性的极限！
本文中描述的任何功能或功能的发布和时间安排完全由 Elastic 决定。任何当前不可用的功能或功能可能无法按时交付，甚至可能永远无法交付。
Elasticsearch 新增了许多功能，帮助你为特定使用场景构建最佳搜索解决方案。深入了解我们的示例笔记本，开始免费云试用，或者现在就在本地机器上尝试 Elastic。
原文：Kibana Alerting: Breaking past scalability limits & unlocking 50x scale - Elasticsearch Labs
