TICKscript 语言简介
概述
Kapacitor 使用名为 TICKscript 的特定领域语言 (DSL) 来定义任务，这些任务涉及数据的提取、转换和加载，以及数据中任意变化的跟踪和事件的检测。一个常见的任务是定义警报。TICKscript 在 .tick 文件中用于定义处理数据的管道。TICKscript 语言旨在将节点中定义的数据处理操作的调用链接在一起。Kapacitor 入门指南 在该产品的上下文中介绍了 TICKscript 基础知识。为了更好地理解后续内容，建议读者首先阅读该文档。
每个脚本都有一个扁平的作用域，作用域中的每个变量都可以引用字面值，例如字符串、整数或浮点值，或者可以调用方法的节点实例。
这些方法有两种形式。
- 属性方法 – 属性方法修改节点的内部属性，并返回对同一节点的引用。属性方法使用点号 (“.”) 表示法调用。
- 链式方法 – 链式方法创建一个新的子节点，并返回对其的引用。链式方法使用管道 (“|”) 表示法调用。
节点
在 TICKscript 中，基本类型是节点。节点具有属性以及如上所述的链式方法。可以使用父节点或同级节点的链式方法从父节点或同级节点创建新节点。对于每种节点类型，此方法的签名都相同，而与父节点或同级节点类型无关。链式方法可以接受零个或多个参数，用于初始化新节点实例的内部属性。常见的节点类型有 batch、query、stream、from、eval 和 alert，但还有数十种其他类型。
顶层节点（用于建立要定义的任务的处理类型）stream 和 batch 只是简单地声明，不带任何参数。具有更复杂属性集的节点依赖于属性方法来进行内部配置。
每种节点类型都想要批处理或流模式的数据。有些可以同时处理两者。每种节点类型也以批处理或流模式提供数据。有些可以同时提供两者。这种想要/提供模式是理解节点如何协同工作的关键。考虑到想要/提供模式，可以定义四种通用节点用例
- 想要批处理并提供流 - 例如，当计算平均值或最小值或最大值时。
- 想要批处理并提供批处理 - 例如，当识别一批数据中的异常值时。
- 想要流并提供批处理 - 例如，当将相似的数据点分组在一起时。
- 想要流并提供流 - 例如，当将数学函数（如对数）应用于点中的值时。
节点参考文档 列出了每个节点的属性和链式方法，以及示例和描述。
管道
每个 TICKscript 都被分解为一个或多个管道。管道是节点的链，逻辑上沿着无法循环回到链中较早节点的边组织。管道中的节点可以分配给变量。这允许使用例如 join 或 union 节点来组合不同管道的结果。它还允许将管道的各个部分分解为合理可理解的自描述功能单元。在简单的 TICKscript 中，可能不需要将管道节点分配给变量。管道中的初始节点设置它们定义的 Kapacitor 任务的处理类型。这些可以是 stream 或 batch。这两种类型的管道不能组合。
流式处理还是批处理？
使用 stream 处理，数据点像经典数据流一样，在到达时逐点读取。使用 stream，Kapacitor 订阅 InfluxDB 中所有感兴趣的写入操作。使用 batch 处理，从数据库中读取“历史”数据帧，然后进行处理。使用 stream 处理，可以在写入 InfluxDB 之前转换数据。使用 batch 处理，数据应已存储在 InfluxDB 中。处理后，也可以将其写回。
使用哪种方法取决于系统资源和正在进行的计算类型。当处理大量数据且时间范围较长时，首选 batch。它将数据存储在磁盘上，直到需要时才使用，但查询在触发时会导致数据库突然高负载。使用 stream 处理大量数据且时间范围较长意味着不必要地将可能数十亿个数据点保存在内存中。当处理较小的时间范围时，首选 stream。它降低了 InfluxDB 的查询负载。
管道作为图
Kapacitor 中的管道是有向无环图 (DAG)。这意味着每条边都有一个数据流动的方向，并且管道中不能有任何循环。边也可以被认为是父节点和其子节点之间存在的数据流关系。
任何管道的开始都将声明两个基本边之一。第一个边建立任务的处理类型，但是，每个后续节点都建立自身与其子节点之间的边类型。
stream→from()– 一次传输单个数据点的边。batch→query()– 一次传输数据块而不是一个点的边。
管道有效性
当连接节点然后创建新的 Kapacitor 任务时，Kapacitor 将检查 TICKscript 语法是否格式良好，以及新边是否适用于最近的节点。但是，管道的全部功能将在运行时才进行验证，届时错误消息可能会出现在 Kapacitor 日志中。
示例 1 – 运行时错误
...
[cpu_alert:alert4] 2017/10/24 14:42:59 E! error evaluating expression for level CRITICAL: left reference value "usage_idle" is missing value
[cpu_alert:alert4] 2017/10/24 14:42:59 E! error evaluating expression for level CRITICAL: left reference value "usage_idle" is missing value
...
示例 1 显示了一个运行时错误，该错误是由于管道中缺少字段值而引发的。这通常发生在 eval 节点之后，当未设置 eval 节点的属性 keep() 时。通常，Kapacitor 无法预测任务在运行时将遇到的所有数据模式。某些任务可能未编写为处理与规范的所有偏差或异常，例如当字段或标签丢失时。在这些情况下，Kapacitor 将记录错误。
基本示例
示例 2 – 基本的 stream → from() 管道
dbrp "telegraf"."autogen"
stream
|from()
.measurement('cpu')
|httpOut('dump')
示例 2 中的简单脚本可用于创建具有默认 Telegraf 数据库的任务。
$ kapacitor define sf_task -tick sf.tick
任务 sf_task 将简单地将最新的 cpu 数据点缓存为 JSON 到 HTTP REST 端点（例如 http://localhost:9092/kapacitor/v1/tasks/sf_task/dump）。
此示例包含数据库和保留策略语句：dbrp。
此示例还包含三个节点
- 基本
stream节点。 - 必需的
from()节点，用于定义数据点流。 - 处理节点
httpOut()，它将接收到的数据缓存到 Kapacitor 的 REST 服务。
它包含两条边。
stream→from()– 设置任务的处理类型和数据流。from()→httpOut()– 将数据流传递到 HTTP 输出处理节点。
它包含一个属性方法，即对 from() 节点的调用 .measurement('cpu')，用于定义要用于进一步处理的指标。
示例 3 – 基本的 batch → query() 管道
batch
|query('SELECT * FROM "telegraf"."autogen".cpu WHERE time > now() - 10s')
.period(10s)
.every(10s)
|httpOut('dump')
示例 3 中的脚本可用于定义具有默认 Telegraf 数据库的任务。
$ kapacitor define bq_task -tick bq.tick -dbrp "telegraf"."autogen"
当用于使用默认 Telegraf 数据库创建 bq_task 时，示例 3 中的 TICKscript 将简单地将表示最近 10 秒活动的批处理指标的最后一个 cpu 数据点缓存到 HTTP REST 端点（例如 http://localhost:9092/kapacitor/v1/tasks/bq_task/dump）。
此示例包含三个节点
- 基本
batch节点。 - 必需的
query()节点，用于定义数据集。 - 处理节点
httpOut()，用于定义处理数据集的一个步骤。在这种情况下，它是将其发布到 Kapacitor 的 REST 服务。
它包含两条边。
batch→query()– 设置处理样式和数据集。query()→httpOut()– 将数据集传递到 HTTP 输出处理节点。
它包含两个属性方法，这些方法从 query() 节点调用。
period()– 设置批处理数据将覆盖的时间段。every()– 设置将处理批处理数据的频率。
下一步？
有关使用 TICKscript 的基本示例，请参阅 GitHub 上代码库中的最新示例。
有关 TICKscript 中级到高级用例的解决方案，请参阅 指南 文档。
下一节介绍 TICKscript 语法 的更多详细信息。 继续…
此页是否对您有帮助？
感谢您的反馈！