Kapacitor 作为连续查询引擎

Kapacitor 可用于执行与 InfluxDB 中的连续查询 (CQ) 相同的工作。今天，我们将探讨选择 Kapacitor 而非 InfluxDB CQ 的原因，以及 Kapacitor 用于 CQ 类型工作负载的基础知识。

一个示例

首先，让我们采用一个简单的 CQ 并将其重写为 Kapacitor TICKscript。

这是一个 CQ，它每 5 分钟计算一次 cpu.usage_idle 的平均值，并将其存储在新测量值 mean_cpu_idle 中。

CREATE CONTINUOUS QUERY cpu_idle_mean ON telegraf BEGIN SELECT mean("usage_idle") as usage_idle INTO mean_cpu_idle FROM cpu GROUP BY time(5m),* END

使用 Kapacitor 实现相同的功能，这里是一个流式 TICKscript。

dbrp "telegraf"."autogen"

stream
    |from()
        .database('telegraf')
        .measurement('cpu')
        .groupBy(*)
    |window()
        .period(5m)
        .every(5m)
        .align()
    |mean('usage_idle')
        .as('usage_idle')
    |influxDBOut()
        .database('telegraf')
        .retentionPolicy('autogen')
        .measurement('mean_cpu_idle')
        .precision('s')

在 Kapacitor 中，也可以将相同的事情作为批处理任务来完成。

dbrp "telegraf"."autogen"

batch
    |query('SELECT mean(usage_idle) as usage_idle FROM "telegraf"."autogen".cpu')
        .period(5m)
        .every(5m)
        .groupBy(*)
    |influxDBOut()
        .database('telegraf')
        .retentionPolicy('autogen')
        .measurement('mean_cpu_idle')
        .precision('s')

这三种方法都将产生相同的结果。

问题

此时，有几个问题需要我们回答：

1. 何时应使用 Kapacitor 而非 CQ？
2. 在 Kapacitor 中，何时应使用流式任务而非批处理任务？

何时应使用 Kapacitor 而非 CQ？

有几个原因可以让你选择 Kapacitor 而非 CQ。

• 你正在执行大量的 CQ，并且希望隔离工作负载。通过使用 Kapacitor 来执行聚合，InfluxDB 的性能配置文件可以保持更稳定，并与 Kapacitor 的保持隔离。
• 你需要做的事情不仅仅是执行查询，例如，你可能只想存储聚合中的异常值，而不是所有值。Kapacitor 可以比 CQ 对数据进行更多的处理，因此你在转换数据方面拥有更大的灵活性。

在某些用例中，使用 CQ 几乎总是明智的。

• 为保留策略执行降采样。这是 CQ 的设计目的，并且做得很好。如果你不需要，就没有必要在你的基础设施中增加另一个移动部件（即 Kapacitor）。保持简单。
• 你只有几个 CQ，同样，保持简单，除非你需要，否则不要在你的设置中添加更多的移动部件。

在 Kapacitor 中，何时应使用流式任务而非批处理任务？

基本上，答案归结为两点：可用内存和正在使用的时间段。

流式任务必须在指定的时间段内将所有数据保留在内存中。如果此时间段对于可用内存来说太长，那么你首先需要将数据存储在 InfluxDB 中，然后使用批处理任务进行查询。

流式任务确实有一个微小的优势，因为它可以监视数据流，它通过数据上的时间戳来理解时间。因此，不存在某个点是否会包含在窗口中的竞争条件。如果你使用的是批处理任务，那么一个点仍然可能晚到而错过一个窗口。

另一个示例

创建一个连续查询以跨保留策略进行降采样。

CREATE CONTINUOUS QUERY cpu_idle_median ON telegraf BEGIN SELECT median("usage_idle") as usage_idle INTO "telegraf"."sampled_5m"."median_cpu_idle" FROM "telegraf"."autogen"."cpu" GROUP BY time(5m),* END

流式 TICKscript

dbrp "telegraf"."autogen"

stream
    |from()
        .database('telegraf')
        .retentionPolicy('autogen')
        .measurement('cpu')
        .groupBy(*)
    |window()
        .period(5m)
        .every(5m)
        .align()
    |median('usage_idle')
        .as('usage_idle')
    |influxDBOut()
        .database('telegraf')
        .retentionPolicy('sampled_5m')
        .measurement('median_cpu_idle')
        .precision('s')

以及批处理 TICKscript

dbrp "telegraf"."autogen"

batch
    |query('SELECT median(usage_idle) as usage_idle FROM "telegraf"."autogen"."cpu"')
        .period(5m)
        .every(5m)
        .groupBy(*)
    |influxDBOut()
        .database('telegraf')
        .retentionPolicy('sampled_5m')
        .measurement('median_cpu_idle')
        .precision('s')

总结

Kapacitor 是一个强大的工具。如果你需要比 CQ 提供的更大的灵活性，请使用它。有关更多信息以及如何从 InfluxQL 查询编写 TICKscript，请参阅 Kapacitor 中的 InfluxQL 节点上的 文档。InfluxDB 查询语言中提供的所有函数都可以在 Kapacitor 中使用，因此你可以将任何查询转换为 Kapacitor TICKscript。

重要提示

连续查询和 Kapacitor 任务可能产生不同的结果

对于某些类型的查询，CQ (InfluxDB) 和 TICKscript (Kapacitor) 可能由于它们选择时间边界的方式不同而返回不同的结果。Kapacitor 选择最大时间戳 (tMax)，而 InfluxDB 选择最小时间戳 (tMin)。对于 InfluxDB 而言，tMax 或 tMin 的选择有些随意，但 Kapacitor 则不然。

Kapacitor 能够对重叠的时间窗口执行复杂的多表连接操作。例如，如果你要连接过去一个月的平均值和过去一天的平均值，你需要它们的返回值发生在同一时间，使用最近的时间 tMax。然而，Kapacitor 会使用 tMin，并且返回值不会发生在同一时间。一个将位于过去一个月初，而另一个将位于过去一天初。

考虑以下同时作为 InfluxQL 查询和 TICKscript 运行的查询：

InfluxQL

SELECT mean(*) FROM ... time >= '2017-03-13T17:50:00Z' AND time < '2017-03-13T17:51:00Z'

TICKscript

batch
  |query('SELECT queryDurationNs FROM "_internal".monitor.queryExecutor')
    .period(1m)
    .every(1m)
    .align()
  |mean('queryDurationNs')

查询结果

请注意返回时间戳之间的差异。

这是一个已知问题，在 Github 上的 Issue #1258 中有讨论。