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 输入插件将 Kapacitor 数据写入 InfluxDB 的示例查询

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 节点进行调试。这会暴露问题，例如，通过 httpOut 隐藏的重复数据。

性能

运行一个复杂的脚本可以获得更好的性能，还是并行运行多个脚本可以获得更好的性能？

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

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

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

Kapacitor 如何处理高负载？

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

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

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

如何优化 Kapacitor 任务？

在优化 Kapacitor 任务时，请考虑以下几点

“批量”传入数据

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

stream 实时镜像所有 InfluxDB 写入 Kapacitor 的操作，并且更容易导致排队。如果使用stream，请使用window将传入数据分割成基于时间的批次。