企业官网建设流程全解析

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 的实际门槛

官方给的"最低配置"是能跑起来，不是能用。我按实际经验给一个参考区间：

这里有个很多人忽略的点：内存不是越大越好，而是"堆内存能拿到的部分"越大越好。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_count=262144 # 永久生效，写入 /etc/sysctl.conf echo "vm.max_map_count=262144" | 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 堆一旦被换到磁盘上，垃圾回收会出现长达几秒甚至几十秒的停顿，集群可能被误判为失联。所以生产环境必须关闭 swap：

sudo swapoff -a # 注释掉 /etc/fstab 里所有 swap 行，防止重启后恢复

关掉 swap 之后还有个隐患：如果物理内存真的不够，进程会被内核直接 OOM Killer 干掉，没有任何商量余地。所以关 swap 的前提是你对内存用量有把握，宁可多留余量，也不要赌。

配合关 swap，建议打开bootstrap.memory_lock: true，让 JVM 把堆内存锁在物理内存里，杜绝被换出的可能。但开启这个必须同时满足两个条件：limits.conf 里的memlock设为unlimited，以及 systemd unit 里的LimitMEMLOCK=infinity。否则启动时会报：

memory locking requested for elasticsearch process but memory is not locked

这个报错很有迷惑性，很多人以为是自己配置写错了，其实是系统限制没放开。

另外顺手把透明大页关掉，它会导致不可预测的内存分配延迟：

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

3. Linux 三种安装路径的取舍与 tar.gz 完整实操

Elasticsearch 在 Linux 上有三种主流装法：tar.gz 压缩包、rpm/deb 包管理器、Docker 镜像。它们不是"哪个更好"的关系，而是"哪个更适合你现在的运维方式"。我把取舍逻辑讲清楚，然后重点演示 tar.gz，因为它是通用性最强的，也是最能让你理解整个目录结构和启动流程的。

3.1 三种方式的适用边界

如果你的团队已经有 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] Description=Elasticsearch 7.10.2 After=network.target [Service] Type=simple User=es Group=es LimitNOFILE=65535 LimitNPROC=4096 LimitMEMLOCK=infinity Environment=JAVA_HOME=/usr/local/elasticsearch/jdk ExecStart=/usr/local/elasticsearch/bin/elasticsearch Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target

保存到/etc/systemd/system/elasticsearch.service，然后：

sudo systemctl daemon-reload sudo systemctl enable elasticsearch sudo systemctl start elasticsearch sudo systemctl status elasticsearch

注意LimitMEMLOCK=infinity这一行，它和bootstrap.memory_lock是配套的，少一个就会启动失败。Restart=on-failure让它在异常退出后自动拉起，配合RestartSec=10避免疯狂重启。

一个实战心得：ExecStart里千万不要加-d参数去后台运行。systemd 的Type=simple本来就期望进程在前台跑，加-d会让 systemd 认为服务已经退出，然后反复重启，日志里一片"start request repeated too quickly"。

4. elasticsearch.yml 与 jvm.options：每一项配置背后的理由

配置文件是 Elasticsearch 安装里最容易抄错的部分。网上教程一抓一大把，但很少有人告诉你"这行不写会怎样"。我按"必须改"和"按需改"分开讲，每一条都说明它的作用。

4.1 集群与节点标识

cluster.name: my-application node.name: node-1

cluster.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 的单实例。

改完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 2>&1把输出重定向到文件，这样才能看到完整报错。

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 版 Elasticsearch，vm.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就起不来"的现象特别常见。一旦进入生产模式，下面这些检查会全部跑一遍：

• 是否关闭了 swap
• vm.max_map_count是否达标
• 文件描述符是否够用
• 内存锁定是否真的生效
• 至少一个发现配置是否存在
• 是否运行在 root 用户下
• JDK 版本是否匹配

这些项目里，任何一项不通过，节点都会启动失败。理解了触发条件，你就知道该往哪个方向查了。

6.2 常见报错对照表

我把这几年遇到频率最高的报错整理了一下，方便你直接查表：

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.yml：

server.port: 5601 server.host: "0.0.0.0" elasticsearch.hosts: ["http://192.168.1.10:9200"] i18n.locale: "zh-CN"

i18n.locale设成zh-CN之后界面会变成中文，对不熟悉英文界面的团队来说省不少事。启动方式和 Elasticsearch 类似，Linux 下用bin/kibana，Windows 下用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 写入性能相关的几个开关

日志类场景对写入吞吐的要求远高于对一致性的要求，这时候可以适当放宽一些默认设置：

这些调整都有代价。refresh_interval调大意味着数据写入后要等更久才能被搜到；translog.durability改成async意味着断电时可能丢失最近几秒的数据。只有在你明确知道自己能接受这些代价时才去改，不要看别人调了就跟风。

8.3 监控与日志的日常关注点

Elasticsearch 挂了往往不是突然挂的，之前一定有征兆，只是没人看。几个必看的指标：

• 堆使用率：持续超过 75% 就要警惕，超过 85% 基本离 Full GC 不远了
• GC 耗时：老年代 GC 单次超过 1 秒就该排查
• 磁盘水位：默认 85% 会触发分片迁移，95% 会让索引变成只读
• 线程池队列：write 队列持续增长说明写入跟不上
• 段合并情况：_cat/segments里段数量过多会影响查询

日志方面，主日志在logs/elasticsearch.log，GC 日志在logs/gc.log。GC 日志尤其重要，一旦出现 Full GC，日志里会有明显记录。我给很多团队的建议是：先把 GC 日志接进监控，其他都可以慢慢来，因为它是性能问题最直接的信号来源。

磁盘水位这块有个实操细节值得提一下，很多人被这个惩罚过：磁盘使用率一旦突破默认的高水位线，Elasticsearch 会开始把分片往其他节点搬，如果所有节点都超过水位，分片就无处可去，集群状态会变黄甚至变红。这时候最直接的处理办法不是扩容，而是先清理老索引。所以索引生命周期管理一定要提前做，别等磁盘满了才想起来删数据。

# 删除指定日期的老索引 curl -X DELETE "localhost:9200/logs-2024-01-01" # 或者用索引模板加 ILM 策略自动滚动和清理

我个人在实际运维中的体会是，Elasticsearch 这类系统的稳定性，八成靠的是"提前规划"而不是"事后救火"。分片怎么规划、内存怎么分配、老数据怎么清理、监控看哪些指标，这些在上线前花两个小时想清楚，能省掉后面无数个加班的夜晚。安装本身反而是最简单的部分，难的是把它养好。