Kapacitor 作为持续查询引擎

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 中使用流式任务而不是批处理任务？

基本上，答案归结为两件事：可用的 RAM 和使用的时间段。

流式任务将必须将所有数据保留在 RAM 中指定的期限内。如果此期限对于可用的 RAM 来说太长，那么您首先需要将数据存储在 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 中讨论过。