生产环境单节点 OpenSearch 的 Dashboards 对所有用户返回 401：按 _id 排序分页留下的 12.3 GiB fielddata 占着没有上限的缓存，几个跨月聚合又把堆推过了 parent 断路器上限。文中整理了时间线、原因和防护建议。

按峰值每秒 6 万到 7 万条、每天约 2.4 TB 主分片数据推算日志集群：Kafka 缓冲、节点角色分离、写入调优和 data stream 滚动；热数据在 14 台本地 NVMe 节点上保留 7 天，快照在 S3 保留约 30 天。

三个非生产环境 14 天共 47.5 GB 的日志里，一个接口的完整响应体估算占了约 23 GB。按文件后缀、字段抽样、mapping 开销和查询模式四步找出空间去向，并估算源头截断、zstd、去掉长文本 .keyword 和不存位置信息各能省多少。

开发环境的单节点 OpenSearch 查出六个问题：自报 98% 的内存使用率把 Page Cache 算成了已用，1 GiB 多的堆页被换出到 swap，PA 的 agent 没有运行，缺少基础设施告警，默认副本让集群一直 yellow，服务日志写了两份。

开发环境单节点只存 47.5 GB 日志，OpenSearch 却平均占 0.88 核。大头是 ISM 每 5 分钟对 1,388 个索引加锁放锁，锁索引两天多才 flush，软删除攒到 185 万条；在线调参后预计降到 0.2～0.25 核。

Spring Boot 3.4+ 内建了 ECS 结构化日志支持，5 行配置能替掉大部分手写的 logback-spring.xml，再用 SLF4J Fluent API 把字段写成 OpenSearch 查得到、聚得起来的样子。