Loki 3.6 配置不认识 block_builder，先核对旧组件依赖

Loki 从 3.5.8 升到 3.6.0 后，加载配置时报 field block_builder not found in type loki.ConfigWrapper。如果旧文件包含 block_builder，应先核对该版本的配置结构，再处理 YAML。日志里通用的环境变量展开提示，不会让一个已删除的字段重新有效。

Loki 3.6 移除了旧 block builder 和 scheduler 相关代码。旧版能解析的 block_builder.max_chunk_age 因而不能原样带入新版本。这里只能确认配置字段已删除，不能把换成另一个名字当作自动迁移，也不能承诺把 18000h 搬到某个 ingester 字段后含义完全相同。

先查看实际运行二进制或镜像的版本、所选 target，以及真正被挂载的配置文件。不要只看仓库中的 YAML；容器可能挂载了另一份旧文件，部署工具也可能合并出额外配置。将发生错误的文件另存到受控副本，用于修改与比较。

若部署已经不依赖旧 block builder，可从副本中移除整个不再支持的 block_builder 段，然后用计划部署的同一版本校验：

loki -version
loki -verify-config=true -config.file=/path/to/reviewed-loki.yaml

路径替换为受控配置副本，保留它原来需要的环境变量与安全挂载方式。校验成功表示配置可以被该二进制读取并通过相应检查，不等于日志已经摄取、索引和查询正常。更换配置后，仍需按既有发布流程观察组件启动、写入链路和查询结果。

若原部署的 Kafka 链路需要旧 block builder，移除字段可能让解析错误消失，却留下功能缺口。此时应先梳理部署目标、数据流、存储布局及新组件的配置要求，单独设计迁移。不要只为了启动成功删掉业务所依赖的组件，也不要把配置解析成功当作旧架构已经等价恢复。

对于不使用该旧组件的部署，验收可分两步：配置校验不再出现这个未知字段；正常发布后，新写入的测试日志能在预期时间范围被查询到，已有查询行为也符合要求。若后者失败，要继续查看实际写入与查询组件，不能再次把未知字段修复当作全链路结论。

没有确认的正式版本会恢复旧字段。当前处理是针对已移除配置的有限调整，适用于确认不再依赖旧组件的部署；其他未知字段错误也应按各自版本的配置结构判断。