1. 整体设计思路与集群规划1.1 为什么是3主2从而不是其他组合先说结论3主2从这个组合是在数据可靠性和硬件成本之间相当务实的一个平衡点。我见过不少团队第一次搭ELK上来就无脑三主三从实际上中小规模日志量根本用不到那么重的配置运维成本还直线上升。反过来也有图省事搞“单节点闯天下”的一段时间后数据一多节点一挂整个日志系统直接瘫痪排查问题连历史日志都翻不出来非常被动。选3个主节点首先是为了解决“脑裂”问题。Elasticsearch的选主机制依赖“多数派”原则3个主节点意味着集群可以容忍任意1个主节点宕机而依旧保持可用。如果只有2个主节点其中一个挂了剩下的那个凑不出多数派集群会进入只读状态甚至完全不可用。这是硬性要求不是靠配置绕得过去的。再加上默认的minimum_master_nodes设置为23主配置就是标准姿势。2个从节点则承担实际的数据存储和查询负载。为什么不是1个从节点因为数据副本replica至少得有1份才谈得上高可用而副本是跨节点分布的2个数据节点意味着每个分片的主副本和从副本可以落在不同节点上任何一个数据节点挂掉另一个还能顶上继续服务。1个从节点也不是不行但副本只能和主分片挤在同一台机器上一旦那台机器宕机数据就真丢了等于高可用形同虚设。我这里把“主节点”和“从节点”的逻辑再明确一下在Elasticsearch里“主节点”负责集群状态管理、索引创建删除、分片分配这些元数据操作并不是说主节点的机器就一定要存数据“从节点”则主要负责数据存储和检索。实际部署时主节点机器通常配置为不存储数据node.data: false专职做管理避免因数据读写压力影响集群稳定性。7.17.9版本里这类节点通常叫“Master-eligible node”和“Data node”配置上主要靠node.roles区分。1.2 版本选型锁定7.17.9的考量Elasticsearch 7.17.9是7.x系列的最后一个维护版本这一点非常关键。很多团队至今仍大量使用7.x生态插件、监控、上下游对接都基于7.x验证过。8.x版本虽然功能更新但引入了不少破坏性变更比如默认开启安全认证、REST API结构调整、客户端兼容性变化迁移成本并不低。7.17.9作为7.x的“收尾版本”修复了大量已知Bug和CVE漏洞稳定性在7.x里属于比较能打的。另外Kibana必须和Elasticsearch保持主版本一致这是官方强制要求。7.17.9配7.17.9是合规且稳妥的组合。后期如果升级两个组件也应当是同步升级避免出现版本不一致导致的兼容性问题。Logstash、Filebeat等周边组件同理尽量用7.17.x配套版本减少不必要的兼容性排查。1.3 硬件配置与网络规划参考3主2从共5台机器主从的硬件配置策略我个人建议是主节点不需要太高的存储配置重点保证CPU和内存稳定因为集群管理操作和选主过程对响应时间敏感从节点则要大内存、大磁盘数据读写和聚合查询主要消耗在这里。角色CPU内存磁盘系统主节点3台4核8G100G系统盘CentOS 7.x / Ubuntu 20.04从节点2台8核16G1T数据盘CentOS 7.x / Ubuntu 20.04如果日志量特别大从节点的磁盘建议直接上SSD机械盘在大量聚合查询时会明显拖慢响应。内存方面Elasticsearch有一个重要规则给JVM堆内存的配置不要超过系统内存的一半且单节点堆内存上限建议32G留出的系统内存给Lucene做文件缓存实际查询性能很大程度依赖这个Lucene缓存。网络方面5台机器建议处于同一内网或同一可用区节点间通信延迟控制在毫秒级。跨地域组集群不是不可以但对网络稳定性要求非常高一旦网络抖动频繁主节点之间的选主交互和数据节点的副本同步都会受影响轻则产生告警重则触发集群脑裂。生产环境我一般建议节点间内网带宽至少千兆。2. 部署前的系统配置与基础环境准备2.1 操作系统基础调优Elasticsearch对系统的要求不算苛刻但有几项基础配置不对后面运行会非常折腾。我把实践中踩过坑的地方集中列一下这些是在安装Elasticsearch之前就要处理好的。文件句柄数限制。Elasticsearch会同时打开大量文件特别是数据节点索引分片越多文件句柄占用越大。默认的1024肯定不够我一般直接改到65535。修改方式是编辑/etc/security/limits.conf加上es_user soft nofile 65535 es_user hard nofile 65535注意这里的es_user要替换成你实际创建的用户后面会详细说用户创建的事。生效需要重新登录或者重启终端。虚拟内存参数。Elasticsearch的Lucene底层用了大量mmap映射文件默认的虚拟内存映射数量上限通常不够用运行时会报“max virtual memory areas vm.max_map_count [65530] is too low”的错误。执行sysctl -w vm.max_map_count262144同时写入/etc/sysctl.conf让它永久生效。这个参数我在第一次部署时忽略过结果启动集群后数据节点日志疯狂报错排查了很久才发现是这个问题。关闭交换分区swap。Elasticsearch官方建议关闭swap或者至少将swap使用降到最低因为内存交换会导致JVM性能急剧下降。稳妥操作swapoff -a如果是云服务器还要注意实例本身的swap配置。这一步做完再配合/etc/fstab注释掉交换分区条目避免重启后swap自动恢复。2.2 专用用户与目录规划Elasticsearch明确禁止使用root用户运行这是官方硬性要求因为root启动会直接报错退出。我的做法是创建一个专用用户并且把数据、日志、配置目录的属主都切到该用户下useradd -m es_user mkdir -p /opt/elasticsearch/{data,logs} mkdir -p /opt/elasticsearch/config chown -R es_user:es_user /opt/elasticsearch目录规划上有个经验数据和日志尽量分盘存放。如果只有一块数据盘至少也要分目录。数据盘如果被日志写满Elasticsearch会自动将索引设置为只读这是保护机制但会导致业务日志写入失败非常坑。我遇到过磁盘满了之后Filebeat还在持续生产数据结果Elasticsearch拒绝写入再去看时一大片索引都是read-only状态处理起来很麻烦。所以日志目录和数据目录分开甚至给系统盘也留够空间是值得提前规划的事。2.3 JDK版本确认Elasticsearch 7.17.9自带OpenJDK如果你不想折腾直接用自带的就行。但不少团队机器上已经有自己的JDK环境需要注意版本兼容。7.17.9要求Java 11或Java 17我建议优先使用Java 11的长期支持版本。如果机器上默认JDK版本不对可以用环境变量强制指定export JAVA_HOME/opt/jdk-11 export PATH$JAVA_HOME/bin:$PATH也可以在elasticsearch启动脚本对应的环境配置里指定但生产环境我倾向于在启动ES之前先echo $JAVA_HOME确认一遍避免启动后才发现用的JVM版本不对日志里报UnsupportedJavaVersionError非常浪费时间。3. Elasticsearch 7.17.9集群配置详解3.1 配置文件核心参数解读Elasticsearch的配置集中在config/elasticsearch.yml集群能否健康运行大部分关键决策都在这个文件里。我直接给出一份经过生产验证的配置模板然后逐个解释为什么这么设。以主节点node-1为例cluster.name: es-prod-cluster node.name: node-1 node.roles: [ master ] network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: - node-1:9300 - node-2:9300 - node-3:9300 - node-4:9300 - node-5:9300 cluster.initial_master_nodes: - node-1 - node-2 - node-3 path.data: /opt/elasticsearch/data path.logs: /opt/elasticsearch/logs discovery.zen.minimum_master_nodes: 2对从节点node-4来说主要是node.roles不同cluster.name: es-prod-cluster node.name: node-4 node.roles: [ data ] network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: - node-1:9300 - node-2:9300 - node-3:9300 - node-4:9300 - node-5:9300 path.data: /opt/elasticsearch/data path.logs: /opt/elasticsearch/logs关键参数逐个说cluster.name同一个集群的所有节点必须同名。这个不解释但经常有人搭好了发现节点之间互相发现不了最后发现是某台机器上的cluster.name抄错了排查了很久。node.name每个节点必须不同。建议用有规律的命名node-1到node-5方便日志定位。node.roles7.x之前是用node.master和node.data两个布尔值控制7.x开始建议用node.roles数组。主节点只写master角色从节点只写data角色。有一点要注意如果node.roles配置为空或者不配置默认这个节点可以担任所有角色包括master和data在5节点架构里这就违背了角色分离的初衷。discovery.seed_hosts这个参数是节点启动后用来发现集群中其他节点的地址列表。填的是transport端口9300而非http端口9200很多人第一次配置容易搞混。我建议把5台节点全部写进去虽然主节点理论上只需要发现其他主节点但写全了后续加节点不用再改配置省事。cluster.initial_master_nodes这是集群首次启动时用于引导选主的节点列表只在第一次集群启动时需要后续重启会自动忽略。如果首次启动时漏配集群会选不出主节点一直处于yellow或red状态。这里建议填写所有主节点。discovery.zen.minimum_master_nodes防止脑裂的关键参数值设置为“主节点数/2 1”即3/212。有了这个配置一个节点想成为主节点需要至少拿到2个主eligible节点的投票才能完成选主从机制上避免网络分区时出现两个主节点。这个参数在7.x里已经默认继承到discovery的配置里但手动显式写上更稳妥。3.2 JVM参数与内存分配在config/jvm.options里最核心的两个参数是堆内存的初始值和最大值-Xms8g -Xmx8g官方强烈建议Xms和Xmx设置为相同值避免运行过程中JVM动态伸缩堆大小带来的性能损耗。上面提到过堆内存不要超过物理内存的50%。以16G内存的数据节点为例堆设8G剩下8G留给Lucene。如果物理内存只有8G堆设到4G以内比较合适否则系统自身都会因为内存不足开始swap性能反而下降。另外如果单个节点内存超过32G建议不要继续往上调堆大小而是通过增加节点数来扩展因为JVM在堆超过32G时会默认启用压缩指针失效机制对象头变大GC效率反而降低这是JVM层面的一个经典经验值。3.3 集群启动顺序与验证首次启动集群顺序很重要。先把3个主节点全部启动确认主节点之间互相发现并选出主节点之后再启动数据节点。如果数据节点先启动它们会因为找不到主节点而不断重试虽然最终也能恢复但日志里会多出一堆无意义的警告信息干扰后续排查。启动命令很简单su - es_user -c /opt/elasticsearch/bin/elasticsearch -d-d表示后台守护进程方式运行。启动后先看日志有没有报错tail -f /opt/elasticsearch/logs/es-prod-cluster.log然后确认集群状态curl -s http://127.0.0.1:9200/_cluster/health?pretty一个健康的集群status字段应该是green。对3主2从的架构来说green意味着所有索引的主分片和副本分片都分配到了可用节点上。如果出现yellow说明有副本分片未分配常见原因是数据节点数不够无法满足副本分布要求如果出现red说明存在主分片未分配的情况需要进一步排查故障节点或磁盘空间。再看节点列表确认5个节点都注册成功curl -s http://127.0.0.1:9200/_cat/nodes?v展示结果里应该能看到5行节点信息IP列为各自的地址node.role列明确标识了mmaster和ddata角色。如果这里缺了某个节点优先检查该节点日志常见原因是network.host配置不一致或transport端口被占用。4. Kibana 7.17.9部署与接入集群4.1 安装步骤与基础配置Kibana的安装包下载方式和Elasticsearch一致解压后主要关心config/kibana.yml。它本身不存储数据只是一个展示和查询界面所以部署在任意一台能访问集群的机器上都可以。我的习惯是部署在一台主节点机器上或者独立一台机器看团队机器资源情况。一份可用的kibana.yml配置server.port: 5601 server.host: 0.0.0.0 elasticsearch.hosts: [http://node-1:9200, http://node-2:9200, http://node-3:9200] kibana.index: .kibana logging.dest: /opt/kibana/logs/kibana.logelasticsearch.hosts这里填所有主节点的HTTP地址Kibana会自动做负载均衡单点故障时自动切换体验比只填一个地址好很多。server.host如果只在本机访问可以填127.0.0.1但如果是内网环境多人需要访问Kibana界面就要监听内网IP或0.0.0.0然后通过防火墙或安全组限制来源IP。启动Kibanasu - es_user -c /opt/kibana/bin/kibana生产环境建议用systemd管理进程方便开机自启和崩溃自动拉起。systemd配置网上有很多模板但有几个细节容易被忽略User指定为es_userExecStart写Kibana的bin目录绝对路径Restarton-failure。4.2 可视化与索引管理的必要设置Kibana首次访问界面会引导创建Index Pattern。这里要注意Index Pattern的正则匹配是基于索引名称的如果日志索引按天命名比如logstash-2024.08.26建议直接把pattern设为logstash-*这样所有按天生成的索引都会自动被匹配到。日常使用Kibana有几个地方值得花时间设置索引生命周期管理ILM。如果日志数据量级可观强烈建议在Elasticsearch侧配置ILM策略比如保留30天自动删除旧索引或者按容量触发滚动。这个不配的话日志索引会无限增长磁盘很快就满了。配置策略后在Kibana的Stack Management里给对应索引模板绑定策略即可。Discover页面时区。Kibana默认时区是UTC国内环境下会发现日志时间比本地时间晚8小时。在Kibana的Advanced Settings里把dateFormat:tz设为本地时区或者直接在界面右上角切换这个不算技术难题但几乎每个团队第一次用时都会踩。Dashboard权限。如果团队人多建议在Kibana里创建不同Space或通过用户角色隔离视图避免有人误删索引或修改系统配置。Kibana 7.17.9的告警、异常检测等功能也值得试但正式使用前先小范围验证不要直接全量启用。5. 安全与防火墙策略落地5.1 端口规划与防火墙最小化原则ELK集群涉及多个端口Elasticsearch的9200是HTTP接口9300是节点间通信的Transport接口Kibana的5601是Web访问端口。生产环境的防火墙策略我的原则是“能不开就不开能限制就限制”。以Linux防火墙举例先添加必要端口firewall-cmd --permanent --add-port9200/tcp firewall-cmd --permanent --add-port9300/tcp firewall-cmd --permanent --add-port5601/tcp firewall-cmd --reload但这只是第一步。9200端口如果对所有来源开放知道IP的人可以直接访问Elasticsearch的REST接口删索引、改配置都很容易非常危险。我的做法是在Firewalld里针对来源IP做白名单限制只允许采集端比如Filebeat所在服务器访问9200只允许运维网段访问5601firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.0/24 port protocoltcp port9200 accept firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.10.0.0/16 port protocoltcp port5601 accept9300端口主要给集群内部节点通信用建议只在5台ES节点之间放通不要暴露到外部。我见过有人把所有端口都裸奔在公网然后数据被勒索的情况虽然Elasticsearch默认没有认证机制但配合防火墙和网络隔离完全可以规避大部分风险。5.2 认证与加密的基本方案7.17.9默认是关闭安全认证的。如果你的集群只在内网运行且网络隔离做得足够好短期用默认配置问题不大。但只要集群有可能被更多人访问或者你不想因为日志泄露背锅就建议在部署阶段就把安全功能打开。Elasticsearch 7.17.9自带的安全功能包括TLS加密和用户名密码认证。开启的流程大致是为每个节点生成证书在elasticsearch.yml里配置xpack.security.enabled: true和xpack.security.transport.ssl相关配置然后通过elasticsearch-setup-passwords命令为内置账号设置密码最后在Kibana配置里指定elasticsearch账号密码。这一步如果在集群搭建完成后再做会牵扯到滚动重启和证书分发比部署初期做麻烦好几倍。所以我的建议是如果你有任何可能开启安全功能的计划请在部署阶段就做好规划。即使暂时不启用也要在架构和配置上留好扩展位比如证书目录提前规划、账号体系提前设计。5.3 系统安全与基线加固除了防火墙和ES自带的认证几个基础的安全加固也值得做按需开放端口定期用ss或netstat检查端口监听情况控制文件权限Elasticsearch配置目录权限设为750es_user属主避免其他用户读取配置文件里的密码信息系统补丁及时更新这个不用多讲但确实容易被忽略备份策略Elasticsearch的备份通常用snapshot接口打到对象存储或NAS建议在部署完成后就做一次完整快照测试恢复不要等到数据丢了才开始研究备份方案。6. 日志采集与Filebeat接入配置6.1 Filebeat配置与输出到Elasticsearch整个ELK链路中采集端通常用Filebeat轻量、资源占用小。它的配置文件核心是定位日志文件路径和定义输出目标。一个典型的Java应用日志采集配置filebeat.inputs: - type: filestream enabled: true paths: - /data/logs/app/*.log fields: log_type: java-app fields_under_root: true output.elasticsearch: hosts: [http://node-1:9200, http://node-2:9200, http://node-3:9200] index: java-app-%{yyyy.MM.dd} setup.template.name: java-app setup.template.pattern: java-app-*这里有个经验如果日志文件会有多个来源建议在fields里增加log_type标识后续在Kibana里按字段过滤不同服务的日志体验会好很多。6.2 索引模板统一管理如果采集端直接写Elasticsearch建议先把索引模板配好。索引模板负责约束索引的mapping设置、分片数量、副本数量等避免每个索引都套默认配置。一个基础的模板配置curl -X PUT http://node-1:9200/_index_template/java-app-template -H Content-Type: application/json -d { index_patterns: [java-app-*], template: { settings: { number_of_shards: 3, number_of_replicas: 1 } } }分片数量这里特意提一下。5节点的集群3个数据分片配1个副本总共就是6个分片副本分散在2台数据节点上。分片数量不宜过多过多会让每个分片内的数据量过小查询效率反而下降也不宜过少过少则单分片数据量太大影响均衡分布。具体需要结合数据量估算但默认3个分片对中等规模日志量是比较稳妥的起点。6.3 Logstash是否一定需要接进来我的观点是除非有复杂的数据清洗需求否则能直接用Filebeat写Elasticsearch就别先上Logstash。Filebeat本身可以做简单的字段提取和基础清洗Logstash引入后虽然处理能力强但部署一个Java运行时、配置过滤规则、维护Pipeline都是在增加架构复杂度和资源消耗。如果确实需要Logstash建议单独部署不要和ES节点抢资源。Logstah比较吃内存尤其是grok正则解析复杂日志时CPU消耗也不低。架构上可以让Filebeat输出到LogstashLogstash处理后再输出到Elasticsearch形成完整管道。但在日志量级不大、清洗需求简单的场景下这层管道完全可以暂缓。7. 常见问题与排查技巧实录7.1 集群状态异常问题速查现象可能原因处理方法集群状态为yellow副本分片未分配检查数据节点数量是否足够检查节点磁盘是否达到水位线手动触发reroute集群状态为red主分片未分配查看未分配原因检查节点是否掉线、索引配置是否有误节点之间互不可见network.host配置错误或transport端口不通逐台检查elasticsearch.yml测试9300端口连通性如nc -vz node-2 9300内存使用过高导致OOM堆内存设置过大或查询负载过高调低Xmx检查是否有大批量聚合查询增加节点分担压力磁盘写满后索引只读磁盘水位线触发保护清理旧索引或扩容执行PUT _settings恢复读写脑裂集群出现多个主节点network分区或minimum_master_nodes配置错误修正minimum_master_nodes为2检查网络抖动7.2 启动失败类问题排查“max virtual memory areas vm.max_map_count”错误前面已提sysctl设置后必须确认已写入/etc/sysctl.conf并执行sysctl -p生效。重启服务器后这个参数如果没做持久化还会再报。端口被占用9200或9300被其他进程抢占尤其是9300注意排查其他服务是否占用比如某些应用框架的RPC端口。JVM内存分配失败启动时报“Could not reserve enough space for object heap”一般是机器可用内存小于jvm.options里配置的Xmx值改小内存配置后再启动。引导检查未通过可能因为系统账号权限不对、文件句柄限制未修改启动时日志会明确提示具体哪项check失败按日志处理即可。7.3 数据采集链路问题Filebeat能正常启动但Kibana搜不到数据这种问题排查优先级最高的环节依次是Filebeat输出端是否连通、索引是否生成、索引字段是否符合预期。先看Filebeat状态filebeat test output看output.es.hosts的连通性。然后查Elasticsearch侧有没有生成对应索引curl -s http://node-1:9200/_cat/indices?v | grep java-app如果索引存在但没数据大概率是Filebeat的日志路径没匹配到文件或者fields配置把日志过滤掉了。检查字段名和路径名时要仔细这类问题多数是路径写错或文件名写错。7.4 重启集群的注意事项集群需要重启时尤其是5个节点都要重启建议按“先数据节点、后主节点”的顺序滚动执行并且在重启任一个节点前先确认集群状态为green。如果直接一次性全部宕机再启动由于是全新冷启动主节点需要重新选主并恢复分片分配耗时更长且如果其中有节点数据未同步恢复过程可能触发分片重平衡非常慢。滚动重启期间要留意集群状态变化如果重启过程中出现red或yellow不用慌等所有节点起来后再观察分片会自动迁移。但如果长时间不恢复就要检查是否有分片被卡在“UNASSIGNED”状态用curl -s http://node-1:9200/_cluster/allocation/explain?pretty可以看到具体原因比如磁盘空间不足、分配策略限制、或者分片数据损坏。8. 部署后的监控、备份与运维配套8.1 集群健康监控方案Elasticsearch自身提供_cat/health等REST接口适合做基础监控。最简单的做法是用crontab定时curl采集健康状态状态非green时告警。但如果团队已有监控体系我更建议让Prometheus通过elasticsearch_exporter抓取指标再配Grafana看板可以实时看到分片数、堆内存、JVM GC、磁盘水位等关键指标。几个必须盯紧的指标集群状态green/yellow/red每次变化都要告警堆内存使用率长期超过85%要考虑扩容或优化查询磁盘使用率ES的磁盘水位线默认是85%写入水位线到达后不会自动清理必须主动处理分片数量与状态分片长时间处于initializing或relocating状态说明集群正在做大量迁移要关注是不是有节点不稳定。8.2 数据备份与恢复演练Elasticsearch的数据备份用的是快照接口。配置一个仓库repository然后定期快照。以本地NAS目录为例curl -X PUT http://node-1:9200/_snapshot/my_backup -H Content-Type: application/json -d { type: fs, settings: { location: /opt/es-backup } }创建快照curl -X PUT http://node-1:9200/_snapshot/my_backup/snapshot_20240826?wait_for_completiontrue这里有个坑备份仓库的路径需要在elasticsearch.yml里通过path.repo配置白名单放行否则创建仓库会报错。另外做快照恢复演练时我建议准备一台独立的恢复环境不要在正式集群上直接测试恢复操作避免误覆盖线上数据。恢复命令curl -X POST http://node-1:9200/_snapshot/my_backup/snapshot_20240826/_restore恢复后检查索引状态和文档条数和备份时记录的数量比对确认没有数据丢失。8.3 索引生命周期与容量管理日志类索引的增长速度非常快建议在部署完成的第一天就制定清理策略。可以用Elasticsearch的ILM功能实现按时间或按容量自动滚动、删除。以30天生命周期为例curl -X PUT http://node-1:9200/_ilm/policy/log_ilm_policy -H Content-Type: application/json -d { policy: { phases: { hot: { actions: { rollover: { max_size: 50GB, max_age: 1d } } }, delete: { min_age: 30d, actions: { delete: {} } } } } }再把策略绑定到索引模板上之后生成的索引都会自带这个生命周期策略。这样做的好处是磁盘空间预警和清理工作不用每天手动处理。9. 经验体会与补充建议9.1 节点角色分离带来的运维变化3主2从的架构跑起来之后最大的感受是“角色职责清晰”。主节点专职管集群状态数据节点专职管存储索引排查问题时直接看对应角色的日志就行不用在一堆日志里区分这个节点到底干了什么。特别是集群发生故障时主节点日志里关于分片分配、选主的过程非常清晰数据节点日志则主要围绕分片恢复、段落合并这些操作定位问题快很多。9.2 从这次部署中总结的实战心得部署过程中有几点让我印象比较深。第一系统参数一定在安装软件之前配好否则Elasticsearch安装完启动时报错又要回头改系统配置再重启来回折腾浪费大量时间。第二Kibana的时区设置虽然只是界面配置但第一次看日志时发现时间差8小时可能让你误判问题发生顺序非常影响排障效率。第三集群第一次启动的选主配置非常重要必须一次性配好否则后面改配置要重启节点、可能触发分片重分配风险更大。9.3 最后再分享一个小技巧如果你用systemd管理Elasticsearch启动脚本里记得加上TimeoutStopSec否则集群节点在停机时要等分片自动迁移完才能退出可能长时间卡在“stopping”状态。我一般设置TimeoutStopSec120配合优雅停机流程每次重启节点都很顺滑不会出现被迫kill进程导致分片损坏的情况。这个细节看起来不起眼但在大规模索引场景下能少踩很多坑。