核心要点
- 小型 ToB 环境如果机器数量不多，可以先用 Vector 直接采集日志并写入 Elasticsearch，降低日志链路复杂度。
- Vector 配置的核心是
sources、transforms和sinks：读取日志文件、解析结构化字段、输出到控制台和 Elasticsearch。 - 本文示例使用
remap解析夜莺日志中的时间戳、日志级别、代码位置和消息内容，并把结果写入按天分割的索引。 - 直接写 Elasticsearch 适合简单场景；如果后续日志量增大、需要缓冲削峰或多消费者分发，再考虑引入 Kafka 等中间层。
很多 ToB 的小环境，机器量不多，但是仍然希望日志被集中收集，此时不需要太复杂的架构，就直接使用 Vector 即可采集日志并直接发送到后端 ElasticSearch，本文来做一个演示备忘。
Vector 简介
Datadog 的 Vector 是一个开源的、高性能的日志聚合、度量指标和分布式跟踪系统。它旨在收集、聚合和分析来自不同来源的数据，以便开发者和运维团队可以更好地监控和理解他们的应用程序和服务的性能。
以下是 Vector 的一些关键特性和优势：
- 统一的数据收集器：Vector 可以作为一个统一的数据收集器，替代传统的日志收集工具如 Fluentd、Logstash 等，简化了日志和度量指标的收集过程。
- 高性能：Vector 针对性能进行了优化，可以高效地处理大量的日志和度量指标数据，同时保持低延迟。
- 灵活的管道：Vector 提供了灵活的管道系统，允许用户定义数据的处理、转换和路由规则，以满足不同的监控和分析需求。
- 可扩展性：Vector 支持水平扩展，可以通过增加更多的 Vector 实例来处理更多的数据。
- 易于集成：Vector 可以轻松集成到现有的监控和度量指标生态系统中，如 Prometheus、Grafana、Elasticsearch 等。
- 安全性：Vector 提供了安全特性，如 TLS 加密、身份验证等，确保数据传输的安全性。
- 开源：Vector 是一个开源项目，允许用户自由使用、修改和贡献代码。
- 丰富的插件：Vector 支持多种输入和输出插件，可以轻松地与各种数据源和目标系统集成。
在本文中，我们将演示如何使用 Vector 采集日志并直接发送到 ElasticSearch。采集的是夜莺的日志，会对日志多解析，把日志解析成一些结构化字段。
Vector 配置
Vector 的配置文件可以是 yaml 或 toml 格式，我这里采用的是 yaml 格式，下面是我的配置内容：
data_dir: "/Users/ulric/works/vector-test/data_dir"
api:
enabled: true
sources:
app_logs:
type: "file"
include:
- "/Users/ulric/works/gopath/src/nightingale/logs/*.log"
transforms:
parse_log:
type: "remap"
inputs:
- "app_logs"
source: |
. |= parse_regex!(.message, r'(?P<timestamp>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{6}) (?P<level>\w+) (?P<source_location>[^ ]+) (?P<message>.+)')
.timestamp = parse_timestamp(.timestamp, format: "%Y-%m-%d %H:%M:%S.6%f") ?? now()
.@timestamp = del(.timestamp)
sinks:
print:
type: "console"
inputs:
- "parse_log"
encoding:
codec: "json"
es:
type: "elasticsearch"
inputs:
- "parse_log"
endpoints:
- "http://192.168.10.30:9200"
batch:
max_events: 1000
timeout_secs: 5
buffer:
type: "disk"
max_size: 536870976
when_full: "block"
bulk:
index: "vector3-%Y.%m.%d"
上面的配置中，核心是包含了 sources、transforms 和 sinks 三个部分：
sources：定义了数据源，这里使用 file 类型的数据源，指定了要采集的日志文件路径。transforms：定义了数据转换规则，这里使用 remap 类型的转换器，对日志进行解析，并将解析后的字段存储到结构化字段中。sinks：定义了数据的输出目标，这里使用 console 类型的输出目标，将解析后的日志数据输出到控制台；同时使用 elasticsearch 类型的输出目标，将解析后的日志数据发送到 ElasticSearch。
| 配置段 | 本文配置 | 作用 |
|---|---|---|
sources.app_logs |
type: "file" |
读取夜莺日志文件 |
transforms.parse_log |
type: "remap" |
用正则解析日志并转换时间字段 |
sinks.print |
type: "console" |
调试时输出解析后的 JSON |
sinks.es |
type: "elasticsearch" |
批量写入 Elasticsearch 索引 |
其中最重要的是 transforms 部分，这里使用了 remap 类型的转换器，通过正则表达式解析日志中的时间戳、日志级别、日志来源和日志内容，并将解析后的字段存储到结构化字段中。这样，我们就可以在 ElasticSearch 中对日志数据进行更加灵活和高效的查询和分析。
下面是一条原始的夜莺的日志供参考：
2025-03-25 20:42:37.006681 INFO eval/eval.go:147 eval:alert-1-1 started
解析后的结构化字段如下：
{
"@timestamp": "2025-03-25T20:42:37.006681Z",
"level": "INFO",
"source_location": "eval/eval.go:147",
"message": "eval:alert-1-1 started"
}
当然了，Vector 采集日志的时候，还会附加一些额外的字段，比如 host、file 等，这些字段可以在 ElasticSearch 中用于更细致的查询和分析。
Sinks 部分配置了两个输出目标，一个是 console 输出到控制台，只是为了方便调试；另一个是 es 输出到 ElasticSearch，将解析后的日志数据发送到 ElasticSearch 中，其中 bulk.index 配置了索引的格式，这里使用了时间格式，每天一个索引。
适用场景和注意事项
这套方案适合日志量不大、链路希望保持简单、团队只需要集中查询和基础分析的环境。它的优点是组件少、配置直观、上线快。
需要注意的是，直接写 Elasticsearch 也意味着削峰、重放、多消费者分发能力有限。如果日志量持续增长，或者需要同时写入多个后端，就应重新评估是否引入 Kafka、对象存储或更完整的日志处理链路。
最终效果
我这里启动夜莺输出日志了，也不用 Kibana 看日志了，直接把 ElasticSearch 作为数据源配置到夜莺里，也可以在夜莺里查看日志。
FAQ
Q1：为什么示例同时配置 console 和 Elasticsearch 两个 sink？
console 主要用于调试，方便确认正则解析、字段类型和时间字段是否正确；Elasticsearch 才是最终查询分析的写入目标。
Q2：什么时候不建议直接从 Vector 写 Elasticsearch？
当日志量较大、写入峰值明显、需要多个下游消费或需要保留可重放队列时，直接写后端会比较脆弱，应考虑增加 Kafka 等缓冲和分发层。
Q3：结构化解析失败怎么办？
先用 console sink 观察原始输出和解析结果，检查日志格式是否变化、正则是否覆盖所有样本、时间格式是否匹配，再决定是否放宽解析规则或增加异常分支。
