1. 7.10.2 这个版本号为什么值得单独写一份手册Elasticsearch 7.10.2 的安装看着就是解压、改配置、启动三步实际动手的人才知道这三步里埋了多少东西。我做检索相关的工作快七年了从 2.x 一路装到 8.x如果要挑一个最值得留在生产环境里、装起来又最不容易出事的小版本7.10.2 一定排在前三。它不是最新版搜索能力也不是最强的但它恰好卡在一个非常特殊的位置上往前是 7.x 的成熟稳定期往后就是授权模型的分水岭。很多团队现在还在用它不是懒是算过账之后觉得没必要动。这篇手册想解决的问题很具体给你一份从裸机到能对外提供检索服务、中间不踩坑的完整路径。我会把每一步为什么这么干讲清楚包括内核参数怎么算、JVM 堆该给多少、配置文件里哪几行不改就启动不了。适合刚接手 ELK 的同学当作起步参考也适合已经在跑但老是被启动报错折腾的人拿来对照排查。1.1 Apache 2.0 授权的最后一个小版本这是 7.10.2 最大的隐形价值。7.11.0 开始Elasticsearch 的默认发行版换成了 Elastic License 和 SSPL 双授权如果你要把它打包进自己的商业产品里对外分发或者做二次开发再发布7.10.2 是最后一个不需要为授权问题发愁的版本。这句话不是法律建议但确实是很多人把它按在版本号上不动的第一个理由。第二个理由更实际新版本里的一些能力比如后面提到的高阶排序融合、部分机器学习相关功能是挂在付费订阅下的。你如果只需要存数据、能搜索、能聚合7.10.2 免费部分给的东西已经非常够用完全没必要为了一个用不上的功能去承担版本升级带来的回归测试成本。我见过一个团队2022 年把集群从 7.10.2 升到 8.x结果两个依赖排序接口的业务线全部报错回滚花了两天。这不是说升级不好而是说版本决策要在装机之前就做完不要装完再纠结。你如果现在就确定未来一年不会用到 8.x 的新特性那 7.10.2 是一个非常省心的落点。1.2 内置 JDK 省掉了最烦人的环境依赖7.10.2 的发行包里自带了一套完整的 JDK解压出来就能跑不需要你系统里预先装 Java。这一点在离线环境里价值极高——你可以把压缩包拷到内网机器上不需要额外准备 Java 安装包也不用担心目标机器上的 JDK 版本是不是符合要求。但这里有个坑必须提前说它并不是无条件使用内置 JDK。如果你的系统环境变量里已经设了JAVA_HOME并且指向了一个别的版本Elasticsearch 有可能拿着那个 JDK 去跑然后因为版本校验不通过而启动失败报错信息通常是什么 Java version mismatch 或者一连串的模块加载异常。最稳妥的做法是在启动脚本里显式把JAVA_HOME指向发行包内部的jdk目录把系统环境的不确定性完全排除掉。# 假设解压到了 /usr/local/elasticsearch export JAVA_HOME/usr/local/elasticsearch/jdk export PATH$JAVA_HOME/bin:$PATH写进/etc/profile.d/elasticsearch.sh每次都生效比手动敲一遍可靠得多。1.3 什么情况下别硬上 7.10.2说句实话如果你的场景是高并发日志检索、每天几十 TB 的写入量或者是需要向量检索、原生 RRF 这类较新的能力那 7.10.2 不是你的最优解该用新版本就用新版本付费订阅该买就买别为了省那点成本让整个检索层拖着业务走。7.10.2 真正舒服的定位是中小规模业务检索、内网知识库、日志归档分析、教学和自研项目的底层引擎以及那些已经稳定运行、没有强升级诉求的存量集群。技术选型没有最优只有最合适把这个想明白后面所有安装细节才有意义。2. 装之前把操作系统底座调到能接住 Elasticsearch大部分人装 Elasticsearch 失败不是因为配置写错了而是因为操作系统层面根本没准备好。Elasticsearch 是个吃文件句柄、吃内存映射、吃线程数的进程Linux 默认的那套限制是给普通应用设计的对它来说太紧了。我习惯把这个环节叫打地基地基没打好后面改配置文件改到天亮也没用。2.1 内存、磁盘、CPU 的实际门槛官方给的最低配置是能跑起来不是能用。我按实际经验给一个参考区间场景内存CPU磁盘单机学习、功能验证4 GB2 核20 GB SSD小规模业务检索16 GB4 核100 GB SSD中等规模日志分析32 GB 起8 核500 GB 以上 SSD生产集群每节点64 GB 起16 核按数据量规划这里有个很多人忽略的点内存不是越大越好而是堆内存能拿到的部分越大越好。Elasticsearch 本身是一个 JVM 进程它用的是堆内存但除此之外文件系统缓存要占用剩下的物理内存来加速段文件读取这部分内存由操作系统管理堆给得太多反而会挤压文件缓存导致查询变慢。所以内存规划的核心是堆和文件缓存各占一半而不是能把堆给多大就给多大。磁盘方面机械盘不是不能用但你会明显感觉到查询延迟上去了尤其是做聚合的时候。如果预算允许SSD 是硬性建议如果只能用机械盘就把数据和日志分到不同物理盘上减少 IO 争抢。2.2 vm.max_map_count 到底在管什么这是新手最容易撞的一个报错max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]要理解它得先知道 Elasticsearch 的存储结构。它把数据切成一个个不可变的段文件然后通过内存映射的方式把这些文件映射到虚拟地址空间里这样查询的时候可以像访问内存一样访问文件避免反复的系统调用。每个映射都要在虚拟内存区域表里占一个条目而 Linux 默认允许的条目数是 65530。索引一多、段一多65530 立刻就不够了。所以官方推荐 262144这不是拍脑袋的数字是留了足够余量之后的经验值。改法很简单# 临时生效 sudo sysctl -w vm.max_map_count262144 # 永久生效写入 /etc/sysctl.conf echo vm.max_map_count262144 | sudo tee -a /etc/sysctl.conf sudo sysctl -p改完用sysctl vm.max_map_count确认一下。注意Docker 容器内的这个值继承自宿主机所以如果你在 Windows 上用 WSL2 跑也是要改 WSL 内核参数的容器里改没有用。2.3 文件句柄和线程数两个容易被忽略的软限制第二个高频报错是文件描述符不够max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]Elasticsearch 每个分片、每个段、每个网络连接都占文件描述符默认的 1024 或 4096 根本扛不住。修改方式是在/etc/security/limits.conf里加es soft nofile 65535 es hard nofile 65535 es soft memlock unlimited es hard memlock unlimited es soft nproc 4096 es hard nproc 4096这里es是运行 Elasticsearch 的系统用户名你得先建这个用户。memlock那一行是为后面开启内存锁定准备的nproc控制线程数Elasticsearch 的线程池模型会创建不少线程4096 是比较稳妥的值。注意limits.conf对通过 systemd 启动的服务不生效。因为 systemd 有自己的资源控制体系你要在 unit 文件里用LimitNOFILE、LimitMEMLOCK、LimitNPROC再设一遍。这个坑我踩过改完 limits.conf 重启机器还是报错查了半天才发现是 systemd 绕过了。2.4 关掉 swap 和内存锁定Swap 对 Elasticsearch 来说是灾难。JVM 堆一旦被换到磁盘上垃圾回收会出现长达几秒甚至几十秒的停顿集群可能被误判为失联。所以生产环境必须关闭 swapsudo swapoff -a # 注释掉 /etc/fstab 里所有 swap 行防止重启后恢复关掉 swap 之后还有个隐患如果物理内存真的不够进程会被内核直接 OOM Killer 干掉没有任何商量余地。所以关 swap 的前提是你对内存用量有把握宁可多留余量也不要赌。配合关 swap建议打开bootstrap.memory_lock: true让 JVM 把堆内存锁在物理内存里杜绝被换出的可能。但开启这个必须同时满足两个条件limits.conf 里的memlock设为unlimited以及 systemd unit 里的LimitMEMLOCKinfinity。否则启动时会报memory locking requested for elasticsearch process but memory is not locked这个报错很有迷惑性很多人以为是自己配置写错了其实是系统限制没放开。另外顺手把透明大页关掉它会导致不可预测的内存分配延迟echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled3. Linux 三种安装路径的取舍与 tar.gz 完整实操Elasticsearch 在 Linux 上有三种主流装法tar.gz 压缩包、rpm/deb 包管理器、Docker 镜像。它们不是哪个更好的关系而是哪个更适合你现在的运维方式。我把取舍逻辑讲清楚然后重点演示 tar.gz因为它是通用性最强的也是最能让你理解整个目录结构和启动流程的。3.1 三种方式的适用边界安装方式适合场景优点代价tar.gz单机部署、离线环境、需要自定义目录完全可控、迁移方便服务化、开机自启要自己配rpm/deb已有包管理体系、批量运维自动注册为系统服务、目录规范目录固定、卸载残留要清查Docker快速验证、编排环境环境隔离、启动快内核参数依赖宿主机、持久化要额外处理如果你的团队已经有 Ansible、SaltStack 这类配置管理工具rpm 包会更省事如果只是验证一个功能Docker 最快但如果你想真正搞清楚 Elasticsearch 的目录结构和启动链路我建议至少用 tar.gz 完整走一遍。3.2 建用户、解压、改属主第一步也是必须做的一步不要用 root 运行。Elasticsearch 启动时会主动检查运行用户如果是 root 会直接拒绝启动这是为了防止以过高权限运行带来的风险。sudo useradd -m -s /bin/bash es sudo passwd es # 上传压缩包后解压 sudo tar -zxvf elasticsearch-7.10.2-linux-x86_64.tar.gz -C /usr/local/ sudo mv /usr/local/elasticsearch-7.10.2 /usr/local/elasticsearch sudo chown -R es:es /usr/local/elasticsearch目录放哪儿有讲究。我一般把程序放在/usr/local/elasticsearch把数据目录和日志目录单独指向大容量数据盘比如/data/elasticsearch/data。理由是程序升级、重装的时候数据不用动风险小很多。3.3 目录结构里哪几个是重点解压后你会看到这么几个关键目录我按重要性排一下config/放elasticsearch.yml、jvm.options、log4j2.properties是你要改最多的地方data/默认的数据目录生产环境建议改到独立磁盘logs/日志目录包含主日志和 GC 日志jdk/内置的 Java 运行时别删plugins/插件目录后面装中文分词器会用到bin/启动脚本和各类命令工具bin/目录里那些可执行文件值得单独记一下日常运维基本靠它们elasticsearch主进程elasticsearch-plugin插件管理elasticsearch-setup-passwords初始化内置用户密码elasticsearch-certutil证书生成工具elasticsearch-syskeygen、elasticsearch-shard等辅助工具3.4 配一个靠谱的 systemd 服务tar.gz 装完最大的问题就是怎么让它开机自启、怎么优雅重启。答案是写一个 systemd unit 文件[Unit] DescriptionElasticsearch 7.10.2 Afternetwork.target [Service] Typesimple Useres Groupes LimitNOFILE65535 LimitNPROC4096 LimitMEMLOCKinfinity EnvironmentJAVA_HOME/usr/local/elasticsearch/jdk ExecStart/usr/local/elasticsearch/bin/elasticsearch Restarton-failure RestartSec10 [Install] WantedBymulti-user.target保存到/etc/systemd/system/elasticsearch.service然后sudo systemctl daemon-reload sudo systemctl enable elasticsearch sudo systemctl start elasticsearch sudo systemctl status elasticsearch注意LimitMEMLOCKinfinity这一行它和bootstrap.memory_lock是配套的少一个就会启动失败。Restarton-failure让它在异常退出后自动拉起配合RestartSec10避免疯狂重启。一个实战心得ExecStart里千万不要加-d参数去后台运行。systemd 的Typesimple本来就期望进程在前台跑加-d会让 systemd 认为服务已经退出然后反复重启日志里一片start request repeated too quickly。4. elasticsearch.yml 与 jvm.options每一项配置背后的理由配置文件是 Elasticsearch 安装里最容易抄错的部分。网上教程一抓一大把但很少有人告诉你这行不写会怎样。我按必须改和按需改分开讲每一条都说明它的作用。4.1 集群与节点标识cluster.name: my-application node.name: node-1cluster.name是集群的身份证。同一个网络里有多个集群时同名节点会自动尝试组队所以名字一定要区分开尤其在开发环境和测试环境混在同一个网段的公司里这个坑踩一次能让你怀疑人生——明明只启了一个节点日志里却出现了另一个集群的节点信息。node.name是节点标识默认取主机名。如果你用容器或云主机主机名可能是一串随机字符串出问题的时候日志里根本分不清是哪台建议显式指定成有意义的名字比如es-data-01。4.2 网络绑定与发现机制network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: [192.168.1.10:9300, 192.168.1.11:9300] cluster.initial_master_nodes: [node-1, node-2, node-3]network.host从默认的localhost改成0.0.0.0或者具体网卡地址这一步会直接触发生产模式进而启用 bootstrap checks 校验。也就是说你一旦让外部能访问Elasticsearch 就会用生产环境的标准来要求你前面那些内核参数没改好这时候就会集中报错。这是设计上的保护理解这一点后面排查就顺了。discovery.seed_hosts是节点发现用的7.x 里取代了旧的discovery.zen.ping.unicast.hosts。它列出的是集群里其他节点的地址注意这里用的是传输端口 9300不是 9200。cluster.initial_master_nodes是 7.x 引入的集群引导机制只在集群第一次启动时使用。它的作用是防止脑裂新集群在没有历史状态的情况下必须由你显式指定哪些节点有资格参与首轮主节点选举不能靠自动发现随便凑。等集群跑起来、元数据落盘之后这一行就可以删掉了留着反而有风险——如果某个节点数据被清空重启它会以为自己是个新集群。单机测试环境可以简化discovery.type: single-node这个配置一写Elasticsearch 就以单节点模式启动不做主节点选举也不用配上面那一堆发现参数。但生产环境绝对不能用它因为它建立的是一个永远不会扩容的集群。4.3 数据与日志路径path.data: /data/elasticsearch/data path.logs: /data/elasticsearch/logs默认路径在安装目录下面方便但危险——一旦你重装或升级的时候手滑删了整个目录数据就没了。另外还有个实际的性能问题数据目录和日志目录在同一块盘上会互相抢 IO日志写入频繁的时候会明显影响索引性能。有条件就分开挂载。给目录做完chown -R es:es之后别忘了检查上层目录的权限/data/elasticsearch这一级也需要es用户可写否则启动时会报权限拒绝。4.4 JVM 堆内存为什么不是越大越好config/jvm.options里最关键的两行-Xms8g -Xmx8g几个原则都是我实际验证过的第一-Xms和-Xmx必须设成一样大。如果不一样JVM 会动态调整堆大小每次调整都会触发一次 Full GC在高负载下这种停顿是致命的。第二堆不要超过物理内存的 50%。剩下的内存要留给文件系统缓存Lucene 的段文件读取极度依赖它。你把 64 GB 内存全给堆查询反而会变慢因为每次读段文件都要走磁盘 IO。第三单节点堆不要超过 31 GB 左右。这里涉及 JVM 的指针压缩优化当堆小于约 32 GB 时对象引用可以用 4 字节表示超过之后必须用 8 字节反而浪费内存实际可用容量可能还不如 31 GB。所以如果你有一台 128 GB 的机器宁可跑两个 31 GB 的实例也不要配一个 64 GB 的单实例。物理内存建议堆大小8 GB4 GB16 GB8 GB32 GB16 GB64 GB31 GB128 GB两个实例各 31 GB改完jvm.options必须重启才生效这点和elasticsearch.yml里的动态配置不一样别搞混。5. Windows 环境启动 Elasticsearch 的完整流程与坑点在 Windows 上装 Elasticsearch 的人比想象中多很多是为了本地开发调接口、做小规模测试。流程比 Linux 简单但坑的形态完全不一样而且报错信息经常让人摸不着头脑。5.1 免安装包直接启动从官网下载 Windows 版的 zip 包解压到一个纯英文、无空格、路径尽量短的目录比如D:\elasticsearch-7.10.2。这一条不是废话中文路径和带空格的路径会引发各种诡异问题包括插件加载失败、日志写入异常。然后双击bin\elasticsearch.bat。第一次启动会比较慢因为要初始化数据目录。看到控制台出现started字样并且没有异常堆栈就说明起来了。浏览器访问http://localhost:9200应该能看到一段 JSON包含name、cluster_name、version等信息。如果控制台一闪就没了说明启动过程中出错了。别用双击打开命令行进入bin目录执行elasticsearch.bat或者用elasticsearch.bat out.log 21把输出重定向到文件这样才能看到完整报错。5.2 装成 Windows 服务如果不想每次手动开窗口可以注册成服务cd D:\elasticsearch-7.10.2\bin elasticsearch-service.bat install elasticsearch-service.bat start管理界面可以这样打开elasticsearch-service.bat manager装成服务之后有个必须注意的点内存配置要在管理器里单独设。Windows 服务版本的 JVM 参数不完全走jvm.options它有一部分存在注册表里通过图形化的 manager 工具调整堆大小才可靠。我见过不少人改了jvm.options里的-Xmx重启服务后发现内存根本没变就是因为这个原因。5.3 Windows 上的几个典型坑坑一Native controller 进程启动失败。报错通常是Native controller process has stopped - no new native processes can be started。这个多半是内存不足或者分片数太多导致的先检查堆是不是给了太小比如给了 512 MB再看是不是创建了几百个索引。坑二Windows Defender 拖慢性能。实时扫描会把 Elasticsearch 的数据目录和日志目录反复扫一遍直接影响写入吞吐。建议把这两个目录加入排除列表这是微软官方也认可的做法。坑三WSL2 里的内核参数。如果你是在 WSL2 里跑 Linux 版 Elasticsearchvm.max_map_count这个限制是存在的需要在 WSL 配置里设置而不是在 Windows 侧设置。这个点很多人不知道一直以为是安装包有问题。坑四端口占用。如果本机已经跑了一个 Elasticsearch再启一个会报BindException: Address already in use。用netstat -ano | findstr 9200找到占用进程决定是停掉还是给新实例换个端口。在 Windows 上做开发验证我建议只开单节点配discovery.type: single-node同时把堆设成 2 GB 左右就够了没必要照搬生产配置。6. 启动后的自检、报错排查与 bootstrap checks服务起来了不等于装好了。Elasticsearch 的启动报错有个特点它不会一次把所有问题都告诉你而是修好一个再报下一个。所以排查要有耐心也要有顺序。6.1 bootstrap checks 什么时候会触发很多人以为 bootstrap checks 是启动检查其实它有个前提条件只有当节点绑定到非回环地址时才会强制执行。如果network.host还是localhost就算你的内核参数没改好它也只是在日志里给个警告development 模式不阻止启动。这就是为什么本地测试好好的一改network.host就起不来的现象特别常见。一旦进入生产模式下面这些检查会全部跑一遍是否关闭了 swapvm.max_map_count是否达标文件描述符是否够用内存锁定是否真的生效至少一个发现配置是否存在是否运行在 root 用户下JDK 版本是否匹配这些项目里任何一项不通过节点都会启动失败。理解了触发条件你就知道该往哪个方向查了。6.2 常见报错对照表我把这几年遇到频率最高的报错整理了一下方便你直接查表报错关键字根本原因处理方式vm.max_map_count is too low内存映射区域不足修改 sysctl 参数max file descriptors is too low文件句柄限制太紧改 limits.conf 和 systemd LimitNOFILEmemory locking requested but not lockedmemlock 未放开改 memlock 与 LimitMEMLOCKdefault discovery settings are unsuitable缺发现配置补discovery.seed_hosts和cluster.initial_master_nodescan not run elasticsearch as root用 root 启动切换到普通用户Address already in use端口被占换端口或停掉占用进程Java version mismatchJAVA_HOME 指向了别的 JDK显式指向包内 jdk 目录failed to obtain node locks同一数据目录被两个实例占用检查是否有残留进程No space left on device磁盘满了清理数据或扩容log4j相关警告日志组件版本提示通常不影响但需关注6.3 起得来之后的健康检查清单服务能启动只是第一关还要确认集群状态正常。按顺序执行这几条# 查看集群健康状态 curl -X GET localhost:9200/_cluster/health?pretty # 查看节点列表和角色分配 curl -X GET localhost:9200/_cat/nodes?v # 查看索引列表 curl -X GET localhost:9200/_cat/indices?v # 查看分片分配情况 curl -X GET localhost:9200/_cat/shards?v单节点环境下集群状态通常是yellow这是正常的。原因是7.x 默认每个索引有 1 个主分片和 1 个副本分片副本必须分配到不同于主分片的节点上单节点没有第二个节点可用所以副本处于未分配状态。如果你希望单节点也是green把索引的副本数设为 0 即可curl -X PUT localhost:9200/my-index/_settings -H Content-Type: application/json -d { index: { number_of_replicas: 0 } }反过来如果你在多节点集群上看到red那就要重视了说明有主分片未分配可能涉及数据丢失需要去看_cluster/allocation/explain的输出。一个容易忽略的点_cat/indices里头部的.开头的索引是系统索引比如.kibana、.security别手贱删。7. 中文分词插件与 Kibana 配套单装一个 Elasticsearch对中文的处理能力是很弱的。默认的标准分词器会把一整句中文按字符切开或者干脆当成一个词检索效果差得离谱。所以要能用还得装中文分词插件再配上 Kibana 做可视化和查询界面。7.1 中文分词插件的正确安装方式插件版本必须和 Elasticsearch 版本严格一致7.10.2 的插件只能装在 7.10.2 上面差一个小版本都可能报版本校验错误。这一点没有例外。安装流程是先把插件压缩包下载到本地然后用自带工具安装cd /usr/local/elasticsearch bin/elasticsearch-plugin install file:///tmp/elasticsearch-analysis-ik-7.10.2.zip用file://前缀指向本地文件比直接用网络地址稳尤其在内网环境里。安装过程中会提示是否继续输入y回车。装完之后必须重启节点才生效。验证是否装上了bin/elasticsearch-plugin list看到插件名出现在列表里就说明成功。然后开一个测试索引指定分词器看看效果curl -X POST localhost:9200/_analyze -H Content-Type: application/json -d { analyzer: ik_max_word, text: 中华人民共和国国歌 }如果返回的 token 是中华人民共和国中华人民中华华人共和国这样的组合说明分词器工作正常。这里两个分词模式的区别值得记一下ik_max_word会把文本切得尽可能细适合建立索引时用能提高召回率ik_smart切得比较粗适合查询时用能提高准确率。常见的配置组合是索引用ik_max_word查询用ik_smart两者配合能兼顾召回和精度。如果插件装了但分词结果还是老样子检查一下映射里有没有显式指定分词器。光装插件不会自动改变已有字段的行为必须建索引时声明{ mappings: { properties: { title: { type: text, analyzer: ik_max_word, search_analyzer: ik_smart } } } }7.2 Kibana 的版本对齐与对接Kibana 的版本必须和 Elasticsearch 完全一致7.10.2 只能配 7.10.2这个限制比插件还严格。装好之后改config/kibana.ymlserver.port: 5601 server.host: 0.0.0.0 elasticsearch.hosts: [http://192.168.1.10:9200] i18n.locale: zh-CNi18n.locale设成zh-CN之后界面会变成中文对不熟悉英文界面的团队来说省不少事。启动方式和 Elasticsearch 类似Linux 下用bin/kibanaWindows 下用bin\kibana.bat。如果 Elasticsearch 那边开启了安全认证Kibana 还得配账号elasticsearch.username: kibana_system elasticsearch.password: 你的密码注意这里用的不是elastic超级用户而是专门的kibana_system角色权限最小化是更好的实践。7.3 安全认证到底开不开7.10.2 的默认发行版里安全功能是默认开启的。也就是说你第一次启动之后访问接口可能会被要求认证。这时候有两种选择。一种是认真配置用bin/elasticsearch-setup-passwords interactive依次给内置用户设密码然后用账号密码访问。这是生产环境该走的路密码强度、证书、传输加密都配齐别偷懒。另一种是内网测试环境图省事直接关掉xpack.security.enabled: false关掉之后接口裸奔谁都能访问能建索引也能删索引。这个配置绝对不能出现在对公网开放或者办公网互通的环境里。我见过太多因为图方便关掉认证、结果数据被误删的案例事后复盘都后悔当初没花那半小时配密码。8. 上生产前的调优清单装完能跑和能扛住生产流量中间还差一段距离。我把上线前一定会过一遍的几项整理出来都是投入产出比较高的。8.1 分片规划定错了改不回来这是最需要提前想清楚的一件事。主分片数在索引创建之后无法修改只能通过重建索引来调整。所以创建之前一定要算一下。经验公式大致是单个分片的大小控制在 10 GB 到 50 GB 之间。太小会导致分片数量爆炸集群元数据压力大太大则单分片恢复慢一个分片出问题影响面广。假设你的索引每天产生 30 GB 数据保留 30 天总共 900 GB按每分片 30 GB 算需要 30 个主分片。这个数字不能再往下压也不能设得太碎。新版本默认每个索引 1 个主分片这个默认值对日志场景来说偏小需要手工指定。curl -X PUT localhost:9200/logs-2024-01 -H Content-Type: application/json -d { settings: { number_of_shards: 6, number_of_replicas: 1 } }副本数倒是可以随时改所以不用太纠结单节点先设 0扩成多节点再调上去。8.2 写入性能相关的几个开关日志类场景对写入吞吐的要求远高于对一致性的要求这时候可以适当放宽一些默认设置配置项默认值调整建议作用index.refresh_interval1s30s减少段合并频率提升写入index.translog.durabilityrequestasync降低每次写入的同步开销index.translog.sync_interval5s30s配合上一项使用index.number_of_replicas1视集群规模减少副本写入开销这些调整都有代价。refresh_interval调大意味着数据写入后要等更久才能被搜到translog.durability改成async意味着断电时可能丢失最近几秒的数据。只有在你明确知道自己能接受这些代价时才去改不要看别人调了就跟风。8.3 监控与日志的日常关注点Elasticsearch 挂了往往不是突然挂的之前一定有征兆只是没人看。几个必看的指标堆使用率持续超过 75% 就要警惕超过 85% 基本离 Full GC 不远了GC 耗时老年代 GC 单次超过 1 秒就该排查磁盘水位默认 85% 会触发分片迁移95% 会让索引变成只读线程池队列write 队列持续增长说明写入跟不上段合并情况_cat/segments里段数量过多会影响查询日志方面主日志在logs/elasticsearch.logGC 日志在logs/gc.log。GC 日志尤其重要一旦出现 Full GC日志里会有明显记录。我给很多团队的建议是先把 GC 日志接进监控其他都可以慢慢来因为它是性能问题最直接的信号来源。磁盘水位这块有个实操细节值得提一下很多人被这个惩罚过磁盘使用率一旦突破默认的高水位线Elasticsearch 会开始把分片往其他节点搬如果所有节点都超过水位分片就无处可去集群状态会变黄甚至变红。这时候最直接的处理办法不是扩容而是先清理老索引。所以索引生命周期管理一定要提前做别等磁盘满了才想起来删数据。# 删除指定日期的老索引 curl -X DELETE localhost:9200/logs-2024-01-01 # 或者用索引模板加 ILM 策略自动滚动和清理我个人在实际运维中的体会是Elasticsearch 这类系统的稳定性八成靠的是提前规划而不是事后救火。分片怎么规划、内存怎么分配、老数据怎么清理、监控看哪些指标这些在上线前花两个小时想清楚能省掉后面无数个加班的夜晚。安装本身反而是最简单的部分难的是把它养好。