在现代可观测性领域，采集器收集到的原始数据往往需要裁剪或重组，才能形成我们关注的关键数据，并根据内容分发到不同的存储系统。这样的处理不仅让数据更加结构化，便于查询，还能减少无关数据对存储资源的占用。
为了解决这一需求，Vector 提供了 Transforms 功能，并配套了功能强大的 VRL（Vector Remap Languag），允许用户自定义数据处理逻辑，以灵活应对各种数据处理场景。
VRL 是一种面向表达式的语言，旨在以安全、高效的方式转换可观测性数据（Logs 和 Metrics）。它具有简单的语法和丰富的内置函数集，专为可观测性用例量身定制。
在上周发布的 《实战 Vector：开源日志和指标采集工具》一文中，我们已经介绍了 Vector 中的各个基本概念，并且初步的使用了简单的 Transform 来处理了 nginx 日志。Vector Transform 提供了 aggregate，dedupe，filter，remap 等方法。本章我们详细介绍 Transform 中的 remap 功能。
![]()
(图 1 ：Remap 在整个 Pipeline 中的位置和作用）
TL;DR
Remap 是通过编写 VRL 语言来定制 Transform 的逻辑，首先我们看一个简单的例子：
[sources.demo_source]
type = "demo_logs"
format = "apache_common"
lines = [ "line1" ]
[transforms.transform_apache_common_log]
type = "remap"
inputs = [ "demo_source" ]
drop_on_error = true
drop_on_abort = true
reroute_dropped = true
source = """
log = parse_apache_log!(.message,format: "common")
if to_int(log.status) > 300 {
abort
}
. = log
.mark = "transform_apache_common_log"
"""
[sinks.transform_apache_common_log_sink]
type = "console"
inputs = [ "transform_apache_common_log" ]
encoding.codec = "json"
[sinks.demo_source_sink]
type = "console"
inputs = [ "demo_source" ]
encoding.codec = "json"
[transforms.transform_apache_common_log_dropped]
type = "remap"
inputs = [ "transform_apache_common_log.dropped" ]
source = """
.mark = "dropped"
"""
[sinks.dropped_msg_sink]
type = "console"
inputs = [ "transform_apache_common_log_dropped" ]
encoding.codec = "json"
然后使用此配置文件启动 Vector ，可以看到在标准输出里出现了三种类型的 JSON，我们会结合这三种类型的的 JSON 来描述 VRL 代码的逻辑。
VRL 基本介绍
通过上述的例子我们对 transform 有了一个简单直观的认识，在上述配置中的 16 行到 19 行，我们主要定义了名为 transform_apache_common_log 的 Transform。
以下我们详细描述一下这个 Transform 到底做了什么。Transform 的定义的基本格式这里不再赘述，我们重点介绍 source 的字段中 VRL 的内容。
上述例子中 source 中的 VRL 可以分为三个部分：
1. 解析
log = parse_apache_log!(.message, format: "common")
同大部分编程语言的赋值语句类型。这一句是把等号右边表达式产生的结果赋值给 log 变量。等号右边整体的意思是按照 Apach Common 的格式解析原 event 中的 message 字段转化为更结构化的键值对结构。
我们再细化一点。这里是调用了一个内置函数 parse_apache_log 他接收两个参数：
-
.message
-
format: "common"
这里的 .message 是对当前 event 取 message 字段的操作。当前 event 的格式如下：
{
"host": "localhost",
"message": "218.169.11.238 - KarimMove [25/Nov/2024:04:21:15 +0000] \"GET /wp-admin HTTP/1.0\" 410 36844",
"service": "vector",
"source_type": "demo_logs",
"timestamp": "2024-11-25T04:21:15.135802380Z"
}
可我们观察到除了 message 字段还包含了一些 host source_type 等元信息。apache log 格式除了 common 还有 combined 格式，这里的第二个参数表示用 common 的格式来解析传入的日志内容。
除此之外，我们还会观察到 parse_apache_log 后有一个 ! 。这个感叹号并不是类似 Rust 中宏的标记，而是代表了一种错误处理逻辑。我们会在后面的 VRL 错误处理小结进行详述。
如果解析成功，Log 将会被赋值为结构化的 Apach Common 格式的数据，可以看到本来单一的字符串内容变成了结构化的键值对，后续可以很方便的进行过滤和聚合等操作。
{
"host": "67.210.39.57",
"message": "DELETE /user/booperbot124 HTTP/1.1",
"method": "DELETE",
"path": "/user/booperbot124",
"protocol": "HTTP/1.1",
"size": 14865,
"status": 300,
"timestamp": "2024-11-26T06:24:17Z",
"user": "meln1ks"
}
2. 过滤 & 错误处理
既然 Log 已经是结构化的数据了，我们就可以用更精细的方式来过滤或者裁剪我们关心的数据。假设我们对 status 大于 300 的数据不关心，那就可以设置 log.status > 300 时中断此 transform （这里的谓词可以换成任意你想要的逻辑）。
if to_int(log.status) > 300 {
abort
}
默认逻辑下，如果触发 abort， 当前事件会原封不动地传入下一个处理单元，因为我们不关心这些数据所以我们决定丢掉这部分数据。
可使用如下配置：
drop_on_error = true
drop_on_abort = true
但是，如果有一些我们本来没考虑到的情况，导致了 vrl 执行错误（类型错误，解析错误等），这样我们可能本来所关心的数据就被丢失了，这会造成一些信息上的缺失。为了解决这个问题。我们可以使用 reroute_dropped = true 配置来把 drop 的 event 增加 metadata 后统一分发到一个 <current_transform_id>.dropped 的 input 里（上述例子中的 transform_apache_common_log.dropped）。
{
"host": "localhost",
"mark": "dropped",
"message": "8.132.254.222 - benefritz [25/Nov/2024:07:56:35 +0000] \"POST /controller/setup HTTP/1.1\" 550 36311",
"metadata": {
"dropped": {
"component_id": "transform_apache_common_log",
"component_kind": "transform",
"component_type": "remap",
"message": "aborted",
"reason": "abort"
}
},
"service": "vector",
"source_type": "demo_logs",
"timestamp": "2024-11-25T07:56:35.126819716Z"
}
我们只要关注这个 input 就可以了解哪些数据被我们 drop 了，视情况可以修改 vrl 把那些丢失的数据也利用起来。
3. 替换
. = log
.mark = "transform_apache_common_log"
上述配置中，第一行等号左边的「.」，在 VRL 中表示 VRL 正在处理的当前 event。等号右边的则是之前解析出来的结构化 Log 结果，将会替换掉当前的 event。
第二行表示在已经替换成结构化日志的当前 event 增加一个 mark 字段来标记当前 event 来自 transform_apache_common_log transform。
最终我们得到了如下数据格式的数据，此数据格式的数据会取代原数据格式被下游接收:
{
"host": "67.210.39.57",
"mark": "transform_apache_common_log",
"message": "DELETE /user/booperbot124 HTTP/1.1",
"method": "DELETE",
"path": "/user/booperbot124",
"protocol": "HTTP/1.1",
"size": 14865,
"status": 300,
"timestamp": "2024-11-26T06:24:17Z",
"user": "meln1ks"
}
VRL 错误处理
在上文调用 parse_apache_log 时，我们在其后增加了一个 !，这是 VRL 中的一种错误处理方式。由于 Event 中包含的字段类型多种多样，为了保证其灵活性，许多函数在逻辑处理或数据类型不符合预期时可能会返回错误。因此，需要引入错误处理机制来应对这些情况。
parse_apache_log 其实是返回了两个结果，一个是函数正常返回结果，另一个则是一个错误信息类似于：
result, err = parse_apache_log(log,format:"common")
当 err 不等于 null 时表示函数执行发送了错误。在 VRL 中，在函数名称后面增加 ! 算是一种语法糖，表示当遇到错误时立即中断当前 VRL 片段提前返回错误。
类似如下代码：
result, err = parse_apache_log(log,format:"common")
if err != null {
panic
}
假如你的 message 是多种格式的数据混合在一起，使用 ! 来提前中断解析逻辑就显得不是那么合理了。假设我们的 Event 字段可能是 JSON、Apache Common 格式中的一种，我们可能就需要如下的配置来使日志结构化的输出：
structured, err = parse_json(.message)
if err != null {
log("Unable to parse JSON: " + err, level: "error")
. = parse_apache_log!(.message,format: "common")
} else {
. = structured
}
我们不能在 parse_json 失败的时候就直接终止 transform，需要再尝试按照 apache common 格式解析后再视解析结果而定。
总结
Vector 的 Transform 功能内置了功能强大的 VRL 语言，支持自定义数据处理逻辑。通过 Remap，我们可以对原始数据进行解析、过滤、替换等操作。同时，VRL 提供了完善的错误处理机制，能够确保 Transform 的稳定性，避免因某些数据异常导致任务失败或数据丢失。此外，VRL 拥有丰富的函数库，可以轻松处理大多数常见数据格式，不仅提升了开发效率，还让数据处理更加灵活高效。
更多详情可参考 VRL 的官网文档。
关于 Greptime
Greptime 格睿科技专注于为可观测、物联网及车联网等领域提供实时、高效的数据存储和分析服务，帮助客户挖掘数据的深层价值。目前基于云原生的时序数据库 GreptimeDB 已经衍生出多款适合不同用户的解决方案，更多信息或 demo 展示请联系下方小助手（微信号：greptime）。
欢迎对开源感兴趣的朋友们参与贡献和讨论，从带有 good first issue 标签的 issue 开始你的开源之旅吧～期待在开源社群里遇见你！添加小助手微信即可加入“技术交流群”与志同道合的朋友们面对面交流哦~
Star us on GitHub Now: https://github.com/GreptimeTeam/greptimedb
官网：https://greptime.cn/
文档：https://docs.greptime.cn/
Twitter: https://twitter.com/Greptime
Slack: https://greptime.com/slack
LinkedIn: https://www.linkedin.com/company/greptime/
