前些天群里有朋友问ES 7.x 集群也起来了节点也加进集群了怎么磁盘还是三天两头报警我一听就猜到八成是少了最关键的运维配置索引模板和生命周期策略。集群起得来只是及格线真正让 Elasticsearch 能长期稳定跑下去的是“新索引一落地就有统一 settings 和 mappings”“超出保留周期的数据能自己滚走消失”。这篇就把这两个东西讲透。这篇是集群搭建系列的第二篇默认你已经有一批 7.x 节点知道_cat/health、_cat/nodes这些基本命令。全文围绕三件事展开索引模板怎么设计、ILM 生命周期策略怎么配置、模板和策略怎么联动落地。适合刚把集群搭起来、每天被“映射错乱”“分片爆炸”“磁盘写满”折磨的运维开发同学。1. 为什么集群跑起来之后要先补上模板和 ILM 这层配置很多人第一次搭 ES 集群时注意力全放在节点通信、分片分配、内存参数上。等集群真的开始接业务数据问题马上就不一样了今天用接口建一个索引明天另一个程序用另一个 client 版本又建一个索引。索引多了之后有的 3 个分片有的 5 个分片有的副本 2 份有的副本 0 份。最要命的是 mapping一开始是 keyword后面来了个数字就自动映射成 long再来个 IP 又变成 ip时间一长同一个字段在不同索引里类型都不一样查询的时候经常莫名其妙报错。这就是没有索引模板的后果。1.1 没模板的集群新索引全靠“缘分”索引模板就像流水线上的工装夹具。零件来了夹具先固定好位置后面加工才不会歪。ES 里也一样模板通过在index_patterns里定义通配符把所有匹配的新索引统一约束起来。没有模板时ES 7.x 默认给一个新索引配置 1 个主分片、1 个副本分片refresh interval 默认 1 秒codec 默认压缩。这些默认值在小数据量下没问题但业务一起来就露馅日志场景写入量大refresh 太频繁会白白吃 CPU检索场景分片数太少吞吐上不去冷数据场景压缩不够磁盘成本直线上升。这些都得在模板里提前定好让集群替你自动做而不是等索引建完再手动_settings去改。1.2 ILM 不是定时删除而是一个状态机生命周期策略ILM经常被误解成“定时删除索引”实际上它是让索引按照 hot、warm、cold、delete 等阶段逐步迁移的一套状态机。数据刚写入时它在 hot 阶段承担读写压力几天后不再更新了可以进 warm 阶段做 force merge、缩分片、调整副本再过一阵子可以进 cold 阶段把副本降为 0甚至放到搜索快照里最后到了保留期限delete 阶段直接把它清理掉。每个阶段都有min_age表示索引在这个阶段至少待多久。到了时间执行配置的 action。ILM 不是起一个 crontab 去固定时间删数据而是根据索引的“年龄”和当前状态一步一步往下推。理解这一点之后你再看_ilm/explain的输出就很直观当前阶段、当前 action、当前 step、卡在哪一步全都能查得到。1.3 模板和 ILM 是什么关系从工程角度说模板负责索引“出生”时的配置ILM 负责索引“一生”的节奏。模板把index.lifecycle.name写死在 settings 里新索引一创建自动绑定对应策略。这样就不用写一堆脚本去循环处理存量索引。两者联动之后你只需要维护两份配置一份是模板规范所有新索引一份是策略决定老索引什么时候优化、什么时候删除。后面所有索引生命周期管理都可以交给 ES 自己跑运维只需要盯监控、查异常。2. 索引模板管理把新索引默认行为一次焊死模板这东西刚开始接触会觉得不就是一个 JSON 嘛往PUT _index_template/xxx一扔完事。但真正写起来就会发现settings、mappings、aliases 之间的关系以及优先级怎么排都是坑。先看一个最常用的模板示例。2.1 模板里面能管哪些东西模板主要管三块settings分片数、副本数、刷新间隔、压缩方式、ILM 策略名。mappings字段类型、分词器、是否允许动态新增字段。aliases索引创建时自动绑定哪些别名。下面是给一个业务日志项目用的模板索引名都以sre-logs-开头PUT _index_template/sre-logs-template { index_patterns: [ sre-logs-* ], priority: 200, template: { settings: { number_of_shards: 3, number_of_replicas: 1, refresh_interval: 30s, index.codec: best_compression, index.lifecycle.name: sre-log-lifecycle }, mappings: { dynamic: false, properties: { timestamp: { type: date, format: epoch_millis||strict_date_optional_time }, level: { type: keyword }, message: { type: text, fields: { keyword: { type: keyword, ignore_above: 512 } } }, service: { type: keyword } } } } }解释一下我为什么这么写。number_of_shards设成 3不是越大越好。分片越多写入并行度高一点但每个分片也要消耗资源集群节点少时反而让 shard 分布很碎。日志类数据 3 个主分片够用后续如果吞吐不够再根据压测加。refresh_interval设成 30 秒是因为日志场景不需要秒级可见。ES 默认 1 秒刷新一次每次刷新都会生成新的 segment频繁刷新纯属浪费。搜索实时性要求很高的业务再考虑调回 1 秒。index.codec设成best_compression会比默认压缩率更好代价是写入时 CPU 略高。日志场景一般能接受换来的是磁盘空间更省。dynamic: false是我强烈建议的一项。允许动态 mapping 会让字段类型跟着数据跑今天一个status是 int明天同一个字段传了字符串可能就 mapping 冲突。设置成 false 后未声明字段不会被索引但文档写入不会直接失败设置成 strict 会更严格未声明字段直接报错。具体选哪个看业务能不能容忍字段丢失。能容忍就 false不能容忍就先在模板里把字段补全再用 strict。2.2 模板优先级和 component template 怎么配合7.8 之后的 ES 推荐使用 composable index template也就是用_index_template接口管理模板并且可以组合多个 component template。同一个索引可能同时匹配多个模板ES 会按priority排序数值大的优先。比如先建一个匹配所有sre-*的通用模板priority 设 100再建一个匹配sre-logs-*的专有模板priority 设 200。当创建sre-logs-2024.07.01时两个模板都会生效但相同配置项以 priority 高的为准。如果公司内部有多个业务线用 component template 会更省心PUT _component_template/sre-base-settings { template: { settings: { number_of_shards: 3, number_of_replicas: 1, refresh_interval: 30s } } }PUT _component_template/sre-log-mappings { template: { mappings: { dynamic: false, properties: { timestamp: { type: date }, message: { type: text } } } } }PUT _index_template/sre-log-template { index_patterns: [ sre-logs-* ], composed_of: [ sre-base-settings, sre-log-mappings ], priority: 200 }这样做的价值在于公共配置只维护一份各个索引模式只需要通过composed_of组合自己需要的组件。模板之间如果出现字段冲突也靠 priority 解决不用每个模板都写一大坨。2.3 创建完模板怎么快速验证模板建完不是看一眼返回acknowledged: true就完事了。我会做一个快速验证先创建一个测试索引看它实际生效的 settings 和 mappings再删掉。PUT /sre-logs-test-000001什么都没写就是空请求走的就是模板匹配。然后查GET /sre-logs-test-000001/_settings/index.lifecycle.name,index.number_of_shards,index.refresh_interval GET /sre-logs-test-000001/_mapping确认index.lifecycle.name自动带上了策略名主分片是 3refresh 是 30 秒mapping 里只有模板中声明的字段。没问题之后删掉这个测试索引DELETE /sre-logs-test-000001这个习惯能帮你隔离很多问题。如果测试索引不对先查模板有没有保存成功再查是不是有更高优先级的模板把配置覆盖了不用去线上索引上“开盲盒”。注意模板只对新创建、且索引名匹配index_patterns的索引生效。已经存在的旧索引不会因为模板更新而自动应用新配置。存量索引要么用_settings手动改要么就得等它滚动到下一个新索引。3. ILM 生命周期策略怎么设计才不至于惹祸ILM 策略本身不复杂真正难的是阶段划分和动作选择。很多人一上来就把 hot、warm、cold、delete 四个阶段全配上结果 rollover 没触发索引全卡在 hot磁盘照样报警。3.1 先别整五个阶段先想清楚业务数据要活多久设计策略前先回答三个问题数据最长保留多久数据还有没有高频更新需不需要把冷数据留在集群里供查询如果只是日志场景数据只写不更新保留 30 天那不需要搞得太复杂。hot 阶段负责写入和短期查询warm 阶段做一次 force merge 和副本调整delete 阶段直接清理。如果连查询需求都几乎没有那连 warm 阶段都可以不要hot 之后直接 delete省力又省心。下面是一个常见的日志生命周期策略PUT _ilm/policy/sre-log-lifecycle { policy: { phases: { hot: { min_age: 0ms, actions: { rollover: { max_size: 50gb, max_age: 7d, max_docs: 200000000 }, set_priority: 100 } }, warm: { min_age: 3d, actions: { forcemerge: { max_num_segments: 1 }, allocate: { number_of_replicas: 1 }, set_priority: 50 } }, delete: { min_age: 30d, actions: { delete: {} } } } } }这里有几个细节容易被忽略。hot阶段的min_age建议写0ms因为新索引一创建就应该进入 hot 阶段。如果 hot 阶段写了 7d那写入索引在 7 天内可能根本不会被 rollover等条件满足时磁盘可能已经扛不住了。rollover的max_size、max_age、max_docs是“或”的关系。只要满足其中一个条件就会触发滚动。不要理解成三个都要满足。warm阶段里forcemerge会把索引合并成尽量少的 segment查询会快很多。代价是会占用大量 IO建议在业务低峰期让它自动跑不要在高峰期手动触发。allocate里的number_of_replicas可以配合你的节点角色比如把副本调整到 0 或者 1主要看你对高可用的要求。3.2 rollover 是 ILM 里最容易出错的点rollover 是整个 ILM 里我最想强调的部分。它的原理是数据写入一个别名别名指向当前正在写的索引当索引满足条件后ES 创建下一个索引把写别名切换到新索引旧索引继续往后面的阶段走。rollover 有一个硬前置条件必须有写别名并且别名在索引上设置了is_write_index: true。举个例子初始索引叫sre-logs-000001写别名叫sre-logs-write。建索引时直接带上别名PUT /sre-logs-000001 { settings: { number_of_shards: 3, number_of_replicas: 1, index.lifecycle.name: sre-log-lifecycle }, aliases: { sre-logs-write: { is_write_index: true } } }这里不建议把sre-logs-write这个别名写在索引模板的aliases里。因为模板会对所有匹配的新索引都尝试建立这个别名多个索引都有同一个别名很容易出现冲突。更稳妥的做法是模板只管 settings 和 mappings写别名由初始索引创建时手动绑定。写入端统一写sre-logs-write这个别名不用关心底层真实索引名。当sre-logs-000001满足 rollover 条件后ILM 自动创建sre-logs-000002并把写别名指过去。业务端全程无感。很多人会问索引名到底用日期还是用-000001这种序号。我的建议是如果你依赖 rollover尽量用-000001这种递增序列。因为 rollover 在生成新索引名时有一套自己的递增规则如果你用日期命名新索引名很容易变得不直观后面脚本 grep 的时候会很痛苦。3.3 策略定义好了怎么观察执行进度策略配置完之后不要直接等。先手动触发一次 rollout或者至少看一次_ilm/explainGET /sre-logs-000001/_ilm/explain?pretty这个接口会返回索引当前处于哪个 phase、哪个 action、哪个 step还会告诉你age和step_info。比如phase 是hot说明还在写阶段action 是rollover说明正在等待满足条件如果 phase 是hot但 action 一直停在complete说明条件还没达到如果 phase 是error那就是卡住了必须看step_info里的报错原因。还可以用下面这条命令看所有匹配索引的状态GET /_ilm/explain/sre-logs-*通过这个接口你能很清楚地看到哪些索引在等什么哪些索引报错了比翻日志高效得多。4. 模板 ILM 联动落地一份可复用的操作流配置类的东西最怕“想到哪写到哪”。我建议你把模板和策略当成线上变更来管理顺序固定每一步都验证。4.1 推荐顺序和完整示例我的落地顺序是先建策略再建模板然后建初始索引最后验证。第一步创建 ILM 策略。上面的sre-log-lifecycle就是。第二步创建索引模板模板里带上index.lifecycle.namePUT _index_template/sre-logs-template { index_patterns: [ sre-logs-* ], priority: 200, template: { settings: { number_of_shards: 3, number_of_replicas: 1, refresh_interval: 30s, index.codec: best_compression, index.lifecycle.name: sre-log-lifecycle }, mappings: { dynamic: false, properties: { timestamp: { type: date, format: epoch_millis||strict_date_optional_time }, level: { type: keyword }, message: { type: text, fields: { keyword: { type: keyword, ignore_above: 512 } } } } } } }第三步创建初始索引并绑定写别名PUT /sre-logs-000001 { aliases: { sre-logs-write: { is_write_index: true } } }这时候sre-logs-000001会命中模板自动配置好分片、刷新间隔、生命周期策略。别名再单独绑上去。第四步验证。先看索引是否自动应用了策略GET /sre-logs-000001/_ilm/explain再强制触发一次 rollover确认系统能滚出下一个索引POST /sre-logs-write/_rollover?pretty如果条件不满足POST会返回rolled_over: false并告诉你每个条件的情况。这正好用来检查你的配置是否符合预期。4.2 多租户、多索引模式怎么扩展业务一多就不能只用一个模板和一个策略。比如接入方 A 的日志可能只保留 15 天接入方 B 的日志要保留 90 天。这时候可以把策略拆开sre-logs-short-lifecycle15 天删除sre-logs-long-lifecycle90 天删除sre-metrics-lifecycle指标数据保留更久且分片数、主键、时间字段都不一样模板也拆开PUT _index_template/sre-logs-long-template { index_patterns: [ sre-logs-*, sre-app-* ], priority: 150, template: { settings: { number_of_shards: 3, number_of_replicas: 1, index.lifecycle.name: sre-log-lifecycle } } }多个模板同时匹配时还是靠priority控制。公共组件放在低 priority 的模板里业务专项配置放在高 priority 的模板里。这里最忌讳的是每个业务线都自己复制一份完整模板后面改公共配置时到处漏改。4.3 配合节点角色做冷热数据分层如果集群规模到了二三十个节点可以考虑把节点分成热节点和温节点通过节点 attribute 区分。在模板的 settings 里可以加分配规则settings: { index.routing.allocation.include.data: hot }意思是让新索引优先分配到带有data: hot属性的节点上。等索引进入 warm 阶段后ILM 里配置allocate动作把它迁移到data: warm的节点。warm: { min_age: 3d, actions: { allocate: { number_of_replicas: 1, include: { data: warm } } } }这样做的好处很明显热节点用 SSD扛住写入和近期查询温节点用普通机械盘或对象存储存老数据。成本能省下来一大截查询性能也不会被老数据拖垮。注意分配规则不是想当然就能生效的节点角色必须提前在 elasticsearch.yml 里设置好节点 attribute并且确认集群里确实有对应节点不然分配动作会一直处于 pending。5. 实战中踩过的坑和排查速查表配置这东西纸上谈兵看着都合理真上了生产就各种意外。我把这几个高频坑单独拎出来讲。5.1 策略没生效先看 _ilm/explain 而不是日志我见过最典型的问题是模板建好了策略建好了初始索引也建好了但是第二天一查所有索引都停在hot阶段磁盘还剩一堆空间却一直不 rollover。这时候第一反应别去翻节点日志而是直接GET /sre-logs-000001/_ilm/explain?pretty大概率能看到两种情况一是索引根本没有绑定策略。如果policy字段是空的说明创建索引时模板里的index.lifecycle.name没生效。检查模板是否匹配了索引名或者索引是不是在模板创建之前就建好了。二是索引绑定了策略但action停在rollover。这说明写别名配得不对或者 rollover 条件还没达到。ES 不会主动帮你造一个写别名如果初始索引上没有is_write_index: true它就一直认为没有可滚动的对象。如果phase已经是error说明某个 action 执行失败。比如forcemerge报错、allocate找不到对应节点、或者shrink因为主分片数量不够而失败。处理方式是先看step_info里的错误信息改配置或者调整数据然后POST /sre-logs-000001/_ilm/retry?pretty让 ILM 从当前步骤重试。不要直接删索引也不要手动去改 ILM 的操作状态很容易把状态机搞乱。5.2 模板命中了但是 mappings 和你预期完全不一样模板冲突是另一个高频问题。假设你建了一个匹配sre-*的通用模板又建了一个匹配sre-logs-*的专项模板这两个模板的 properties 有同名但类型不同的字段结果新创建的日志索引用的却是通用模板的 mapping。这时候要查模板优先级GET /_index_template/sre-*看看哪个模板的priority更高以及composed_of组合了哪些 component template。ES 合成最终配置时priority 高的覆盖 priority 低的。如果你的通用模板 priority 是 300专项模板 priority 是 200那专项模板里的字段类型就会被通用模板覆盖。还有一种情况是多个 component template 里都定义了同一个字段。component template 之间冲突时_index_template能查出来但它不报错只是按优先级处理。建议所有 component template 的字段命名空间别重叠公共 settings 和业务 mappings 分开。5.3 易错点速查表症状可能原因处理方式新索引没有应用 ILM 策略索引在模板创建前已存在或模板index.lifecycle.name写错确认模板优先级存量索引手动_settings索引一直停在 hot/rollover没有写别名或写别名is_write_index不是 true给当前写索引加sre-logs-write别名索引进入 errorforcemerge/shrink/allocate 等动作报错看step_info改配置后_ilm/retrymapping 自动加了奇怪字段模板没写 dynamic或 dynamic 为 true将模板dynamic设为 false 或 strict磁盘快满但 delete 不触发delete 的 min_age 还没到或索引一直卡在前面阶段看_ilm/explain确认 age 是否满足同一字段类型在不同索引里不一致多个模板 conflictpriority 没控制好逐个查模板合成结果调整 priority6. 给长期运维的几个小建议模板和策略不是配置完就不用管的它们会随着业务变化不断演进。最后分享几个我自己的运维习惯。6.1 把模板和策略纳入版本管理我会把所有 ILM 策略和索引模板存成 JSON 文件放在代码仓库里。线上要做任何变更都走“改文件提交再执行”的流程。执行之前GET /_index_template/sre-* GET /_ilm/policy/*先确认当前线上配置长什么样再和本地的 diff 对比。别嫌多这一步很多时候模板被覆盖就是因为有人直接把新的 JSON 怼上去根本没看原来的配置。6.2 写代码的入口用 alias所有业务写入端统一使用写别名而不是具体索引名。这样做的好处是rollover 之后业务不需要知道新索引叫什么底层索引随便滚动你的代码一行都不用改。查询端也尽量通过别名或通配符查询比如GET sre-logs-*/_search避免写死索引名。6.3 定期做一次“瘦身演练”不要等磁盘告警才去看 ILM 是否正常工作。我会在每月例行维护时直接把一个测试索引的 rollover 条件调小手动触发一次确认整个链路是通的。这个动作十分钟都不到但能让真正的磁盘告警来得晚很多。我个人在实际操作中最深的体会是ES 集群出故障很多时候不是节点不够稳而是索引管理太随意。索引模板和 ILM 属于越早定好越省心的部分。尤其是你如果已经因为磁盘报警凌晨爬起来清过索引就会明白把规则交给集群自己执行比什么都重要。