任务管理器
编辑任务管理器编辑
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.max_workers 设置调整最大工作线程数，这允许每个 Kibana 在每个间隔内提取更多数量的任务。这可能会影响每个 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 实例。然后，您可以监控它们的性能，并在所需吞吐量变得更加清晰时重新评估。
尽管这是一个*粗略*的估计，但*每分钟任务数*提供了及时执行任务所需的下限。
估计*每分钟任务数*后，为非重复任务添加一个缓冲区。需要多少缓冲区很大程度上取决于您的用例。通过评估您的工作负载（随着工作负载的增长）并通过评估您的运行时来跟踪重复任务与非重复任务的比率，以确保预留了足够的缓冲区。