日志索引写到第三天开始报 Limit of total fields [1000] has been exceeded。查 _mapping 发现 labels 下面每个 JSON key 都成为一个字段，一共 3800 个。日志里能对上时间点，这种反而好排。
默认 dynamic 是 true，遇到新 key 就自动建字段。日志标签是高基数的，key 又不受控，字段数按天线性涨。字段一多集群状态变大，每次更新 mapping 都要推给所有节点。这一点先确认清楚，后面就不用反复试。
PUT logs_v2
{"mappings": {"dynamic": "strict",
"properties": {"labels": {"type": "flattened"}}}}
「mapping 字段爆炸」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
处理上按这个顺序：把 labels 这类字段改成 flattened 整块当一个字段存；模板里把 dynamic 设成 strict 拦住意外字段；已经炸掉的索引新建模板重建 不要原地改；观察 mapping 总大小和 cluster state 更新耗时。
结果对不对很好判断，新索引字段数稳定在 60 个以内，写入一周不再出现字段上限报错。