Kapacitor 常见问题

本页面解决与Kapacitor相关的常见疑惑或重要事项。 在适用的情况下，它链接到Github上的突出问题。

管理

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

TICK脚本

• 批处理有效但流处理无效。为什么？
• 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 node 来调试问题。这会显现出例如被 httpOut 隐藏的重复数据等问题。

性能

运行一个复杂脚本的性能更好，还是同时运行多个脚本的性能更好？

将事情推向极限，最佳情况是一个任务消耗所有数据并完成所有工作，因为在管理多个任务时会增加额外的开销。 然而，已经投入了大量的精力来减少每个任务的开销。 以对您的项目和组织逻辑上合理的方式使用任务。 如果您在多个任务中遇到性能问题，请告诉我们. 作为最后手段，将任务合并为更复杂的任务。

基于模板的脚本是使用更少的资源还是仅仅是一个易用的工具？

模板只是一个便捷工具，不会对性能产生任何影响。

Kapacitor 如何处理高负载？

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

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

• 确保您的硬件提供足够的系统资源以应对额外的负载。
• 优化你的Kapacitor任务。 见下文.

我如何优化Kapacitor任务？

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

“批量”传入数据

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

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