任务管理器故障排除
编辑任务管理器故障排除编辑
任务管理器由 Kibana 中的各种服务使用，例如 警报、操作、报告和遥测。这些服务中的意外行为可能是源于任务管理器的下游问题。
本页介绍如何解决您在使用任务管理器时可能遇到的常见问题。如果您的问题未在此处描述，请查看以下 GitHub 存储库中的开放问题
有问题？请在 讨论论坛 中联系我们。
具有较小调度间隔的任务运行延迟编辑
问题:
任务计划每 2 秒运行一次，但似乎运行延迟。
解决方案:
任务管理器以 xpack.task_manager.poll_interval 设置指定的频率轮询任务，默认值为 3 秒。这意味着如果任务使用比此设置更小的调度，则可能会运行延迟。
您可以调整 xpack.task_manager.poll_interval 设置。但是，这将增加集群中 Kibana 和 Elasticsearch 实例的额外负载，因为它们将执行更多查询。
任务运行延迟编辑
问题:
任务管理器中潜在问题的最常见症状是任务似乎运行延迟。例如，定期任务可能以不一致的频率运行，或者在计划时间很久之后运行。
解决方案:
默认情况下，Kibana 每 3 秒轮询 10 个任务。
如果许多任务计划在同一时间运行，待处理的任务将在 Elasticsearch 中排队。然后，每个 Kibana 实例以每 3 秒最多 10 个任务的速度轮询待处理的任务。队列中的待处理任务可能会超过此容量，并因此运行延迟。
这种类型的延迟称为漂移。漂移的根本原因取决于具体的使用情况，并且没有解决漂移的硬性规定。
例如
- 如果漂移是由 并发任务过多 相对于集群中可用 Kibana 实例的容量引起的，请扩展集群的吞吐量。
- 如果漂移是由 长时间运行的任务 超过其计划频率引起的，请重新配置相关任务。
有关诊断漂移的正确解决方案的分步说明，请参阅 诊断漂移的根本原因。
漂移通常通过调整部署的规模来解决，以更好地适应您的使用情况。有关扩展任务管理器的详细信息，请参阅 扩展指南。
诊断漂移的根本原因编辑
此功能处于技术预览阶段，可能会在将来的版本中更改或删除。Elastic 将努力解决任何问题，但技术预览中的功能不受官方 GA 功能支持 SLA 的约束。
以下指南通过分析 运行状况监控 端点的输出，帮助您确定漂移的根本原因。
通过分析输出的不同部分，您可以评估解释部署中漂移的不同理论。
检索 Kibana 实例任务管理器的最新监控运行状况统计信息
$ curl -X GET api/task_manager/_health
API 返回以下内容
{
"id": "15415ecf-cdb0-4fef-950a-f824bd277fe4",
"timestamp": "2021-02-16T11:38:10.077Z",
"status": "OK",
"last_update": "2021-02-16T11:38:09.934Z",
"stats": {
"configuration": {
"timestamp": "2021-02-16T11:29:05.055Z",
"value": {
"request_capacity": 1000,
"monitored_aggregated_stats_refresh_rate": 60000,
"monitored_stats_running_average_window": 50,
"monitored_task_execution_thresholds": {
"default": {
"error_threshold": 90,
"warn_threshold": 80
},
"custom": {}
},
"poll_interval": 3000,
"max_workers": 10
},
"status": "OK"
},
"runtime": {
"timestamp": "2021-02-16T11:38:09.934Z",
"value": {
"polling": {
"last_successful_poll": "2021-02-16T11:38:09.934Z",
"last_polling_delay": "2021-02-16T11:29:05.053Z",
"duration": {
"p50": 13,
"p90": 128,
"p95": 143,
"p99": 168
},
"claim_conflicts": {
"p50": 0,
"p90": 0,
"p95": 0,
"p99": 0
},
"claim_mismatches": {
"p50": 0,
"p90": 0,
"p95": 0,
"p99": 0
},
"result_frequency_percent_as_number": {
"Failed": 0,
"NoAvailableWorkers": 0,
"NoTasksClaimed": 80,
"RanOutOfCapacity": 0,
"RunningAtCapacity": 0,
"PoolFilled": 20
}
},
"drift": {
"p50": 99,
"p90": 1245,
"p95": 1845,
"p99": 2878
},
"load": {
"p50": 0,
"p90": 0,
"p95": 10,
"p99": 20
},
"execution": {
"duration": {
"alerting:.index-threshold": {
"p50": 95,
"p90": 1725,
"p95": 2761,
"p99": 2761
},
"alerting:xpack.uptime.alerts.monitorStatus": {
"p50": 149,
"p90": 1071,
"p95": 1171,
"p99": 1171
},
"actions:.index": {
"p50": 166,
"p90": 166,
"p95": 166,
"p99": 166
}
},
"persistence": {
"recurring": 88,
"non_recurring": 4,
"ephemeral": 8
},
"result_frequency_percent_as_number": {
"alerting:.index-threshold": {
"Success": 100,
"RetryScheduled": 0,
"Failed": 0,
"status": "OK"
},
"alerting:xpack.uptime.alerts.monitorStatus": {
"Success": 100,
"RetryScheduled": 0,
"Failed": 0,
"status": "OK"
},
"actions:.index": {
"Success": 10,
"RetryScheduled": 0,
"Failed": 90,
"status": "error"
}
}
}
},
"status": "OK"
},
"workload": {
"timestamp": "2021-02-16T11:38:05.826Z",
"value": {
"count": 26,
"task_types": {
"alerting:.index-threshold": {
"count": 2,
"status": {
"idle": 2
}
},
"actions:.index": {
"count": 14,
"status": {
"idle": 2,
"running": 2,
"failed": 10
}
},
"alerting:xpack.uptime.alerts.monitorStatus": {
"count": 10,
"status": {
"idle": 10
}
},
},
"schedule": [
["10s", 2],
["1m", 2],
["60s", 2],
["5m", 2],
["60m", 4],
["3600s", 1],
["720m", 1]
],
"non_recurring": 18,
"owner_ids": 0,
"overdue": 10,
"overdue_non_recurring": 10,
"estimated_schedule_density": [0, 1, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 1, 0, 0, 3, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 1, 0],
"capacity_requirements": {
"per_minute": 6,
"per_hour": 28,
"per_day": 2
}
},
"status": "OK"
},
"capacity_estimation": {
"timestamp": "2021-02-16T11:38:06.826Z",
"value": {
"observed": {
"observed_kibana_instances": 1,
"max_throughput_per_minute_per_kibana": 200,
"max_throughput_per_minute": 200,
"minutes_to_drain_overdue": 1,
"avg_recurring_required_throughput_per_minute": 28,
"avg_recurring_required_throughput_per_minute_per_kibana": 28,
"avg_required_throughput_per_minute": 28,
"avg_required_throughput_per_minute_per_kibana": 28
},
"proposed": {
"min_required_kibana": 1,
"provisioned_kibana": 1,
"avg_recurring_required_throughput_per_minute_per_kibana": 28,
"avg_required_throughput_per_minute_per_kibana": 28
}
}
"status": "OK"
}
}
}
评估配置编辑
诊断: 评估运行状况统计信息，您可以在 stats.configuration.value 下看到以下输出
{
"request_capacity": 1000,
"monitored_aggregated_stats_refresh_rate": 60000,
"monitored_stats_running_average_window": 50,
"monitored_task_execution_thresholds": {
"default": {
"error_threshold": 90,
"warn_threshold": 80
},
"custom": {}
},
"poll_interval": 3000,
"max_workers": 10
}
您可以从该输出推断出 Kibana 实例每 3 秒轮询一次工作，并且可以运行 10 个并发任务。
现在假设 stats.configuration.value 下的输出如下
{
"request_capacity": 1000,
"monitored_aggregated_stats_refresh_rate": 60000,
"monitored_stats_running_average_window": 50,
"monitored_task_execution_thresholds": {
"default": {
"error_threshold": 90,
"warn_threshold": 80
},
"custom": {}
},
"poll_interval": 60000,
"max_workers": 1
}
您可以从该输出推断出 Kibana 实例每分钟仅轮询一次工作，并且一次仅获取一个任务。这种吞吐量不太可能支持关键任务服务，例如警报或报告，并且任务通常会运行延迟。
这种配置可能有两种可能的原因
- 这些设置已手动配置，可以通过重新配置这些设置来解决。有关详细信息，请参阅 任务管理器设置。
-
Kibana 降低了自己的吞吐量，以应对 Elasticsearch 集群上的过度负载。
任务管理器配备了响应式自愈机制，以应对 Elasticsearch 中与负载相关的错误增加。此机制将增加
poll_interval设置（降低查询 Elasticsearch 的频率），并减少max_workers（减少对 Elasticsearch 执行的操作数量）。一旦错误率降低，这些设置将再次逐步调高，使其恢复到配置的设置。可以通过在 Kibana 服务器日志中搜索以下消息来识别这种情况
Max workers configuration is temporarily reduced after Elasticsearch returned 25 "too many request" error(s).
需要对 Elasticsearch 集群遇到的高错误率进行更深入的调查。
评估运行时编辑
诊断: 评估运行状况统计信息，您会在 stats.runtime.value.polling 下看到以下输出
{
"last_successful_poll": "2021-02-16T11:38:09.934Z",
"last_polling_delay": "2021-02-14T11:29:05.053Z",
"duration": {
"p50": 13,
"p90": 128,
"p95": 143,
"p99": 168
},
"claim_conflicts": {
"p50": 0,
"p90": 0,
"p95": 0,
"p99": 2
},
"claim_mismatches": {
"p50": 0,
"p90": 0,
"p95": 0,
"p99": 0
},
"result_frequency_percent_as_number": {
"Failed": 0,
"NoAvailableWorkers": 0,
"NoTasksClaimed": 80,
"RanOutOfCapacity": 0,
"RunningAtCapacity": 0,
"PoolFilled": 20
}
}
|
确保上次成功的轮询周期在过去不超过 |
|
|
确保轮询周期的持续时间通常低于 100 毫秒。更长的持续时间是可能的，但并非预期。 |
|
|
确保集群中的 Kibana 实例没有遇到高版本的冲突率。 |
|
|
确保大多数轮询周期都产生积极的结果，例如 |
您可以从该输出推断出 Kibana 实例正在定期轮询。此评估基于以下内容
- 将
last_successful_poll与根目录下的timestamp（值为2021-02-16T11:38:10.077Z）进行比较，您可以看到上次轮询周期在监控统计信息由运行状况监控 API 公开之前 1 秒完成。 - 将
last_polling_delay与根目录下的timestamp（值为2021-02-16T11:38:10.077Z）进行比较，您可以看到上次轮询周期的延迟发生在 2 天前，这表明 Kibana 实例没有经常发生冲突。 duration的p50显示至少 50% 的轮询周期最多需要 13 毫秒才能完成。-
评估
result_frequency_percent_as_number- 80% 的轮询周期在没有声明任何任务的情况下完成（表明没有逾期任务）。
- 20% 在任务管理器声明并执行任务的情况下完成。
- 没有轮询周期最终占用所有可用工作线程，因为
RunningAtCapacity的频率为 0%，这表明任务管理器有足够的容量来处理工作负载。
所有这些统计信息都作为运行平均值进行跟踪，这意味着它们提供了一段时间内的快照（默认情况下，Kibana 跟踪最多 50 个周期），而不是提供完整的历史记录。
假设 stats.runtime.value.polling.result_frequency_percent_as_number 下的输出如下
{
"Failed": 30,
"NoAvailableWorkers": 20,
"NoTasksClaimed": 10,
"RanOutOfCapacity": 10,
"RunningAtCapacity": 10,
"PoolFilled": 20
}
|
30% 的轮询周期失败，这是一个很高的比率。 |
|
|
20% 的轮询周期被跳过，因为任务管理器没有剩余容量来运行任务。 |
|
|
10% 的轮询周期导致任务管理器声明的任务数量超过其运行容量。 |
|
|
10% 的轮询周期导致任务管理器声明的任务数量与其运行容量完全相同。 |
您可以从该输出推断出任务管理器不健康，因为失败率很高，并且任务管理器正在获取它没有容量运行的任务。分析 Kibana 服务器日志应该会揭示导致高错误率和容量问题的根本问题。
高 NoAvailableWorkers 比率（20%）表明有许多任务的运行时间超过了 poll_interval。有关分析长时间运行的任务执行持续时间的详细信息，请参阅 长时间运行的任务 理论。
理论: Kibana 正在以预期频率轮询，但这不足以跟上工作负载
诊断: 评估健康状况，您可以在 stats.runtime.value 下看到 drift 和 load 的以下输出
{
"drift": {
"p50": 99,
"p90": 1245,
"p95": 1845,
"p99": 2878
},
"load": {
"p50": 0,
"p90": 0,
"p95": 10,
"p99": 20
},
}
您可以从这些统计数据推断出，此 Kibana 拥有充足的容量，您可能遇到的任何延迟不太可能通过扩展吞吐量来解决。
假设 drift 和 load 的输出如下
{
"drift": {
"p50": 2999,
"p90": 3845,
"p95": 3845.75,
"p99": 4078
},
"load": {
"p50": 80,
"p90": 100,
"p95": 100,
"p99": 100
}
}
您可以从这些统计数据推断出，此 Kibana 正在使用其大部分容量，但似乎大部分时间都能跟上工作。此评估基于以下内容
load的p90为 100%，p50也相当高，为 80%。这意味着几乎没有回旋余地，工作量激增可能会导致任务管理器超出其容量。- 任务在计划时间后不久运行，这是预期的。
poll_interval为3000毫秒通常会经历0到3000毫秒之间的持续漂移。p50 drift为2999表明有改进的空间，您可以从更高的吞吐量中受益。
有关通过调整扩展策略来实现更高吞吐量的详细信息，请参阅 扩展指南。
诊断: 处理计划工作负载的吞吐量不足 理论分析了一个假设场景，其中漂移和负载都异常高。
假设另一种情况，其中 drift 较高，但 load 不高，例如以下情况
{
"drift": {
"p50": 9799,
"p90": 83845,
"p95": 90328,
"p99": 123845
},
"load": {
"p50": 40,
"p90": 75,
"p95": 80,
"p99": 100
}
}
在前面的场景中，任务运行得太晚，但您有足够的容量来运行更多并发任务。高容量允许 Kibana 并发运行多个不同的任务。如果任务在下一个计划运行时间到期时已经在运行，Kibana 将避免第二次运行它，而是等待第一次执行完成。
如果任务的执行时间超过其计划的节奏，那么该任务将始终超时并经历高漂移。例如，假设一个任务计划每 3 秒执行一次，但需要 6 秒才能完成。它将始终遭受至少 3 秒的漂移。
评估此假设场景中的健康状况，您将在 stats.runtime.value.execution.duration 下看到以下输出
{
"alerting:.index-threshold": {
"p50": 95,
"p90": 1725,
"p95": 2761,
"p99": 2761
},
"alerting:.es-query": {
"p50": 7149,
"p90": 40071,
"p95": 45282,
"p99": 121845
},
"actions:.index": {
"p50": 166,
"p90": 166,
"p95": 166,
"p99": 166
}
}
您可以从这些统计数据推断出，任务管理器遇到的高漂移很可能是由于 Elasticsearch 查询警报运行时间过长造成的。
解决此问题取决于上下文，并且会因情况而异。在前面的示例中，这可以通过修改这些警报中的查询以使其更快，或者提高 Elasticsearch 吞吐量以加快现有查询来解决。
诊断: 高错误率会导致任务看起来运行得很晚，而实际上它按时运行，但经历了很高的失败率。
评估前面的健康状况，您将在 stats.runtime.value.execution.result_frequency_percent_as_number 下看到以下输出
{
"alerting:.index-threshold": {
"Success": 100,
"RetryScheduled": 0,
"Failed": 0,
"status": "OK"
},
"alerting:xpack.uptime.alerts.monitorStatus": {
"Success": 100,
"RetryScheduled": 0,
"Failed": 0,
"status": "OK"
},
"actions:.index": {
"Success": 8,
"RetryScheduled": 0,
"Failed": 92,
"status": "error"
}
}
|
支持索引阈值警报的 100% 的任务成功完成。 |
|
|
支持 ES 索引操作的 92% 的任务未能完成。 |
|
|
支持 ES 索引操作的任务已超过默认的 |
您可以从这些统计数据推断出，大多数支持 ES 索引 Kibana 操作的 actions:.index 任务都失败了。解决此问题需要深入调查 Kibana 服务器日志，其中记录了确切的错误，并解决这些特定错误。
诊断: 任务管理器使用临时非定期任务在多个 Kibana 实例之间负载平衡操作。此外，Kibana 可以使用任务管理器通过执行短暂任务来为昂贵的操作分配资源。短暂任务在操作上与非定期任务相同，但不会持久化，也不能在 Kibana 实例之间负载平衡。
评估前面的健康状况，您将在 stats.runtime.value.execution.persistence 下看到以下输出
您可以从这些统计数据推断出，大多数执行（88%）由定期任务组成。您可以使用 execution.persistence 统计数据来评估消耗容量的比率，但仅凭它们，您不应该对可用容量的充足性做出假设。
要评估容量，您应该将这些统计数据与 stats.runtime.value 下的 load 进行比较
您可以从这些统计数据推断出，任务管理器非常不寻常地会用完容量，因此容量可能足以处理非定期和短暂任务的数量。
假设您有另一种情况，您在 stats.runtime.value.execution.persistence 下看到以下输出
您可以从这些统计数据推断出，尽管大多数执行是定期任务，但 40% 的执行是非定期和短暂任务。
评估 stats.runtime.value 下的 load，您将看到以下内容
您可以从这些统计数据推断出，此 Kibana 实例经常会用完容量。鉴于非定期和短暂任务的高比率，合理地评估 Kibana 集群中没有足够的容量来处理任务量。
请记住，这些统计数据只是对某一时刻的快照，即使最近几分钟内容量不足，但这在其他时间可能不成立，因为在其他时间使用较少的非定期或短暂任务。我们建议跟踪这些统计数据，并确定这些任务的来源，然后再对基础设施进行大规模更改。
评估工作负载编辑
预测部署可能需要支持任务管理器的所需吞吐量很困难，因为功能可以以各种计划节奏安排不可预测数量的任务。
健康状况监控 提供了统计数据，使监控现有吞吐量的充分性变得更容易。通过评估工作负载，可以估计所需的吞吐量，这在遵循任务管理器 扩展指南 时使用。
评估前面示例中的健康状况，您将在 stats.workload.value 下看到以下输出
{
"count": 26,
"task_types": {
"alerting:.index-threshold": {
"count": 2,
"status": {
"idle": 2
}
},
"actions:.index": {
"count": 14,
"status": {
"idle": 2,
"running": 2,
"failed": 10
}
},
"alerting:xpack.uptime.alerts.monitorStatus": {
"count": 10,
"status": {
"idle": 10
}
},
},
"non_recurring": 0,
"owner_ids": 1,
"schedule": [
["10s", 2],
["1m", 2],
["90s", 2],
["5m", 8]
],
"overdue_non_recurring": 0,
"overdue": 0,
"estimated_schedule_density": [
0, 1, 0, 0, 0, 1, 0, 1, 0, 1,
0, 0, 0, 1, 0, 0, 1, 1, 1, 0,
0, 3, 0, 0, 0, 1, 0, 1, 0, 1,
0, 0, 0, 1, 0, 0, 1, 1, 1, 0
],
"capacity_requirements": {
"per_minute": 14,
"per_hour": 240,
"per_day": 0
}
}
|
系统中有 26 个任务，包括常规任务、定期任务和失败的任务。 |
|
|
有 2 个 |
|
|
在支持 ES 索引操作的 14 个任务中，10 个已失败，2 个正在运行。 |
|
|
队列中没有非定期任务。 |
|
|
有一个任务管理器正在积极执行任务。可能还有其他空闲的任务管理器，但它们目前没有积极执行任务。 |
|
|
所有计划的定期任务的直方图显示，2 个任务计划每 10 秒运行一次，2 个任务计划每分钟运行一次，等等。 |
|
|
没有过期的非定期任务。非定期任务通常计划立即执行，因此过期的非定期任务通常是系统拥塞的症状。 |
|
|
没有过期的任务，这意味着所有应该运行的任务都已运行。 |
|
|
此直方图显示了在接下来的 20 个轮询周期中计划运行的任务。直方图表示整个部署，而不仅仅是此 Kibana 实例。 |
|
|
处理系统中定期任务所需的容量。这些是桶，而不是聚合总和，我们建议 评估容量估计 部分，而不是自己评估这些桶。 |
workload 部分总结了整个集群的工作负载，列出了系统中的任务、它们的类型、计划和当前状态。
您可以从这些统计数据推断出，默认部署应该足够。此评估基于以下内容
- 估计的计划密度很低。
- 相对于默认容量而言，系统中的任务并不多。
假设 stats.workload.value 的输出类似于以下内容
{
"count": 2191,
"task_types": {
"alerting:.index-threshold": {
"count": 202,
"status": {
"idle": 183,
"claiming": 2,
"running": 19
}
},
"alerting:.es-query": {
"count": 225,
"status": {
"idle": 225,
}
},
"actions:.index": {
"count": 89,
"status": {
"idle": 24,
"running": 2,
"failed": 63
}
},
"alerting:xpack.uptime.alerts.monitorStatus": {
"count": 87,
"status": {
"idle": 74,
"running": 13
}
},
},
"non_recurring": 0,
"owner_ids": 1,
"schedule": [
["10s", 38],
["1m", 101],
["90s", 55],
["5m", 89],
["20m", 62],
["60m", 106],
["1d", 61]
],
"overdue_non_recurring": 0,
"overdue": 0,
"estimated_schedule_density": [
10, 1, 0, 10, 0, 20, 0, 1, 0, 1,
9, 0, 3, 10, 0, 0, 10, 10, 7, 0,
0, 31, 0, 12, 16, 31, 0, 10, 0, 10,
3, 22, 0, 10, 0, 2, 10, 10, 1, 0
],
"capacity_requirements": {
"per_minute": 329,
"per_hour": 4272,
"per_day": 61
}
}
|
系统中有 2,191 个任务。 |
|
|
计划的任务分布在各种节奏中。 |
|
|
计划密度显示您预计会超过默认的 10 个并发任务。 |
|
|
有 329 个任务执行在每分钟内重复。 |
|
|
有 4,273 个任务执行在每小时内重复。 |
|
|
有 61 个任务执行在每天内重复。 |
您可以从此输出中推断出工作负载的几个重要属性
- 您的系统中有许多任务，确保这些任务按计划节奏运行需要关注任务管理器的吞吐量。
- 评估高频任务（以几分钟或更短的节奏重复的任务），您必须支持每分钟大约 330 个任务执行的吞吐量（每 10 秒 38 个 + 每分钟 101 个）。
- 评估中频任务（每小时或更短时间内重复的任务），您需要支持每小时超过 4,272 次的任务执行量（每 90 秒 55 次 + 每 5 分钟 89 次 + 每 20 分钟 62 次 + 每小时 106 次）。您可以将每小时所需的吞吐量平均计算，将这些任务视为每分钟额外 70-80 个任务。
- 评估估计的调度密度，有一些周期需要同时运行多达 31 个任务，并且在这些周期旁边还有空闲周期。您可以预期任务管理器在整个空闲周期内对这些任务进行负载均衡，但这不会留下太多容量来处理将来可能安排的突发任务。
这些粗略的计算为您提供了所需吞吐量的下限，即每分钟至少 410 个任务，以确保重复任务按计划时间执行。此吞吐量不考虑可能已安排的非重复任务，也不考虑将来可能安排的任务（重复或其他）。
根据这些推断的属性，可以安全地假设单个 Kibana 实例使用默认设置不会提供所需的吞吐量。通过添加几个 Kibana 实例进行水平扩展可能是可行的。
有关扩展任务管理器的详细信息，请参阅扩展指南。
评估容量估计编辑
任务管理器不断评估其运行时操作和工作负载。这使任务管理器能够对容量的充足性进行粗略估计。
顾名思义，这些是基于历史数据的估计，不应被用作预测。在对基础设施进行更改之前，应将这些估计与详细的运行状况监控统计信息一起评估。这些估计假设所有 Kibana 实例的配置相同。
建议在遵循任务管理器扩展指南时使用这些估计。
评估上一个示例中的运行状况统计信息，您可以在stats.capacity_estimation.value下看到以下输出
{
"observed": {
"observed_kibana_instances": 1,
"minutes_to_drain_overdue": 1,
"max_throughput_per_minute_per_kibana": 200,
"max_throughput_per_minute": 200,
"avg_recurring_required_throughput_per_minute": 28,
"avg_recurring_required_throughput_per_minute_per_kibana": 28,
"avg_required_throughput_per_minute": 28,
"avg_required_throughput_per_minute_per_kibana": 28
},
"proposed": {
"min_required_kibana": 1,
"provisioned_kibana": 1,
"avg_recurring_required_throughput_per_minute_per_kibana": 28,
"avg_required_throughput_per_minute_per_kibana": 28
}
}
|
这些估计假设有一个 Kibana 实例正在积极执行任务。 |
|
|
根据过去的吞吐量，系统中逾期的任务可以在 1 分钟内执行完毕。 |
|
|
假设集群中的所有 Kibana 实例都与该实例配置相同，则最大可用吞吐量为每分钟 200 个任务。 |
|
|
平均而言，系统中重复任务在历史上需要每分钟 28 个任务的吞吐量。 |
|
|
平均而言，无论任务是重复的还是其他的，系统中的任务在历史上需要每分钟 28 个任务的吞吐量。 |
|
|
一个 Kibana 实例应该足以运行当前的重复工作负载。 |
|
|
我们建议等待工作负载发生变化，然后再配置额外的 Kibana 实例。 |
capacity_estimation部分由两个子部分组成
-
observed通过观察历史运行时和工作负载统计信息来估计当前容量 -
proposed估计基线 Kibana 集群大小以及在这种部署策略下的预期吞吐量
您可以从这些估计中推断出，当前系统利用率不足，并且有足够的容量来处理比目前更多的任务。
假设另一种情况，您在stats.capacity_estimation.value下看到以下输出
{
"observed": {
"observed_kibana_instances": 2,
"max_throughput_per_minute_per_kibana": 200,
"max_throughput_per_minute": 400,
"minutes_to_drain_overdue": 12,
"avg_recurring_required_throughput_per_minute": 354,
"avg_recurring_required_throughput_per_minute_per_kibana": 177,
"avg_required_throughput_per_minute": 434,
"avg_required_throughput_per_minute_per_kibana": 217
},
"proposed": {
"min_required_kibana": 2,
"provisioned_kibana": 3,
"avg_recurring_required_throughput_per_minute_per_kibana": 118,
"avg_required_throughput_per_minute_per_kibana": 145
}
}
|
这些估计假设有两个 Kibana 实例正在积极执行任务。 |
|
|
系统当前的最大可用吞吐量为每分钟 400 个任务。 |
|
|
根据过去的吞吐量，系统中逾期的任务应该在 12 分钟内执行完毕。 |
|
|
平均而言，系统中重复任务在历史上需要每分钟 354 个任务的吞吐量。 |
|
|
平均而言，每个 Kibana 实例利用其容量的每分钟 177 个任务来执行重复任务。 |
|
|
平均而言，系统中的任务在历史上需要每分钟 434 个任务的吞吐量。 |
|
|
系统估计至少需要两个 Kibana 实例才能运行当前的重复工作负载。 |
|
|
系统建议配置三个 Kibana 实例来处理工作负载。 |
|
|
配置第三个 Kibana 实例后，每个实例用于执行重复任务的容量利用率应该从每分钟 177 个任务下降到每分钟 118 个任务。 |
|
|
考虑到历史上的临时任务执行，我们估计配置第三个 Kibana 实例后，每个 Kibana 实例所需的吞吐量将从每分钟 217 个任务下降到每分钟 145 个任务。 |
通过这些估计进行评估，我们可以推断出系统的一些有趣属性
- 这些估计是基于集群中有两个 Kibana 实例的假设得出的。此数字基于最近几分钟内积极执行任务的 Kibana 实例数量。如果 Kibana 实例保持空闲，有时此数字可能会波动，因此建议根据您对系统的了解来验证这些估计。
- 似乎有太多逾期的任务，需要 12 分钟的执行才能赶上这些积压。这没有考虑到在这 12 分钟内可能变得逾期的任务。虽然这种拥塞可能是暂时的，但系统也可能始终处于供应不足状态，并且可能永远无法完全消除积压。
- 评估工作负载中的重复任务，系统平均需要每分钟 354 个任务的吞吐量才能按时执行任务，这低于估计的最大吞吐量每分钟 400 个任务。但是，一旦我们考虑到历史吞吐量，我们估计所需的吞吐量为每分钟 434 个任务。这表明，在历史上，大约 20% 的任务是临时非重复任务，其规模比重复任务更难预测。
您可以从这些估计中推断出，当前系统的容量不足，至少需要一个额外的 Kibana 实例才能跟上工作负载。
有关扩展任务管理器的详细信息，请参阅扩展指南。
Elasticsearch 中禁用了内联脚本编辑
问题:
任务没有运行，服务器日志包含以下错误消息
[warning][plugins][taskManager] Task Manager cannot operate when inline scripts are disabled in {es}
解决方案:
内联脚本是任务管理器正常运行的硬性要求。要启用内联脚本，请参阅 Elasticsearch 文档，了解配置允许的脚本类型设置。
如果任务的runAt在过去，该怎么办？编辑
问题:
任务的属性runAt在过去。
解决方案:
在将其宣布为失败之前，请等待片刻，因为任务管理器可能只是落后于其工作。您应该查看 Kibana 日志，并查看您能找到与任务管理器相关的任何内容。在健康的环境中，您应该看到一条日志行，表明任务管理器在 Kibana 启动时已成功启动
server log [12:41:33.672] [info][plugins][taskManager][taskManager] TaskManager is identified by the Kibana UUID: 5b2de169-2785-441b-ae8c-186a1936b17d
如果您看到该消息，并且没有其他与任务管理器相关的错误，则很可能是任务管理器运行良好，只是还没有机会拾取该任务。另一方面，如果 runAt 严重逾期，那么值得寻找其他任务管理器或警报相关的错误，因为可能发生了其他问题。值得查看 status 字段，因为它可能已失败，这将解释为什么它没有被拾取，或者它可能正在运行，这意味着该任务可能只是一个运行时间很长的任务。
如果任务标记为失败，该怎么办？编辑
问题:
标记为失败的任务。
解决方案:
总的来说，警报框架旨在优雅地处理任务失败的情况，方法是在将来重新安排新的运行。如果这种情况没有发生，那么这意味着底层实现中出现了一些问题，这是不可预期的。理想情况下，您应该尝试找到与该规则及其任务相关的任何日志行，并使用这些日志行来帮助我们进一步调查。
任务管理器 Kibana 日志编辑
任务管理器将在某些情况下将日志行写入 Kibana 日志。以下是常见的一些日志行及其含义。
任务管理器已用完可用工作线程
server log [12:41:33.672] [info][plugins][taskManager][taskManager] [Task Ownership]: Task Manager has skipped Claiming Ownership of available tasks at it has ran out Available Workers.
此日志消息告诉我们，任务管理器无法跟上它被分配完成的大量工作。这可能意味着规则没有按预期频率运行（例如，不是每 5 分钟运行一次，而是每 7-8 分钟运行一次）。
默认情况下，任务管理器限制为 10 个任务，可以通过在 kibana.yml 文件中使用xpack.task_manager.max_workers配置设置更高的数字来提高此限制。重要的是要记住，在任何给定时间运行的任务数量越多，对 Kibana 和 Elasticsearch 的负载就越大，因此只有在增加环境中的负载有意义的情况下才更改此设置。
解决此问题的另一种方法可能是告诉工作线程以更高的速率运行，而不是添加更多工作线程，这可以通过使用 xpack.task_manager.poll_interval 来配置。此值决定任务管理器检查是否有更多工作要做的频率，并使用毫秒（默认值为 3000，这意味着间隔为 3 秒）。
在更改这两个数字之前，强烈建议调查任务管理器无法跟上的原因 - 系统中是否有异常高的规则数量？规则是否经常失败，迫使任务管理器不断重新运行它们？Kibana 是否负载过重？可能存在各种问题，这些问题都不应该通过简单地更改这些配置来解决。
任务 TaskType 在运行尝试中失败
server log [12:41:33.672] [info][plugins][taskManager][taskManager] Task TaskType "alerting:example.always-firing" failed in attempt to run: Unable to load resource ‘/api/something’
此日志消息告诉我们，当任务管理器运行我们的规则之一时，它的任务出错并因此失败。在这种情况下，我们可以确定失败的规则类型为 alerting:example.always-firing，并且失败的原因是无法加载资源“/api/something”。这是一个虚构的示例，但总的来说，如果您看到格式类似于此的消息，那么这将告诉您问题可能出在哪里。
例如，在这种情况下，我们预计会看到来自警报框架本身的相应日志行，表明该规则已失败。您应该在 Kibana 日志中查找类似于以下日志行的行（可能在任务管理器日志行之前不久）
执行规则“27559295-44e4-4983-aa1b-94fe043ab4f9”导致错误：无法加载资源“/api/something”
这将确认错误确实发生在规则本身（而不是任务管理器）中，并且将帮助我们查明失败的特定规则 ID：27559295-44e4-4983-aa1b-94fe043ab4f9
我们现在可以使用 ID 通过使用 http 端点查找该规则的配置和当前状态来帮助调查可能导致问题的原因。