Loki 4.0 进 RC：Go 模块路径换成 /v4，V2 查询引擎拔掉，BoltDB shipper 正式退场

Loki 4.0 从 11 月 5 日开始出 RC，两天里连发三个。我读它的破坏性变更清单时，脑子里只有一个想法：这次是真的要把旧账一次结了。

最容易被忽略、也最容易咬人的一条

模块路径改成了 github.com/grafana/loki/v4。

看起来只是 import 变了，但它意味着：所有直接依赖 Loki 包的下游项目（包括自定义的客户端、operator 封装、内部 fork）都要改 import 路径，不然升级时会拿到两份模块、两份类型，报错信息还特别难懂。

如果你只是部署二进制的用户，这条与你无关。如果你维护过任何 import 了 Loki 内部包的代码，现在就该去看。

被拔掉的东西

这一版的破坏性变更不是微调，是删功能：

移除	说明
V2 查询引擎	从配置与模块里彻底摘掉
BoltDB shipper 相关后端	索引与 chunk 的老后端一起退场
/api/prom 端点	老 API 面关闭
SSD（Simple Scalable Deployment）targets	部署形态收敛
variants() 实验查询	LogQL 实验语法删除
row_shards、disable_broad_index_queries 等配置	schema 里的历史残留

这些删除其实是一个信号：「兼容很久」的代价终于付不动了。 一个日志系统要背着的兼容层越多，查询路径就越绕，性能越难优化。4.0 选择把老路砍掉，换来的是干净的执行路径。

会立刻影响你账单的一条

S3 存储类别被限制在 STANDARD 与 STANDARD_IA。

如果你的 bucket 用了 INTELLIGENT_TIERING 或者 Glacier 之类的类别，升级后 Loki 会拒绝。这条不是「可能会坏」，是「一定会坏」—— 而且坏在写入路径上，日志一断你会发现得很快，但那天你大概正在处理别的事。

升级前先跑一遍：aws s3api list-objects-v2 看对象的 StorageClass，或者直接查 bucket 的生命周期规则。

默认值变了的地方

• 前端编码默认切成 protobuf（带宽更省，但如果你有自定义的查询前端，需要确认它能解）
• 存储客户端默认用 Thanos 的那一套
• Ruler 启动时无条件清空 remote-write WAL（以前是「看情况」，现在是「一定」）
• loki_log_flushes 指标改名

我的升级顺序

日志系统和监控系统一样，最怕「升级完才发现历史数据读不出来」。所以顺序我会这么排：

1. 先把迁移文档读完，把 limits_config 里被删的键全部找出来（Loki 对未知配置键的处理是启动即失败，这点反而是好事）
2. 在隔离环境用一份旧版本写的 chunk 与索引跑一次查询 —— 这才是真正的兼容性测试
3. 检查 S3 存储类别与生命周期规则
4. 先升读取路径（querier），再升写入路径（distributor / ingester）
5. 最后升 ruler，并接受它清 WAL 的事实

要不要现在上

RC 阶段不建议上生产。但如果你是「今年必须升级」的那批人，现在正是把迁移清单跑一遍的最好时机 —— RC 阶段的问题报上去，比正式版发出来之后报有用得多。

顺带说一句我自己的感受：这类「大版本删功能」的发布，看着吓人，实际往往比那些「加了十个新特性」的版本安全。删掉的东西不会再出 bug。