任务管理器
编辑任务管理器
编辑Kibana 任务管理器被诸如告警、操作和报告等功能所利用，以持久后台任务的形式运行关键性工作。这些后台任务将工作分配到多个 Kibana 实例上。这有三个主要好处
- 持久性：所有任务状态和调度都存储在 Elasticsearch 中，因此如果您重新启动 Kibana，任务将从中断的地方继续。
- 可伸缩性：多个 Kibana 实例可以从 Elasticsearch 中的同一任务队列读取和更新，从而允许工作负载在实例之间分配。如果 Kibana 实例不再有能力运行任务，您可以通过添加额外的 Kibana 实例来增加容量。
- 负载均衡：任务管理器配备了反应式的自我修复机制，这使其能够减少因 Elasticsearch 中错误率增加而导致的工作负载。此外，当任务管理器遇到重复任务增加时，它会尝试分散工作以更好地平衡负载。
告警和操作的任务定义存储在名为 .kibana_task_manager 的索引中。
对于生产部署，您必须至少拥有此索引的一个副本。
如果您丢失此索引，所有计划的告警和操作都将丢失。
运行后台任务
编辑Kibana 后台任务的管理方式如下
- 以 3 秒的间隔轮询 Elasticsearch 任务索引以查找过期的任务。您可以使用
xpack.task_manager.poll_interval设置更改此间隔。 - 通过在 Elasticsearch 索引中更新任务来声明任务，使用乐观并发控制来防止冲突。每个 Kibana 实例最多可以运行 10 个并发任务，因此每个间隔最多声明 10 个任务。
- 任务在 Kibana 服务器上运行。
-
任务管理器确保任务
- 只执行一次
- 在失败时重试（如果配置为这样做）
- 重新安排在未来的某个时间再次运行（如果配置为这样做）
部署注意事项
编辑Elasticsearch 和 Kibana 实例使用系统时钟来确定当前时间。为了确保按预期触发计划，请使用诸如 网络时间协议之类的时钟服务同步集群中所有节点的时钟。
扩展指南
编辑您如何部署 Kibana 在很大程度上取决于您的使用场景。预测部署可能需要支持任务管理的总吞吐量是困难的，因为功能可能会以各种计划的节奏安排不可预测的任务数量。
但是，您可以遵循一个相对简单的方法，根据您期望的使用情况生成粗略的估计值。
默认规模
编辑默认情况下，Kibana 以每 3 秒 10 个任务的速度轮询任务。这意味着您可以预期单个 Kibana 实例支持高达 200 个每分钟任务 (200/tpm)。
实际上，如果任务执行持续时间低于 3 秒的轮询率，Kibana 实例才能达到 200/tpm 的上限。在大多数情况下，任务的持续时间低于该阈值，但随着 Elasticsearch 和 Kibana 使用量的增长以及任务复杂性的增加（例如告警在大型数据集上执行繁重的查询），它可能会有很大差异。
通过 估计粗略的吞吐量要求，您可以估计需要多少个 Kibana 实例才能及时可靠地执行任务。可以估计适当数量的 Kibana 实例以匹配所需的规模。
有关监控 Kibana 任务管理器运行状况的详细信息，请遵循 运行状况监控中的指南。
水平扩展
编辑有时，可持续的方法可能是通过配置额外的 Kibana 实例来扩展集群的吞吐量。默认情况下，每个额外的 Kibana 实例将增加您的集群可以并发运行的 10 个任务，但是如果您的诊断表明它们可以处理额外的工作负载，您也可以垂直扩展每个 Kibana 实例。
垂直扩展
编辑有时，增加单个 Kibana 实例的吞吐量可能更可取。
使用 xpack.task_manager.capacity 设置调整容量，这使每个 Kibana 实例可以在每个间隔内拉取更多任务。由于工作负载会更高，因此此设置会影响每个实例的性能。
使用 xpack.task_manager.poll_interval 设置调整轮询间隔，这使每个 Kibana 实例可以以更高的速率拉取计划的任务。由于工作负载会更高，因此此设置会影响 Elasticsearch 集群的性能。
选择扩展策略
编辑每种扩展策略都有其自身的注意事项，适当的策略在很大程度上取决于您的使用场景。
垂直扩展 Kibana 实例会导致每个 Kibana 实例中更高的资源使用率，因为它将执行更多并发工作。水平扩展 Kibana 实例需要更高程度的协调，这可能会影响整体性能。
建议的策略是遵循以下步骤
- 生成 粗略的吞吐量估计，以此作为配置所需数量 Kibana 实例的指南。包括您预计在不久的将来会遇到的任务的任何增长，以及用于更好地处理临时任务的缓冲区。
- 配置部署后，通过评估 运行状况监控（如 没有足够的吞吐量来处理计划的工作负载中所述）来评估已配置的 Kibana 实例是否达到所需的吞吐量。
- 如果吞吐量不足，并且 Kibana 实例的资源使用率较低，请在 监控这些更改的影响的同时，逐步垂直扩展。
- 如果吞吐量不足，并且 Kibana 实例的资源使用率很高，请通过配置新的 Kibana 实例并重新评估来逐步水平扩展。
与 Elastic Stack 的其余部分一样，任务管理器旨在水平扩展。利用此功能来确保关键任务服务（例如告警、操作和报告）始终具有所需的容量。
水平扩展需要在 Kibana 实例之间进行更高程度的协调。任务管理器与其他实例协调的一种方式是通过延迟其轮询计划以避免与其他实例冲突。通过使用 运行状况监控来评估部署中 的 last_polling_delay 的日期，您可以估计任务管理器重置其延迟机制的频率。较高的频率表明 Kibana 实例以较高的速率冲突，您可以通过垂直扩展而不是水平扩展来解决此问题，从而减少所需的协调。
粗略的吞吐量估计
编辑预测部署可能需要支持任务管理所需的吞吐量是困难的，因为功能可能会以各种计划的节奏安排不可预测的任务数量。但是，可以估计一个粗略的下限，然后将其用作指南。
吞吐量最好被认为是每分钟任务数的度量。
默认的 Kibana 实例可以支持高达 200/tpm 的吞吐量。
自动估计
编辑此功能为技术预览版，可能会在以后的版本中更改或删除。Elastic 将努力解决任何问题，但技术预览版中的功能不受官方 GA 功能的支持 SLA 的约束。
如 评估您的容量估计 中所示，任务管理器 运行状况监控会自动执行这些估计。
这些估计基于历史数据，不应用作预测，但可以在扩展系统时用作粗略的指南。
我们建议配置足够的 Kibana 实例，以确保观察到的最大吞吐量（在 observed.max_throughput_per_minute 下估计）与平均所需吞吐量（在 observed.avg_required_throughput_per_minute 下估计）之间存在缓冲区。否则，可能没有足够的容量来处理临时任务的峰值。需要多少缓冲区在很大程度上取决于您的使用场景，但请记住，估计的吞吐量考虑了最近的峰值，并且只要它们能代表系统的行为，就不需要太多的缓冲区。
我们建议至少配置 proposed.provisioned_kibana 建议的 Kibana 实例数量，但请记住，此数字基于估计的所需吞吐量，该吞吐量基于平均历史性能，无法准确预测未来需求。
自动容量估计由每个 Kibana 实例独立执行。此估计是通过观察该实例中的任务吞吐量、当时执行任务的 Kibana 实例数量以及 Elasticsearch 中的重复工作负载来执行的。
如果在进行容量估计时 Kibana 实例处于空闲状态，则活动 Kibana 实例的数量可能会被错误计数，并且可用吞吐量会被错误计算。
在评估 proposed.provisioned_kibana 下建议的 Kibana 实例数量时，我们强烈建议验证 observed.observed_kibana_instances 是否与配置的 Kibana 实例的数量匹配。
手动估计
编辑通过 评估工作负载，您可以粗略估计所需的吞吐量，以每分钟任务数为单位。
例如，假设您当前的工作负载显示所需的吞吐量为 440/tpm。您可以通过配置 3 个 Kibana 实例来解决此规模问题，其吞吐量上限为 600/tpm。此规模将提供大约 25% 的额外容量来处理临时非重复任务以及重复任务的潜在增长。
假设部署了 100 个定期任务，估计所需的吞吐量取决于计划的频率。假设您期望以 10 秒的频率运行 50 个任务，以 20 分钟的频率运行另外 50 个任务。此外，您预计每分钟会有几十个非定期任务。
非定期任务只需要执行一次，这意味着单个 Kibana 实例可以在不到一分钟的时间内执行所有 100 个任务，并且只使用了其一半的容量。由于这些任务只执行一次，因此一旦所有任务都执行完毕，Kibana 实例将处于空闲状态。因此，请不要将非定期任务纳入您的每分钟任务数计算中。相反，在最终的下限中加入一个缓冲，以承担临时非定期任务的成本。
定期任务需要的执行次数与它在一分钟内可以容纳的频率次数一样多。一个计划为 10 秒的定期任务将需要 6/tpm，因为它每分钟执行 6 次。一个计划为 20 分钟的定期任务每小时只执行 3 次，只需要 0.05/tpm 的吞吐量，这个数字太小了，很难考虑进去。
因此，我们建议将任务按每分钟任务数和每小时任务数分组，如评估您的工作负载中所示，对所有分钟的每小时测量值进行平均。
强烈建议您在预期工作负载之外至少保持 20% 的额外容量，因为在活动高峰期（例如，响应活动警报的操作激增）时可能会出现临时任务的激增。
鉴于预测的工作负载，您可以估计 340/tpm 的吞吐量下限（6/tpm * 50 + 3/tph * 50 + 20% 的缓冲）。默认情况下，一个 Kibana 实例提供 200/tpm 的吞吐量。部署的良好起点是配置 2 个 Kibana 实例。然后，您可以监控它们的性能，并随着所需吞吐量变得更加清晰而重新评估。
尽管这是一个粗略的估计，每分钟任务数提供了按时执行任务所需的下限。
一旦您估计了每分钟任务数，请为非定期任务添加一个缓冲。需要多少缓冲在很大程度上取决于您的用例。通过评估您的工作负载（随着它的增长）并跟踪定期任务与非定期任务的比率来确保提供足够的缓冲，通过评估您的运行时间。