Kapacitor 常见问题

此页面解答了与 Kapacitor 相关的常见困惑或重要须知事项。在适用的情况下，它链接到 Github 上的未解决问题。

管理

• 更新脚本时，警报状态和警报数据会丢失吗？
• 如何验证 Kapacitor 是否正在从 InfluxDB 接收数据？

TICKscript

• 批量处理工作正常，但流处理不正常。为什么？
• Kapacitor 可以处理的脚本数量是否有限制？
• 是什么导致具有相同时间戳的意外或额外值？？

性能

• 运行一个复杂的脚本还是并行运行多个脚本，哪种性能更好？
• 基于模板的脚本是否使用更少的资源，或者它们只是一个易于使用的工具？
• Kapacitor 如何处理高负载？
• 如何优化 Kapacitor 任务？

管理

更新脚本时，警报状态和警报数据会丢失吗？

Kapacitor 将记住警报的最后一个级别，但其他类状态数据（例如窗口中缓冲的数据）将丢失。

如何验证 Kapacitor 是否正在从 InfluxDB 接收数据？

有几种方法可以确定 Kapacitor 是否正在从 InfluxDB 接收数据。 kapacitor stats ingress 命令输出存储在 Kapacitor 数据库中的 InfluxDB 指标，以及通过 Kapacitor 服务器的数据点数量。

$ kapacitor stats ingress
Database   Retention Policy Measurement    Points Received
_internal  monitor          cq                        5274
_internal  monitor          database                 52740
_internal  monitor          httpd                     5274
_internal  monitor          queryExecutor             5274
_internal  monitor          runtime                   5274
_internal  monitor          shard                   300976
# ...

您还可以使用 Kapacitor 的 /debug/vars API 端点 来查看和监控摄取率。使用此端点和 Telegraf 的 Kapacitor 输入插件，您可以创建可视化效果来监控 Kapacitor 摄取率。以下是示例查询，这些查询使用 Telegraf 的 Kapacitor 输入插件写入 InfluxDB 的 Kapacitor 数据

Kapacitor 摄取率（点/秒）

SELECT sum(points_received_rate) FROM (SELECT non_negative_derivative(first("points_received"),1s) as points_received_rate FROM "_kapacitor"."autogen"."ingress" WHERE time > :dashboardTime: GROUP BY "database", "retention_policy", "measurement", time(1m)) WHERE time > :dashboardTime: GROUP BY time(1m)

按任务划分的 Kapacitor 摄取量（点/秒）

SELECT non_negative_derivative("collected",1s) FROM "_kapacitor"."autogen"."edges" WHERE time > now() - 15m AND ("parent"='stream' OR "parent"='batch') GROUP BY task

TICKscript

批量处理工作正常，但流处理不正常。为什么？

确保端口 9092 对入站连接开放。流 PUSH 到端口 9092，因此必须允许其通过防火墙。

Kapacitor 可以处理的脚本数量是否有限制？

没有软件限制，但它将受到可用服务器资源的限制。

是什么导致具有相同时间戳的意外或额外值？

如果在不规则的时间间隔摄取数据，并且您看到具有相同时间戳的意外结果，请在 TICKscript 中摄取数据时使用 log node 来调试问题。这会浮出问题，例如，httpOut 隐藏的重复数据。

性能

运行一个复杂的脚本还是并行运行多个脚本，哪种性能更好？

从极端情况来看，最佳情况是一个任务消耗所有数据并完成所有工作，因为管理多个任务时会增加开销。但是，在减少每个任务的开销方面已经付出了巨大的努力。以对您的项目和组织有逻辑意义的方式使用任务。如果您在多个任务中遇到性能问题，请告知我们。作为最后的手段，将任务合并为更复杂的任务。

基于模板的脚本是否使用更少的资源，或者它们只是一个易于使用的工具？

模板只是一个易于使用的工具，在性能方面没有任何区别。

Kapacitor 如何处理高负载？

如果 Kapacitor 无法在接收新数据之前摄取和处理传入数据，则 Kapacitor 会将传入数据排队到内存中，并在能够处理时对其进行处理。排队数据的内存需求取决于摄取率和传入数据的形状。一旦 Kapacitor 能够处理所有排队的数据，它就会随着内部垃圾回收器回收内存而缓慢释放内存。

长时间的高数据摄取可能会使可用系统资源不堪重负，从而迫使操作系统停止 kapacitord 进程。避免此问题的主要方法是

• 确保您的硬件提供足够的系统资源来处理额外的负载。
• 优化您的 Kapacitor 任务。请参阅下文。

如何优化 Kapacitor 任务？

在优化 Kapacitor 任务时，请考虑以下事项

“批量处理”传入数据

batch 以批处理方式从 InfluxDB 查询数据。只要 Kapacitor 能够在查询下一个批处理之前处理一个批处理，它就不需要排队任何东西。

stream 将所有 InfluxDB 写入实时镜像到 Kapacitor，并且更容易排队。如果使用 stream，请使用 window 将传入数据分段为基于时间的批处理。