欢迎访问我的个人小站 莹的网络日志 ,不定时更新文章和技术博客~
目前为止,我查询服务器日志的方式都是小作坊式做法,先是连进服务器找到日志文件,要么使用 vim 打开文件搜索要么就是用 grep。当前我只有一个服务器进程,操作起来还好,但是如果需要增加服务器进程数量进行负载均衡的话就非常麻烦,急需一个日志采集系统在统一的地方集中管理和查找日志。恰好公司最近将日志采集从 elk 切换到了 victoria-logs,我也稍微有些好奇当前的日志生态大致是怎样的。
victoria-logs
事实上,提到日志采集系统或者说框架,我第一个想到的就是 elk,也是目前这个领域应用最为广泛的,elastic 负责数据存储和搜索,logstash 负责日志数据采集,kibana 负责图形化展示。之前使用的时候觉得真是超级好用,然而缺点就是太重了,这方面是我无法接受的,还记得前段时间研究搜索引擎时,刚用 docker 启动 elastic search 就占用了 1GB 内存,直接惊掉下巴,这根本不是我租的那个蝇量级服务器能够承担的。
用不了 elk 只能退而求其次,首先分析一下我的需求,其实就是需要一个集中统一管理日志的地方,方便查日志,如此一来 kibana 所代表的角色就可有可无了,或者用服务器目前已经部署的 grafana 代替。日志数据采集是必须的,总要有一个搬运工将程序日志收集到数据库中,但并不复杂,毕竟我的服务器程序非常简单,打印的日志也都是固定格式,开发个日志采集也不怎么费事。那么重担就落在寻找 elastic 的替代品身上了。
在一番搜索过后,摘选出了两个比较信得过的技术栈 victoria-logs 和 loki,victoria-logs 是因为公司项目本身就在用,借机熟悉一下不是坏事,loki 则是有 grafana 背书,我还是比较信任 grafana 的。
bash
docker run -d \
--name=loki \
--network monitoring \
-p 3100:3100 \
grafana/loki:latest \
-config.file=/etc/loki/local-config.yaml
bash
docker run -d \
--name victoria-logs \
--network monitoring \
-p 9428:9428 \
-v /srv/data/victoria-logs:/victoria-logs-data \
victoriametrics/victoria-logs:latest \
-storageDataPath=/victoria-logs-data \
-retentionPeriod=30d
bash
docker stats
text
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
b9635e741ba7 victoria-logs 0.05% 5.469MiB / 7.654GiB 0.07% 872B / 126B 0B / 0B 9
af17f30b01a4 loki 1.38% 61.79MiB / 7.654GiB 0.79% 1.3kB / 126B 0B / 0B 13
稍微对比了下 docker 镜像启动后空档运行的资源占用,看来是 victoria-logs 小胜一筹。就没对比满负荷的资源占用了,毕竟现在网站日访问量都不知道能不能到三位数,很难说会有服务器满载的情况,总之降本增效不一定增效,但一定降本了~
在 VictoriaLogs 文档 中也介绍了 victoria-logs 自身的一些优点和特色,还有一些从 elastic 和 loki 迁移过来的用户的分享,虽然 Github VictoriaMetrics/VictoriaLogs 的 Star 数量仅有几百个,有点惨不忍睹。不过我这个也不是企业级项目,够用就行,如果后面业务量增加的话再切换成 elk。
vector
日志采集的技术方案选择相对就很随意了,选择了比较流行的 vector,同样使用 docker 部署,需要注意其中两个地方需要容器挂载,一个是宿主机的日志目录,对应的是服务器程序输出文件的位置,一个是配置文件。
bash
docker run -d \
--name vector \
--network monitoring \
-v /etc/vector/vector.yaml:/etc/vector/vector.yaml:ro \
-v /var/log/blog:/var/log/blog:ro \
timberio/vector:nightly-alpine \
--config /etc/vector/vector.yaml
配置文件可以用 toml 也可以用 yaml,或者是 json,本来我问 ChatGPT 给出的示例都是 toml 的,也打算用 toml,但是后面看文档中大部分示例都是用的 yaml,本着方便 copy 的原则我这里也选用了 yaml 格式的配置,虽然实际上都差不多。文档参考:Vector quickstart。
bash
vim /etc/vector/vector.yaml
配置整体分三块,而且是非常标准的上中下,第一块 sources 是数据输入,比如我的需求是监听文件更新,所以类型选择 type。第二块 transforms 是数据处理,比如做一些简单的转换。第三块 sinks 是数据输出,这里我需要把处理好的数据发送到 victoria-logs 中去。方便的是 victoria-logs 本身就兼容 elasticsearch 的 api,已有的技术栈可以无痛迁移,具体参考VictoriaLogs / Data Ingestion / Vector Setup。
yaml
sources:
blog_server_logs:
type: "file"
include:
- "/var/log/blog/*.log"
read_from: "beginning"
transforms:
blog_server_json_logs:
type: remap
inputs:
- blog_server_logs
source: |
._msg = .message
.message = parse_json(.message) ?? {}
.level = .message.level
.timestamp = .message.ts
sinks:
victorialogs:
inputs:
- "blog_server_json_logs"
type: elasticsearch
endpoints:
- http://victoria-logs:9428/insert/elasticsearch/
compression: gzip
healthcheck:
enabled: false
query:
_msg_field: message
_time_field: timestamp
_stream_fields: host,container_name
vector 打印采集到的数据
遇到服务一部署就行正常运行,如果不是经验丰富,那一定是幸运女神的眷顾。而我这次就没这么幸运了,那边服务器日志正常增加,这边 victoria-logs 却是什么数据都没有,查看 vector 的日志只有监听文件成功的日志打印,看起来一切正常,真让人摸不着头脑。
text
2025-09-28T14:59:15.296799Z INFO source{component_kind="source" component_id=blog_server_logs component_type=file}:file_server: vector::internal_events::file::source: Found new file to watch. file=/var/log/blog/blog_backend.log
所幸 vector 还提供了更多的输出方式,比如打印日志,将配置表添加如下字段,类型选择 console。
yaml
sinks:
print:
inputs:
- "blog_server_logs"
type: "console"
encoding:
codec: "json"
如果成功就会在 vector 的日志中看到打印的内容
bash
docker logs vector --tail 50
可惜的是我依旧没有看到打印,悬着的心终于死了。经过一番摸索,终于拨开云雾见天明,发现是在多次重试的过程中删除过日志文件,但是 vector 保存了上次收集日志的位置,可能是防止重启或者什么特殊情况导致重复消费。而我在调试的过程中,有过重启服务器和删除日志的操作,但是 vector 检查点不重置,新生成的日志小于检查点的位置,vector 会认为所有日志都消费过了,直到新日志超过检查点。解决办法就是删除镜像重新运行 vector,或者更换一下日志文件的位置。
zap 日志输出格式
最初的最初,我的想法是只要收集到日志就好了,不做处理直接存起来后面查,但事与愿违一下就遇到了拦路虎, victoria-logs 解析 json 失败,报错信息如下。
2025-09-28T07:38:48.422Z warn VictoriaLogs/app/vlinsert/jsonline/jsonline.go:54 remoteAddr: "172.18.0.6:50528"; requestURI: /insert/jsonline; cannot process jsonline request; error: unexpected tail: "T15:38:46+08:00 \x1b[34mINFO\x1b[0m Vodka inte...\": 200, \"body_size\": 2658, \"latency\": 4}"; line contents: "2025-09-28T15:38:46+08:00 \x1b[34mINFO\x1b[0m Vodka internal Request {\"method\": \"GET\", \"path\": \"/metrics\", \"client_ip\": \"172.18.0.2\", \"proto\": \"HTTP/1.1\", \"status\": 200, \"body_size\": 2658, \"latency\": 4}"
这要追溯到 golang 的 zap 日志打印库,我的设置是打印 level 时前后加上固定的转义字符比如 \x1b[34mINFO\x1b[0m
,让 INFO 或者 ERROR 在控制台中显示蓝色和红色,然而这个转义字符给 json 解析造成了很大麻烦。
解决方法之一是在 vector 的数据处理部分添加大量逻辑替换或者复杂正则匹配,方法二则是更改服务器日志打印参数,开发环境便于肉眼观察可以打印颜色,但是生产环境就要规规矩矩只输出常规字符。这里我参考了Get started with ECS Logging Go (Zap)。
go
// 带有转义色彩控制字符
config := zapcore.EncoderConfig{
EncodeLevel: zapcore.CapitalColorLevelEncoder,
// ...
}
// 以便于查日志的控制台格式输出
encoder = zapcore.NewConsoleEncoder(encoderConfig)
// 不带转义色彩控制字符
config := zapcore.EncoderConfig{
EncodeLevel: zapcore.LowercaseLevelEncoder,
// ...
}
// 以 json 的格式输出
encoder = zapcore.NewJSONEncoder(encoderConfig)
- 原本的格式
text
2025-10-01T00:43:56+08:00 ^[[31mERROR^[[0m serv.go:86 failed to initialize database, got error Error 1045 (28000): Access denied for user 'nobody'@'localhost' (using password: YES)
- 更改后的格式
text
{"level":"error","ts":1759252206.642765,"caller":"serv.go:86","msg":"failed to initialize database, got error Error 1045 (28000): Access denied for user 'nobody'@'localhost' (using password: YES)"}
最好还是采用 zap 官方设置,比如 NewDevelopmentConfig 和 NewProductionConfig,如果需要的话再在这个基础上修改某些字段的值。
vector remap language
好了,现在日志输出非常规范了,vector 直接可以解析,但是仍需要一些处理,把 json 文本解析成字段方便后面 victoria-logs 统计和显示,如果是自定义格式的日志,就要使用正则匹配,这时候就需要 vrl 了,可以查看官方文档Vector Remap Language (VRL),其中有一些范例可以参考。
bash
docker logs vector --tail 50
使用 zap 打印日志比如:
go
fields := []zap.Field{
zap.String("method", c.Request.Method),
zap.String("path", c.Request.URL.Path),
zap.String("client_ip", c.ClientIP()),
zap.String("proto", c.Request.Proto),
}
logger.Error("Vodka Internal Server Error", fields...)
输出的日志格式是:
json
{"level":"info","ts":1759286696.6425128,"msg":"Vodka internal Request","method":"GET","path":"/metrics","client_ip":"172.18.0.2","proto":"HTTP/1.1","status":200,"body_size":2544,"latency":2}
编写如下 vrl:
yaml
transforms:
blog_server_json_logs:
type: remap
inputs:
- blog_server_logs
source: |
._msg = .message
.message = parse_json(.message) ?? {}
.level = .message.level
得到的 vector 处理后的数据:
json
{"_msg":"{\"level\":\"info\",\"ts\":1759288966.6411865,\"msg\":\"Vodka internal Request\",\"method\":\"GET\",\"path\":\"/metrics\",\"client_ip\":\"172.18.0.2\",\"proto\":\"HTTP/1.1\",\"status\":200,\"body_size\":2264,\"latency\":1}","file":"/var/log/blog/blog_backend.log","host":"f33342bfbf69","level":"info","message":{"body_size":2264,"client_ip":"172.18.0.2","latency":1,"level":"info","method":"GET","msg":"Vodka internal Request","path":"/metrics","proto":"HTTP/1.1","status":200,"ts":1759288966.6411865},"source_type":"file","timestamp":"2025-10-01T03:22:47.353385037Z"}
victoria-logs 和 grafana
victoria-logs 本身有一个网页的界面,视觉上蛮舒服的。
grafana 没有内置 victoria-logs,需要额外下载插件,然后添加 datasource,不需要太多配置,只需设置下 victoria-logs 的地址,效果如下。
Elastic+Logstash+Kibana 技术栈可以简称成 ELK,那么 VictoriaLogs+Vector+Grafana 可不可以称作 VVG,不过听起来却是没有 ELK 好听。