1. 配置全景ES启动前先搞清这四类文件先同步一个概念很多人一说“ES配置文件”就只盯着elasticsearch.yml其实一个生产环境可用的 ES 实例至少要同时处理好四类文件。缺了哪一个轻则启动报错重则集群跑着跑着把数据搞丢。我按优先级给你排个序配置文件作用范围优先级jvm.options控制 ES 进程的 JVM 参数堆内存、GC、JVM 调优最高启动时最先被读取elasticsearch.ymlES 核心功能配置集群、节点、网络、存储、安全等核心几乎所有业务配置都在这里log4j2.properties日志输出格式、滚动策略、日志级别运维排查时高频修改role_mapping.yml/users_roles/elasticsearch-users安全认证相关角色映射仅在开启安全特性时需要一般解决方案或者教程里讲的“配置 ES”九成时间都在折腾elasticsearch.yml但如果你直接照抄网上的 demo 配置就上生产大概率会踩到堆内存和文件描述符的坑。所以这篇文章我会把四类文件的每一项配置都拆开讲重点放在elasticsearch.yml和jvm.options上顺带提醒几个日志和安全的常见误区。2. elasticsearch.yml 核心配置逐项解读2.1 集群与节点命名不许随便起名字cluster.name: es-production node.name: node-01 node.roles: [master, data, ingest]cluster.name是集群的唯一标识同一个集群的所有节点必须完全一致。这个字段没有默认的“自动生成”逻辑不写的话 ES 会用默认值但你后面要加节点、维护集群状态、排查脑裂问题的时候一堆默认名字的节点会让你痛不欲生。node.name建议用「机房角色编号」的命名法比如cn-north-master-01。我用过纯数字编号的集群后来扩了十几个节点后光靠 IP 根本对不上日志里的节点名排查问题效率极低。node.roles是 ES 7.x 之后引入的角色划分机制。这里最容易犯的错是什么单节点测试环境不指定 roles没问题但多节点集群里如果不显式声明ES 会默认让每个节点同时承担 master、data、ingest 全角色。小规模集群无所谓一旦规模超过 15~20 个节点这种“全角色”配置会带来无谓的 master 选举竞争和 data 节点间的分片迁移压力。实操建议3 节点以下的集群可以用默认全角色5 节点以上建议明确拆出 3 个 master 候选节点和若干 data 节点。2.2 路径配置ES 迈不过去的三个目录path.data: /data/elasticsearch/data path.logs: /data/elasticsearch/logs path.repo: /backup/elasticsearchpath.data索引数据、分片数据、translog 的存放位置。生产环境必须放在独立的高性能磁盘上SSD 优先千万别和系统盘混在一起。原因是 ES 的写入链路对磁盘 IOPS 极其敏感系统日志频繁读写会拖垮索引性能。path.logsES 自身日志目录排错时第一眼要看的地方。path.repo快照仓库路径做备份恢复时用。注意这里只是“注册”位置真正的快照数据会写在里面对应的仓库子目录里。我有一次排障发现某节点的磁盘 IO 居高不下排查了半天发现是path.data和 swap 分区在同一块机械盘上索引吞吐率直接掉了 70%。这类问题用iostat和iotop就能定位但最好的办法是开局就分开。2.3 网络与通信配置network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: [node-01:9300, node-02:9300, node-03:9300] cluster.initial_master_nodes: [node-01, node-02, node-03]network.host是 ES 节点监听的地址。测试环境可以设127.0.0.1生产环境一般写0.0.0.0表示监听所有网卡但这样会有暴露风险必须配合防火墙或者安全认证使用。如果你只想让内网访问也可以写成具体的内网 IP。http.port是 REST API 端口默认9200一般不用动transport.port是节点间内部通信端口默认9300。这两个端口名字容易混淆我见过有人防火墙只开了 9200结果节点间一直无法通信集群总是 yellow排查了很久才发现 9300 被挡了。discovery.seed_hosts是节点发现列表。ES 启动时通过这些地址找到其他节点进而完成集群组建。注意这里写的是 transport 端口9300不是 http 端口9200。写错端口是新手高频错误之一。cluster.initial_master_nodes只在集群第一次初始化时有用列出的是具备 master 资格的节点名。集群建立起来之后这个配置就失去作用了但你不能随便删掉它因为如果所有节点同时重启没有这个配置会导致集群无法在启动时主动选举进入一种“谁也说服不了谁”的状态。2.4 集群脑裂防护配置discovery.zen.minimum_master_nodes: 2这是 ES 7.x 之前防脑裂最关键的参数在 7.x 之后被新的集群协调机制淘汰了。新版本里不需要手动设置这个值系统会自动根据 master 候选节点数量计算最少需要多少个节点参与选举。但这里要强调一个底层原则避免脑裂的核心是保证只有“大多数”节点能选举出 master。ES 7.x 之后的新机制用了类似 Raft 的算法要求一个 master 必须获得超过半数的选票才能当选。所以你在设计集群时master 候选节点数量必须是奇数比如 3 个或 5 个。如果设置 2 个当其中一个宕机时剩下一个无论如何都无法达到“超过半数”至少需要 2 票集群就完全瘫痪如果只设 1 个脑裂风险极高。实操经验3 个 master 候选节点允许挂 1 个5 个 master 候选节点允许挂 2 个。这个配比是性价比和可用性的最佳折中点。2.5 堆内存以外的内存管理设置bootstrap.memory_lock: true这个参数很多人容易忽略但它对生产环境的稳定性格外重要。bootstrap.memory_lock: true的作用是锁定 ES 进程占用的内存禁止系统把它 swap 到磁盘上。ES 是内存敏感型应用如果内存被 swapGC 停顿时间会剧烈上升请求延迟直接从毫秒级变成秒级而且毫无规律。你会在监控上看到极其诡异的毛刺CPU 不高、堆内存也没满但查询就是慢。开启这个选项需要操作系统的配合具体做法后面章节我会把常见报错和排查写出来。这里先说结论生产环境一律开启测试环境如果内存不足可以先关掉。2.6 数据可靠性设置gateway.recover_after_nodes: 3 gateway.expected_nodes: 5 gateway.recover_after_time: 5mgateway这一组配置控制的是集群全量重启后数据恢复的时机。ES 在集群刚启动时不会立刻开始恢复分片而是等待满足条件后才动手。recover_after_nodes至少多少个节点加入后开始恢复expected_nodes期望的节点总数recover_after_time如果节点数始终达不到期望值最多等 5 分钟后也强行开始恢复这里有一个很重要的设计逻辑如果不设置等待时间集群每次启动时只要有节点就立刻开始大规模分片恢复会把磁盘 IO 和网络打满。设置等待时间后等大部分节点都上线了再一次性恢复速度反而更快、更平缓。经验值参考recover_after_nodes设为主数据节点数量的一半以上expected_nodes设为集群总节点数。计算方式可以记为「N/21」原则有点类似脑裂防护的“过半数”思路。2.7 索引分片恢复并发度cluster.routing.allocation.node_concurrent_recoveries: 3 cluster.routing.allocation.node_concurrent_incoming_recoveries: 3 cluster.routing.allocation.node_concurrent_outgoing_recoveries: 3这几个参数控制分片恢复时的并发数。默认值是 2对于机械盘可能刚好合适但如果你用的是 SSD可以适当调大到 3~5。注意不要贪心并发调太高会导致 IO 过载反而把恢复速度拖慢。我调过最成功的一次是从 2 调到 4恢复时间缩短了 40%磁盘 IO 依然有余量。但如果机器上同时还有其他服务跑着建议保守一点保持默认。2.8 安全认证配置xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/certs/transport.p12 xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/certs/transport.p12ES 的安全功能属于 X-Pack基础版免费提供。如果是 8.x 版本安全功能默认开启如果是 7.x 版本默认关闭需要手动打开。这里最容易被坑的地方是xpack.security.enabled和transport.ssl必须同时考虑。仅开启安全认证不启用 TLS 加密密码在集群内网传输时是明文安全性形同虚设。而开启 TLS 又涉及到证书的生成和分发三个节点的集群三个节点都要把证书放到相同路径。如果你不想在生产环境折腾证书最低限度也要保证xpack.security.enabled: true 内网隔离但这只是权宜之计不推荐作为长期方案。2.9 跨域配置http.cors.enabled: true http.cors.allow-origin: * http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE http.cors.allow-headers: X-Requested-With, Content-Type, Content-Length这个配置主要是给 Kibana、Cerebro 等可视化工具用的。如果不开跨域浏览器端的请求会被跨域策略拦截你会在控制台里看到一片红。但注意http.cors.allow-origin: *在生产环境是风险隐患等于允许任意来源的浏览器请求访问节点。如果 ES 节点暴露在公网绝对不能用*要写成具体的 Kibana 域名或前端应用域名。我的习惯是只允许 Kibana 所在服务器的地址其他一律拒绝。2.10 其他高频但容易被忽视的配置项action.destructive_requires_name: true indices.query.bool.max_clause_count: 2048action.destructive_requires_name是用来防止误删索引的。把它设为true后执行DELETE *或者DELETE _all这类通配符删除操作就会被拒绝。我在测试环境吃过大亏本想清空一个测试索引手滑执行了DELETE *整个集群的索引全部被删了。从此之后在任何环境我都默认开这个参数。indices.query.bool.max_clause_count是查询时 bool 子句数量的上限默认值是 1024。如果你的业务里有复杂的多条件组合查询很容易打满这个限制导致报错。调太高也不好会带来严重的 CPU 和内存开销。建议按实际业务压测后取一个折中值一般 2048 够用。3. jvm.options 堆内存与 GC 配置实战3.1 堆内存设置的“黄金规则”-Xms4g -Xmx4gES 官方明确建议-Xms和-Xmx必须设置为相同值。为什么因为如果不一致JVM 在运行过程中会动态调整堆大小这个调整过程会触发 Full GC导致响应时间出现难以预测的尖刺。设为相同值后JVM 启动时就完全分配好堆空间运行时避免堆扩容带来的性能损耗。堆内存最大值建议设为物理内存的 50%且不要超过 30GB。很多人不理解“为什么不能给 JVM 分配 50GB”。原因有两层第一层ES 最底层用的是 LuceneLucene 本身非常依赖操作系统的文件缓存它并不把索引数据全部放进 JVM 堆里而是用mmap的方式把文件映射到堆外内存通过 OS page cache 加速访问。你给 ES 堆内存分得越多留给系统文件缓存的就越少索引读写反而变慢。第二层JVM 对象指针压缩技术的限制。当堆内存小于 32GB 时JVM 可以启用「普通对象指针压缩」compressed oops能显著节省对象头占用的内存一旦超过 32GB指针压缩失效对象头变大实际的可用内存反而可能比 30GB 时更少。这是 Elastic 官方在博客里明确验证过的结论上限 30GB 不是玄学是 JVM 底层机制的硬限制。3.2 典型堆内存配置方案物理内存推荐堆内存预留系统内存16GB8GB8GB32GB16GB16GB64GB28-30GB34GB128GB30GB98GB物理内存 64GB 时推荐堆内存上限 30GB不能超过。预留的 34GB 中一部分给 Lucene 文件缓存一部分给操作系统本身和各种进程的 overhead。从我多次压测的经验看16GB 内存的机器给 8GB 堆对于中小规模的日志检索场景已经够用但如果你的写入并发很高或者索引特别多8GB 堆会频繁触发 GC这时候优先考虑加机器而不是调大堆内存。3.3 GC 策略的选择与调优-XX:UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction75 -XX:UseCMSInitiatingOccupancyOnlyES 7.x 默认使用 G1GC配置里不再需要显式指定。如果你的版本还在用 CMS建议关注CMSInitiatingOccupancyFraction这个参数控制 CMS 在老年代占用多少比例时开始并发回收。在 G1GC 下主要关注这几个参数-XX:MaxGCPauseMillis200 -XX:G1HeapRegionSize4mMaxGCPauseMillis是 G1 的软目标200 毫秒是一个相对平衡的值。设置太低比如 50ms会导致 G1 过于激进地扩展回收集合CPU 消耗大幅增加设置太高比如 1000ms则失去了调优意义。GC 调优的核心指标是停顿频率而不是停顿时间。我见过有人把停顿时间从 200ms 压到 20ms结果 CPU 跑满整个服务吞吐量暴跌三分之二。这种「以吞吐换延迟」的调优在日志型场景基本都是得不偿失。3.4 内存锁定与 JVM 参数的系统级配合前面提到的bootstrap.memory_lock: true要真正生效需要操作系统的两个设置配合在/etc/security/limits.conf中es hard nofile 65536 es soft nofile 65536 es soft memlock unlimited es hard memlock unlimitednofile是文件描述符上限ES 运行时会打开大量文件每个分片、每个 segment 都对应文件默认的 1024 绝对不够。生产环境一定要调高通常是 65536 起步。memlock则是允许进程锁定内存的容量上限设置为unlimited才能让bootstrap.memory_lock: true不至于报错。改完limits.conf之后记得重新登录或者重启服务ulimit -l查一下确认是否生效。我遇到过一个情况配置文件改了没问题但服务是通过 systemd 启动的systemd 会无视/etc/security/limits.conf必须在 systemd service 文件里加LimitMEMLOCKinfinity LimitNOFILE65536这个问题特别隐蔽因为只检查 limits.conf 根本看不出来问题ES 日志里会持续报memory locking requested for elasticsearch process but memory is not locked这样的警告。4. log4j2.properties 与安全用户配置两个容易被忽视的模块4.1 日志滚动策略配置log4j2.properties里主要关注滚动策略。ES 默认按天滚动但如果你的日志量特别大单个日志文件可能膨胀到几 GB打开日志文件都会卡顿。appender.rolling.strategy.type: DefaultRolloverStrategy appender.rolling.strategy.max: 10 appender.rolling.strategy.action.condition.type: IfFileName appender.rolling.strategy.action.condition.glob: ${sys:es.logs}.log appender.rolling.strategy.action.condition.nested_condition.type: IfAccumulatedFileSize appender.rolling.strategy.action.condition.nested_condition.exceeds: 5GB这个配置的含义是当日志累计超过 5GB 时删除最多 10 个旧日志文件。这样既能保证磁盘不被日志打满又能保留足够的查询历史。日志文件还可以按大小分割需要在滚动配置里增加appender.rolling.filePattern的大小条件。具体字段在不同大版本之间略有差异建议以你当前版本的官方文档为准。我个人习惯是磁盘充足的情况下留 7~14 天日志磁盘紧张就 3 天。日志对排查故障太重要了千万别为了省空间把滚动周期设置得过短。4.2 安全用户与角色映射启用 X-Pack 安全后ES 节点启动时会有一些内置用户elastic、kibana_system、logstash_system等。role_mapping.yml负责把外部系统的用户组映射为 ES 角色比如公司内部统一身份认证系统里的某个部门映射为superuser。这个文件常用于配置 LDAP / Active Directory 认证的场景。如果不用外部认证用内置用户就够了。首次启动时通过初始化命令可以设置elastic用户的密码。这里有一个很关键的坑内置用户密码一定不要在生产环境用默认值否则等于裸奔。我见过有团队把 ES 映射到公网用的是默认密码结果被扫描工具直接攻破索引被清空还留下勒索信息。这个坑只要是经历过一次这辈子都不会再犯。5. 完整可复用的生产配置清单5.1 单节点测试环境配置cluster.name: es-test node.name: node-test-01 path.data: /data/elasticsearch/data path.logs: /data/elasticsearch/logs network.host: 0.0.0.0 http.port: 9200 discovery.type: single-node xpack.security.enabled: falsediscovery.type: single-node是测试模式专用的它跳过节点发现和选举过程启动速度更快。注意不要在生产环境使用这个配置否则后续加节点时集群行为会非常诡异。5.2 三节点生产集群配置三个节点的elasticsearch.yml大部分相同只有node.name不同cluster.name: es-production node.name: node-01 # 另外两个节点改成 node-02 和 node-03 node.roles: [master, data, ingest] path.data: /data/elasticsearch/data path.logs: /data/elasticsearch/logs path.repo: /backup/elasticsearch bootstrap.memory_lock: true network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: [node-01:9300, node-02:9300, node-03:9300] cluster.initial_master_nodes: [node-01, node-02, node-03] gateway.recover_after_nodes: 2 gateway.expected_nodes: 3 gateway.recover_after_time: 5m action.destructive_requires_name: true xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/certs/transport.p12 xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/certs/transport.p12 http.cors.enabled: true http.cors.allow-origin: https://kibana.example.internal http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE http.cors.allow-headers: X-Requested-With, Content-Type, Content-Length配套的jvm.options核心部分-Xms16g -Xmx16g -XX:UseG1GC -XX:MaxGCPauseMillis200这套配置在我的实践中跑得非常稳能扛住单日亿级日志的写入量集群基本不需要手动干预。6. 常见配置问题与排查实录6.1 启动报错memory locking requested but not available这是开启bootstrap.memory_lock: true后最常见的错误。排查步骤用ulimit -l查看当前用户的 memlock 限制unlimited才正常检查/etc/security/limits.conf是否写对了用户和值用 systemd 启动的话检查 service 文件里是否有LimitMEMLOCKinfinity确认没有同时设置bootstrap.system_call_filter: false这个参数在某些容器环境会掩盖内存问题的真实原因6.2 集群状态 yellow分片无法分配先用GET _cat/indices?v看哪些索引有问题再用GET _cluster/allocation/explain查看具体原因。最常见的原因有两个一是磁盘水位线设置默认cluster.routing.allocation.disk.watermark.low是 85%high是 90%。磁盘使用超过阈值后ES 会拒绝分配新分片。可以在配置里调整cluster.routing.allocation.disk.watermark.low: 80% cluster.routing.allocation.disk.watermark.high: 85% cluster.routing.allocation.disk.watermark.flood_stage: 90%注意flood_stage一旦触发ES 会把相关索引置为只读这时候必须手动释放磁盘空间或扩容并执行PUT /index/_settings把index.blocks.read_only_allow_delete解除。第二个常见原因是同一个节点的分片数达到上限cluster.routing.allocation.total_shards_per_node默认无限制但如果你手工设置过很容易卡住分片分配。6.3 max file descriptors 警告启动日志里出现max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]说明当前用户能打开的文件句柄数不够。ES 每个分片会占用至少一个句柄segment 文件会更多。如果这个值不够运行期间可能出现“Too many open files”的异常导致查询失败。按前面说的改limits.conf和 systemd 配置即可。改完重启后再用下面的方式确认curl -s http://node:9200/_nodes/process?pretty看输出里的max_file_descriptors字段应该是 65535 或者更大。6.4 bootstrap checks 失败[1] bootstrap checks failed [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]这个报错表示 Linux 系统的虚拟内存映射区域数量太少ES 需要足够的 mmap 区域来加载索引文件。解决办法是修改/etc/sysctl.confvm.max_map_count 262144执行sysctl -p使其生效。这个参数在容器环境也要注意有些容器的基础镜像默认值极低。6.5 集群脑裂排查思路怀疑脑裂时先看日志里有没有 master 多次选举的记录然后执行GET _cat/master?v确认当前 master再看看 node 列表里是否出现多个节点都认为自己是 master。新版 ES 里已经用新版协调机制替代了老的minimum_master_nodes但如果你还在用旧版本6.x 及以下请务必保证discovery.zen.minimum_master_nodes的值大于 master 候选节点数的半数。例如 3 个节点设置为 25 个设置为 3。6.6 升级版本后的配置兼容性ES 从 7.x 到 8.x不少配置项被改名或删除最常见的就是discovery.zen.*系列完全失效。升级前建议用elasticsearch-upgrade工具或者启动时的 warning 信息逐条排查。我遇到过最坑的一次是 7.10 升 8.x配置里残留了颈椎病般的多个不兼容参数启动日志只打 warning 不报错但集群行为明显异常最后通过逐条注释配置、重启对比才定位到问题。7. 配置管理最佳实践与心得ES 配置管理看似简单就是把几个 yaml 和 properties 文件改一改但在实际运维中踩过不少坑之后我总结了几条比较值得分享的经验。配置文件一定要做版本管理。elasticsearch.yml是集群的“宪法”每次修改都要走审批流并且要有 diff 记录。我用过一个简单办法每个节点启动前自动从配置中心拉取配置并校验 MD5保证所有节点配置一致。这有效避免了很多“为什么这两台机器行为不一致”的诡异问题。修改配置之前一定要先看版本差异。ES 大版本之间的配置项改动相当大7.x 里明明生效的参数到了 8.x 可能被移除或者改了语义。网上搜到的配置方案很可能过时最终以官方文档和当前版本的 reference 为准。如果配置之间有明显的依赖关系可以留意一下优先级。jvm.options参数优先级最高其次是elasticsearch.yml中的系统属性再其次是环境变量。如果在一个地方配置了 A 组值又在另一个地方配置了 B 组值最终生效的往往不是你以为的那个值。排查这类问题时最好的方法就是启动时加上-Des.logger.levelDEBUG或者直接看_nodes/settings接口返回的最终配置数据。我对配置最深的感受是ES 的配置没有银弹。一套配置配到极致的高手是把参数和硬件、业务场景、数据模型结合着思考的人。你可以先把本文里的配置拿来当起点再结合本机压测和监控数据做微调尤其是 GC 日志和慢查询日志要持续观察才能找到最适合自己集群的那一组数值。 
长河君 · 2026/10/9 20:42:20 · 阅读 1.2k Elasticsearch生产环境配置全解析：核心文件与最佳实践
1. 配置全景ES启动前先搞清这四类文件先同步一个概念很多人一说“ES配置文件”就只盯着elasticsearch.yml其实一个生产环境可用的 ES 实例至少要同时处理好四类文件。缺了哪一个轻则启动报错重则集群跑着跑着把数据搞丢。我按优先级给你排个序配置文件作用范围优先级jvm.options控制 ES 进程的 JVM 参数堆内存、GC、JVM 调优最高启动时最先被读取elasticsearch.ymlES 核心功能配置集群、节点、网络、存储、安全等核心几乎所有业务配置都在这里log4j2.properties日志输出格式、滚动策略、日志级别运维排查时高频修改role_mapping.yml/users_roles/elasticsearch-users安全认证相关角色映射仅在开启安全特性时需要一般解决方案或者教程里讲的“配置 ES”九成时间都在折腾elasticsearch.yml但如果你直接照抄网上的 demo 配置就上生产大概率会踩到堆内存和文件描述符的坑。所以这篇文章我会把四类文件的每一项配置都拆开讲重点放在elasticsearch.yml和jvm.options上顺带提醒几个日志和安全的常见误区。2. elasticsearch.yml 核心配置逐项解读2.1 集群与节点命名不许随便起名字cluster.name: es-production node.name: node-01 node.roles: [master, data, ingest]cluster.name是集群的唯一标识同一个集群的所有节点必须完全一致。这个字段没有默认的“自动生成”逻辑不写的话 ES 会用默认值但你后面要加节点、维护集群状态、排查脑裂问题的时候一堆默认名字的节点会让你痛不欲生。node.name建议用「机房角色编号」的命名法比如cn-north-master-01。我用过纯数字编号的集群后来扩了十几个节点后光靠 IP 根本对不上日志里的节点名排查问题效率极低。node.roles是 ES 7.x 之后引入的角色划分机制。这里最容易犯的错是什么单节点测试环境不指定 roles没问题但多节点集群里如果不显式声明ES 会默认让每个节点同时承担 master、data、ingest 全角色。小规模集群无所谓一旦规模超过 15~20 个节点这种“全角色”配置会带来无谓的 master 选举竞争和 data 节点间的分片迁移压力。实操建议3 节点以下的集群可以用默认全角色5 节点以上建议明确拆出 3 个 master 候选节点和若干 data 节点。2.2 路径配置ES 迈不过去的三个目录path.data: /data/elasticsearch/data path.logs: /data/elasticsearch/logs path.repo: /backup/elasticsearchpath.data索引数据、分片数据、translog 的存放位置。生产环境必须放在独立的高性能磁盘上SSD 优先千万别和系统盘混在一起。原因是 ES 的写入链路对磁盘 IOPS 极其敏感系统日志频繁读写会拖垮索引性能。path.logsES 自身日志目录排错时第一眼要看的地方。path.repo快照仓库路径做备份恢复时用。注意这里只是“注册”位置真正的快照数据会写在里面对应的仓库子目录里。我有一次排障发现某节点的磁盘 IO 居高不下排查了半天发现是path.data和 swap 分区在同一块机械盘上索引吞吐率直接掉了 70%。这类问题用iostat和iotop就能定位但最好的办法是开局就分开。2.3 网络与通信配置network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: [node-01:9300, node-02:9300, node-03:9300] cluster.initial_master_nodes: [node-01, node-02, node-03]network.host是 ES 节点监听的地址。测试环境可以设127.0.0.1生产环境一般写0.0.0.0表示监听所有网卡但这样会有暴露风险必须配合防火墙或者安全认证使用。如果你只想让内网访问也可以写成具体的内网 IP。http.port是 REST API 端口默认9200一般不用动transport.port是节点间内部通信端口默认9300。这两个端口名字容易混淆我见过有人防火墙只开了 9200结果节点间一直无法通信集群总是 yellow排查了很久才发现 9300 被挡了。discovery.seed_hosts是节点发现列表。ES 启动时通过这些地址找到其他节点进而完成集群组建。注意这里写的是 transport 端口9300不是 http 端口9200。写错端口是新手高频错误之一。cluster.initial_master_nodes只在集群第一次初始化时有用列出的是具备 master 资格的节点名。集群建立起来之后这个配置就失去作用了但你不能随便删掉它因为如果所有节点同时重启没有这个配置会导致集群无法在启动时主动选举进入一种“谁也说服不了谁”的状态。2.4 集群脑裂防护配置discovery.zen.minimum_master_nodes: 2这是 ES 7.x 之前防脑裂最关键的参数在 7.x 之后被新的集群协调机制淘汰了。新版本里不需要手动设置这个值系统会自动根据 master 候选节点数量计算最少需要多少个节点参与选举。但这里要强调一个底层原则避免脑裂的核心是保证只有“大多数”节点能选举出 master。ES 7.x 之后的新机制用了类似 Raft 的算法要求一个 master 必须获得超过半数的选票才能当选。所以你在设计集群时master 候选节点数量必须是奇数比如 3 个或 5 个。如果设置 2 个当其中一个宕机时剩下一个无论如何都无法达到“超过半数”至少需要 2 票集群就完全瘫痪如果只设 1 个脑裂风险极高。实操经验3 个 master 候选节点允许挂 1 个5 个 master 候选节点允许挂 2 个。这个配比是性价比和可用性的最佳折中点。2.5 堆内存以外的内存管理设置bootstrap.memory_lock: true这个参数很多人容易忽略但它对生产环境的稳定性格外重要。bootstrap.memory_lock: true的作用是锁定 ES 进程占用的内存禁止系统把它 swap 到磁盘上。ES 是内存敏感型应用如果内存被 swapGC 停顿时间会剧烈上升请求延迟直接从毫秒级变成秒级而且毫无规律。你会在监控上看到极其诡异的毛刺CPU 不高、堆内存也没满但查询就是慢。开启这个选项需要操作系统的配合具体做法后面章节我会把常见报错和排查写出来。这里先说结论生产环境一律开启测试环境如果内存不足可以先关掉。2.6 数据可靠性设置gateway.recover_after_nodes: 3 gateway.expected_nodes: 5 gateway.recover_after_time: 5mgateway这一组配置控制的是集群全量重启后数据恢复的时机。ES 在集群刚启动时不会立刻开始恢复分片而是等待满足条件后才动手。recover_after_nodes至少多少个节点加入后开始恢复expected_nodes期望的节点总数recover_after_time如果节点数始终达不到期望值最多等 5 分钟后也强行开始恢复这里有一个很重要的设计逻辑如果不设置等待时间集群每次启动时只要有节点就立刻开始大规模分片恢复会把磁盘 IO 和网络打满。设置等待时间后等大部分节点都上线了再一次性恢复速度反而更快、更平缓。经验值参考recover_after_nodes设为主数据节点数量的一半以上expected_nodes设为集群总节点数。计算方式可以记为「N/21」原则有点类似脑裂防护的“过半数”思路。2.7 索引分片恢复并发度cluster.routing.allocation.node_concurrent_recoveries: 3 cluster.routing.allocation.node_concurrent_incoming_recoveries: 3 cluster.routing.allocation.node_concurrent_outgoing_recoveries: 3这几个参数控制分片恢复时的并发数。默认值是 2对于机械盘可能刚好合适但如果你用的是 SSD可以适当调大到 3~5。注意不要贪心并发调太高会导致 IO 过载反而把恢复速度拖慢。我调过最成功的一次是从 2 调到 4恢复时间缩短了 40%磁盘 IO 依然有余量。但如果机器上同时还有其他服务跑着建议保守一点保持默认。2.8 安全认证配置xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/certs/transport.p12 xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/certs/transport.p12ES 的安全功能属于 X-Pack基础版免费提供。如果是 8.x 版本安全功能默认开启如果是 7.x 版本默认关闭需要手动打开。这里最容易被坑的地方是xpack.security.enabled和transport.ssl必须同时考虑。仅开启安全认证不启用 TLS 加密密码在集群内网传输时是明文安全性形同虚设。而开启 TLS 又涉及到证书的生成和分发三个节点的集群三个节点都要把证书放到相同路径。如果你不想在生产环境折腾证书最低限度也要保证xpack.security.enabled: true 内网隔离但这只是权宜之计不推荐作为长期方案。2.9 跨域配置http.cors.enabled: true http.cors.allow-origin: * http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE http.cors.allow-headers: X-Requested-With, Content-Type, Content-Length这个配置主要是给 Kibana、Cerebro 等可视化工具用的。如果不开跨域浏览器端的请求会被跨域策略拦截你会在控制台里看到一片红。但注意http.cors.allow-origin: *在生产环境是风险隐患等于允许任意来源的浏览器请求访问节点。如果 ES 节点暴露在公网绝对不能用*要写成具体的 Kibana 域名或前端应用域名。我的习惯是只允许 Kibana 所在服务器的地址其他一律拒绝。2.10 其他高频但容易被忽视的配置项action.destructive_requires_name: true indices.query.bool.max_clause_count: 2048action.destructive_requires_name是用来防止误删索引的。把它设为true后执行DELETE *或者DELETE _all这类通配符删除操作就会被拒绝。我在测试环境吃过大亏本想清空一个测试索引手滑执行了DELETE *整个集群的索引全部被删了。从此之后在任何环境我都默认开这个参数。indices.query.bool.max_clause_count是查询时 bool 子句数量的上限默认值是 1024。如果你的业务里有复杂的多条件组合查询很容易打满这个限制导致报错。调太高也不好会带来严重的 CPU 和内存开销。建议按实际业务压测后取一个折中值一般 2048 够用。3. jvm.options 堆内存与 GC 配置实战3.1 堆内存设置的“黄金规则”-Xms4g -Xmx4gES 官方明确建议-Xms和-Xmx必须设置为相同值。为什么因为如果不一致JVM 在运行过程中会动态调整堆大小这个调整过程会触发 Full GC导致响应时间出现难以预测的尖刺。设为相同值后JVM 启动时就完全分配好堆空间运行时避免堆扩容带来的性能损耗。堆内存最大值建议设为物理内存的 50%且不要超过 30GB。很多人不理解“为什么不能给 JVM 分配 50GB”。原因有两层第一层ES 最底层用的是 LuceneLucene 本身非常依赖操作系统的文件缓存它并不把索引数据全部放进 JVM 堆里而是用mmap的方式把文件映射到堆外内存通过 OS page cache 加速访问。你给 ES 堆内存分得越多留给系统文件缓存的就越少索引读写反而变慢。第二层JVM 对象指针压缩技术的限制。当堆内存小于 32GB 时JVM 可以启用「普通对象指针压缩」compressed oops能显著节省对象头占用的内存一旦超过 32GB指针压缩失效对象头变大实际的可用内存反而可能比 30GB 时更少。这是 Elastic 官方在博客里明确验证过的结论上限 30GB 不是玄学是 JVM 底层机制的硬限制。3.2 典型堆内存配置方案物理内存推荐堆内存预留系统内存16GB8GB8GB32GB16GB16GB64GB28-30GB34GB128GB30GB98GB物理内存 64GB 时推荐堆内存上限 30GB不能超过。预留的 34GB 中一部分给 Lucene 文件缓存一部分给操作系统本身和各种进程的 overhead。从我多次压测的经验看16GB 内存的机器给 8GB 堆对于中小规模的日志检索场景已经够用但如果你的写入并发很高或者索引特别多8GB 堆会频繁触发 GC这时候优先考虑加机器而不是调大堆内存。3.3 GC 策略的选择与调优-XX:UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction75 -XX:UseCMSInitiatingOccupancyOnlyES 7.x 默认使用 G1GC配置里不再需要显式指定。如果你的版本还在用 CMS建议关注CMSInitiatingOccupancyFraction这个参数控制 CMS 在老年代占用多少比例时开始并发回收。在 G1GC 下主要关注这几个参数-XX:MaxGCPauseMillis200 -XX:G1HeapRegionSize4mMaxGCPauseMillis是 G1 的软目标200 毫秒是一个相对平衡的值。设置太低比如 50ms会导致 G1 过于激进地扩展回收集合CPU 消耗大幅增加设置太高比如 1000ms则失去了调优意义。GC 调优的核心指标是停顿频率而不是停顿时间。我见过有人把停顿时间从 200ms 压到 20ms结果 CPU 跑满整个服务吞吐量暴跌三分之二。这种「以吞吐换延迟」的调优在日志型场景基本都是得不偿失。3.4 内存锁定与 JVM 参数的系统级配合前面提到的bootstrap.memory_lock: true要真正生效需要操作系统的两个设置配合在/etc/security/limits.conf中es hard nofile 65536 es soft nofile 65536 es soft memlock unlimited es hard memlock unlimitednofile是文件描述符上限ES 运行时会打开大量文件每个分片、每个 segment 都对应文件默认的 1024 绝对不够。生产环境一定要调高通常是 65536 起步。memlock则是允许进程锁定内存的容量上限设置为unlimited才能让bootstrap.memory_lock: true不至于报错。改完limits.conf之后记得重新登录或者重启服务ulimit -l查一下确认是否生效。我遇到过一个情况配置文件改了没问题但服务是通过 systemd 启动的systemd 会无视/etc/security/limits.conf必须在 systemd service 文件里加LimitMEMLOCKinfinity LimitNOFILE65536这个问题特别隐蔽因为只检查 limits.conf 根本看不出来问题ES 日志里会持续报memory locking requested for elasticsearch process but memory is not locked这样的警告。4. log4j2.properties 与安全用户配置两个容易被忽视的模块4.1 日志滚动策略配置log4j2.properties里主要关注滚动策略。ES 默认按天滚动但如果你的日志量特别大单个日志文件可能膨胀到几 GB打开日志文件都会卡顿。appender.rolling.strategy.type: DefaultRolloverStrategy appender.rolling.strategy.max: 10 appender.rolling.strategy.action.condition.type: IfFileName appender.rolling.strategy.action.condition.glob: ${sys:es.logs}.log appender.rolling.strategy.action.condition.nested_condition.type: IfAccumulatedFileSize appender.rolling.strategy.action.condition.nested_condition.exceeds: 5GB这个配置的含义是当日志累计超过 5GB 时删除最多 10 个旧日志文件。这样既能保证磁盘不被日志打满又能保留足够的查询历史。日志文件还可以按大小分割需要在滚动配置里增加appender.rolling.filePattern的大小条件。具体字段在不同大版本之间略有差异建议以你当前版本的官方文档为准。我个人习惯是磁盘充足的情况下留 7~14 天日志磁盘紧张就 3 天。日志对排查故障太重要了千万别为了省空间把滚动周期设置得过短。4.2 安全用户与角色映射启用 X-Pack 安全后ES 节点启动时会有一些内置用户elastic、kibana_system、logstash_system等。role_mapping.yml负责把外部系统的用户组映射为 ES 角色比如公司内部统一身份认证系统里的某个部门映射为superuser。这个文件常用于配置 LDAP / Active Directory 认证的场景。如果不用外部认证用内置用户就够了。首次启动时通过初始化命令可以设置elastic用户的密码。这里有一个很关键的坑内置用户密码一定不要在生产环境用默认值否则等于裸奔。我见过有团队把 ES 映射到公网用的是默认密码结果被扫描工具直接攻破索引被清空还留下勒索信息。这个坑只要是经历过一次这辈子都不会再犯。5. 完整可复用的生产配置清单5.1 单节点测试环境配置cluster.name: es-test node.name: node-test-01 path.data: /data/elasticsearch/data path.logs: /data/elasticsearch/logs network.host: 0.0.0.0 http.port: 9200 discovery.type: single-node xpack.security.enabled: falsediscovery.type: single-node是测试模式专用的它跳过节点发现和选举过程启动速度更快。注意不要在生产环境使用这个配置否则后续加节点时集群行为会非常诡异。5.2 三节点生产集群配置三个节点的elasticsearch.yml大部分相同只有node.name不同cluster.name: es-production node.name: node-01 # 另外两个节点改成 node-02 和 node-03 node.roles: [master, data, ingest] path.data: /data/elasticsearch/data path.logs: /data/elasticsearch/logs path.repo: /backup/elasticsearch bootstrap.memory_lock: true network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: [node-01:9300, node-02:9300, node-03:9300] cluster.initial_master_nodes: [node-01, node-02, node-03] gateway.recover_after_nodes: 2 gateway.expected_nodes: 3 gateway.recover_after_time: 5m action.destructive_requires_name: true xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/certs/transport.p12 xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/certs/transport.p12 http.cors.enabled: true http.cors.allow-origin: https://kibana.example.internal http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE http.cors.allow-headers: X-Requested-With, Content-Type, Content-Length配套的jvm.options核心部分-Xms16g -Xmx16g -XX:UseG1GC -XX:MaxGCPauseMillis200这套配置在我的实践中跑得非常稳能扛住单日亿级日志的写入量集群基本不需要手动干预。6. 常见配置问题与排查实录6.1 启动报错memory locking requested but not available这是开启bootstrap.memory_lock: true后最常见的错误。排查步骤用ulimit -l查看当前用户的 memlock 限制unlimited才正常检查/etc/security/limits.conf是否写对了用户和值用 systemd 启动的话检查 service 文件里是否有LimitMEMLOCKinfinity确认没有同时设置bootstrap.system_call_filter: false这个参数在某些容器环境会掩盖内存问题的真实原因6.2 集群状态 yellow分片无法分配先用GET _cat/indices?v看哪些索引有问题再用GET _cluster/allocation/explain查看具体原因。最常见的原因有两个一是磁盘水位线设置默认cluster.routing.allocation.disk.watermark.low是 85%high是 90%。磁盘使用超过阈值后ES 会拒绝分配新分片。可以在配置里调整cluster.routing.allocation.disk.watermark.low: 80% cluster.routing.allocation.disk.watermark.high: 85% cluster.routing.allocation.disk.watermark.flood_stage: 90%注意flood_stage一旦触发ES 会把相关索引置为只读这时候必须手动释放磁盘空间或扩容并执行PUT /index/_settings把index.blocks.read_only_allow_delete解除。第二个常见原因是同一个节点的分片数达到上限cluster.routing.allocation.total_shards_per_node默认无限制但如果你手工设置过很容易卡住分片分配。6.3 max file descriptors 警告启动日志里出现max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]说明当前用户能打开的文件句柄数不够。ES 每个分片会占用至少一个句柄segment 文件会更多。如果这个值不够运行期间可能出现“Too many open files”的异常导致查询失败。按前面说的改limits.conf和 systemd 配置即可。改完重启后再用下面的方式确认curl -s http://node:9200/_nodes/process?pretty看输出里的max_file_descriptors字段应该是 65535 或者更大。6.4 bootstrap checks 失败[1] bootstrap checks failed [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]这个报错表示 Linux 系统的虚拟内存映射区域数量太少ES 需要足够的 mmap 区域来加载索引文件。解决办法是修改/etc/sysctl.confvm.max_map_count 262144执行sysctl -p使其生效。这个参数在容器环境也要注意有些容器的基础镜像默认值极低。6.5 集群脑裂排查思路怀疑脑裂时先看日志里有没有 master 多次选举的记录然后执行GET _cat/master?v确认当前 master再看看 node 列表里是否出现多个节点都认为自己是 master。新版 ES 里已经用新版协调机制替代了老的minimum_master_nodes但如果你还在用旧版本6.x 及以下请务必保证discovery.zen.minimum_master_nodes的值大于 master 候选节点数的半数。例如 3 个节点设置为 25 个设置为 3。6.6 升级版本后的配置兼容性ES 从 7.x 到 8.x不少配置项被改名或删除最常见的就是discovery.zen.*系列完全失效。升级前建议用elasticsearch-upgrade工具或者启动时的 warning 信息逐条排查。我遇到过最坑的一次是 7.10 升 8.x配置里残留了颈椎病般的多个不兼容参数启动日志只打 warning 不报错但集群行为明显异常最后通过逐条注释配置、重启对比才定位到问题。7. 配置管理最佳实践与心得ES 配置管理看似简单就是把几个 yaml 和 properties 文件改一改但在实际运维中踩过不少坑之后我总结了几条比较值得分享的经验。配置文件一定要做版本管理。elasticsearch.yml是集群的“宪法”每次修改都要走审批流并且要有 diff 记录。我用过一个简单办法每个节点启动前自动从配置中心拉取配置并校验 MD5保证所有节点配置一致。这有效避免了很多“为什么这两台机器行为不一致”的诡异问题。修改配置之前一定要先看版本差异。ES 大版本之间的配置项改动相当大7.x 里明明生效的参数到了 8.x 可能被移除或者改了语义。网上搜到的配置方案很可能过时最终以官方文档和当前版本的 reference 为准。如果配置之间有明显的依赖关系可以留意一下优先级。jvm.options参数优先级最高其次是elasticsearch.yml中的系统属性再其次是环境变量。如果在一个地方配置了 A 组值又在另一个地方配置了 B 组值最终生效的往往不是你以为的那个值。排查这类问题时最好的方法就是启动时加上-Des.logger.levelDEBUG或者直接看_nodes/settings接口返回的最终配置数据。我对配置最深的感受是ES 的配置没有银弹。一套配置配到极致的高手是把参数和硬件、业务场景、数据模型结合着思考的人。你可以先把本文里的配置拿来当起点再结合本机压测和监控数据做微调尤其是 GC 日志和慢查询日志要持续观察才能找到最适合自己集群的那一组数值。