TrueNAS 监测：数据库焕新
丢掉臃肿的 Influx，迎接 AI 时代可观测性平台的基石——Victoria Metrics。原因很简单： 性能更佳，资源使用更少，查询语句更简洁（看着 SQL 我真的会当场宕机）。我还发现获取硬盘温度无需再依赖 TrueNAS 的报告导出接口了。好！
改造过程的关键点，是学习 PromQL（虽然 V Metrics 有自己的 MetricsQL，但这实际上是 PromQL 的超集）。很幸运的是，V Metrics 为 Grafana 提供了专用插件（貌似是借用了 Prometheus 接口），也有现成的面板模板可供参考。然后，基本上实现了对原有面板的复刻。
使用的查询语句
V Metrics 插件提供了直观的构建界面，一般无需手打查询语句，就算要手打，一行字也便解决了；但个别特殊情况除外。这里我举几个例子：
处理器使用率
根据文档，V Metrics 将一切监测项目以近乎“扁平化”的方式进行管理：原来泾渭分明的分类 measurements 和 field 被熨平了，每条指标都是一张大表下独立的一列；数据类型统一为 Float64；时间段的查询则整体转移到 HTTP 请求头上。于是，原来臃肿的 Flux 语句：
from(bucket: "${bucket}")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "cpu")
|> filter(fn: (r) => r["cpu"] == "cpu-total")
|> filter(fn: (r) => r["_field"] =~ /usage_(iowait|nice|softirq|system|user)/)
|> filter(fn: (r) => r["host"] == "${host}")
|> aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)
|> yield(name: "mean")变成了简简单单一句 PromQL：
{__name__=~"cpu_usage_(iowait|nice|softirq|system|user)",host="$hostname",cpu="cpu-total"}题外话，貌似 Flux 语句和 MongoDB 查询语言大同小异；本博客代码的高亮以 Prism.js 模块实现，该高亮的地方都高亮了。
ARC 命中率
该指标未被直接记录，需要从一定间隔内的“命中次数”和“未命中次数”两项记录计算出来。原来在 InfluxDB 整的那套极度冗杂，堪称灾难：
from(bucket: "${bucket}")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "zfs")
|> filter(fn: (r) => r["host"] == "${host}")
|> filter(fn: (r) => r["_field"] == "arcstats_hits" or r["_field"] == "arcstats_misses")
|> difference()
|> pivot(rowKey:["_time"], columnKey:["_field"], valueColumn:"_value")
|> map(fn: (r) => ({
_time: r._time,
_measurement: r._measurement,
_field: "hit_rate",
_value: float(v: r.arcstats_hits) / (float(v: r.arcstats_hits) + float(v: r.arcstats_misses))
}))
|> aggregateWindow(every: v.windowPeriod, fn: last, createEmpty: false)在 V Metrics 这边，三下五除二解决了：
WITH (
hits = rate(zfs_arcstats_hits{host="$hostname"}[$__interval]),
misses = rate(zfs_arcstats_misses{host="$hostname"}[$__interval])
)
hits / (hits + misses)记录精度和准确性
基本和 InfluxDB 相同。但个别方面存在区别：
| V Metrics | InfluxDB | |
|---|---|---|
| 硬盘存取用时（I/O Time） | 最低精度 0.8 ms | 精度可达亚微秒级 |
| 网络吞吐（Network Transfer） | 记录值接近于实际 | 同单位下，记录值偏大 |
性能和资源占用
这方面而言，资深 DevOps 冯若航写的文章更有说服力，负载比我这小不点儿大了好几个数量级。但与此同时，他采用的平台算力也是我家服务器的成百上千倍，其结论不一定能套用到这里来。我在 2 月 3 日切换到 V Metrics，所以到撰稿为止还没有长期观察的条件，但短期收益依然立竿见影：
| V Metrics | InfluxDB | |
|---|---|---|
| Grafana 面板刷新速度 | 有少许延迟 | 有明显延迟，半秒以上 |
| Grafana 显示前后，服务端处理器使用率 | 4%→5%，曲线平滑 | 4%→7%，呈锯齿状波动 |
| 存储使用量 | 8 日存储量：约 88 MB | 90 日存储量：约 2 GB |
| 日均存储需求 | 11 MB/天 | 22.75 MB/天 |
非常厉害，不愧是苏联地区斯拉夫人的杰作。
设置、面板等相关资源
感谢你看到这里，奖励来了！Docker Compose 配置、Telegraf 配置、Grafana 面板配置一网打尽！