这段时间在处理一套日志检索系统的存储底座消息产线那边的数据量涨得比我预期快得多单机Elasticsearch已经被查询和写入压得有点喘不过气。翻了几台空闲机器出来之后决定把ES升级成集群架构正好也把一直欠着的可视化工具补上。于是就有了这次完整的Elasticsearch 7.6.0集群搭建过程顺手配好elasticsearch-head和Kibana前后花了一个周末。这篇内容不是官方文档的复读而是我把三台机器从裸机状态一直搞到Kibana页面正常显示中文界面的全过程。适合正在搞ES集群、准备搭head和Kibana的运维同学也适合后端开发者想在测试环境快速验证一些集群特性。涉及的内容包括版本选择考量、系统参数优化、elasticsearch.yml核心配置逐项拆解、head跨域问题、Kibana汉化等都会把“为什么这么做“讲清楚。1. 为什么选7.6.0以及这次的整体架构设计1.1 版本号背后的取舍很多人问为什么还在用7.6.0这个版本。翻一下版本历史能发现7.x系列里真正经过大规模生产验证、插件生态稳定、社区讨论最多的就是7.6和7.10。7.6.0的分片分配逻辑、节点发现机制、Kibana配套的兼容性都已经非常成熟后面虽然有7.7到7.15的不少新特性但对我们这种以日志检索为核心、不太依赖新功能的场景来说稳定性优先级远远高于新功能。而且7.6.0的Rest API结构干净很多第三方工具和脚本都是围绕7.x这套接口写的踩坑成本低。还有一点很实际Kibana的版本必须和ES严格对应7.6.0的Kibana适配做得比较好中文语言包从这一代开始也很完善。与其追新版本被各种兼容问题绊住不如先在生产需求驱动下把一个稳定组合跑起来。1.2 三节点拓扑与角色分配这次用了三台机器IP分别是192.168.16.101、102、103主机名对应node1、node2、node3。三台机器角色完全一样既是master候选节点也是data节点。很多新手会纠结要不要单独拆master节点出来其实在中小规模集群里三节点同时担任master候选和数据节点是很常见且合理的做法关键是master候选节点数量必须是奇数三台恰好满足可以避免脑裂时的投票僵局。每台机器配置是8核16G内存、500G数据盘对日志检索场景来说属于中等偏上配置。ES堆内存规划为8G留出一部分给操作系统页缓存毕竟Lucene的索引文件读取极度依赖page cache。1.3 elasticsearch-head和Kibana各自是什么角色先说明白这两个工具的关系。elasticsearch-head是一个开源的前端界面工具核心用途是快速查看集群健康状态、节点列表、索引分布以及发一些简单的REST请求做调试。它不负责数据分析更像是一个集群管理驾驶舱。Kibana则是官方出品的可视化分析平台可以查索引数据、做图表、写查询语句功能重得多。我个人的分工习惯是日常排查节点状态、索引分配情况用head因为打开快、信息直观涉及日志检索、DSL调试、看板展示就用Kibana。两者不冲突反而互补。2. 环境准备与系统参数优化2.1 基础环境与目录规划先处理Java环境。ES 7.6.0要求JDK 8或者JDK 11建议直接用JDK 11因为7.6对JDK 11的优化已经比较完善。使用tar包安装JDK解压后配置环境变量。三台机器都按同样的路径规划ES安装在/data/elasticsearch目录下数据文件放在/data/es-data日志放在/data/es-logs。把数据和程序分开是很重要的习惯后面升级ES版本时直接替换程序目录而不用动数据目录能省很多事情。ES从安全角度强制要求不能以root用户运行。需要创建专用用户useradd es passwd es mkdir -p /data/elasticsearch /data/es-data /data/es-logs chown -R es:es /data/elasticsearch /data/es-data /data/es-logs这个创建专用用户的操作不是形式主义ES启动时会检测当前用户如果是root会直接拒绝启动这是它内部的安全保护逻辑。用专用用户还可以在权限分配上做隔离避免日志数据被其他服务误操作。2.2 内核参数与文件句柄设置ES对系统参数有三个硬性要求任何一个不满足启动都会报错或者运行期不稳定。第一个是虚拟内存映射区数量。Lucene在底层大量使用mmap做文件映射如果系统默认的vm.max_map_count值太小会导致内存映射失败。修改/etc/sysctl.confvm.max_map_count262144 sysctl -p第二个是文件句柄上限。ES在运行中会打开大量文件默认的1024完全不够。修改/etc/security/limits.confes soft nofile 65536 es hard nofile 65536 es soft nproc 4096 es hard nproc 4096第三个是内存锁定限制。如果计划开启bootstrap.memory_lock让ES锁定内存防止swap必须让es用户有解锁内存的权限。在limits.conf里再加上es soft memlock unlimited es hard memlock unlimited除了这些还要把三台机器的时间同步做好。集群节点之间如果时钟偏差太大偶尔会出现一些比较诡异的问题。用chrony做时间同步就行还有防火墙方面需要放行9200、9300、5601这三个端口。9200是ES的HTTP接口9300是节点间传输通信端口5601是Kibana的Web端口。开防火墙端口时注意不要只开本机要确保三台机器之间能够互通9300和9200。3. Elasticsearch集群搭建核心全部在配置文件里3.1 下载安装与目录结构从发布页下载elasticsearch-7.6.0-linux-x86_64.tar.gz每个节点都执行同样的解压操作tar -xzf elasticsearch-7.6.0-linux-x86_64.tar.gz -C /data/elasticsearch解压后的目录结构主要有bin、config、lib、modules和plugins。bin目录是启动脚本config目录是配置文件modules里是内置模块。环境和JDK都准备好之后真正需要关心的就是config/elasticsearch.yml和config/jvm.options这两个文件。3.2 elasticsearch.yml核心参数逐项拆解这是集群搭建最关键的环节。以node1的配置为例逐项说明每个参数的意义。cluster.name: es-prod-cluster node.name: node-1 path.data: /data/es-data path.logs: /data/es-logs bootstrap.memory_lock: true network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: [node1:9300, node2:9300, node3:9300] cluster.initial_master_nodes: [node-1, node-2, node-3] gateway.recover_after_nodes: 2cluster.name如果三台机器不一致它们永远不可能组到一个集群里这是最基础的隔离标识。node.name很重要后面在head和Kibana里看到节点名都靠它。network.host这里设置为0.0.0.0表示监听所有网卡。如果只填本机IP其他节点就没办法通过transport端口连过来。很多新手第一次搭集群失败就是卡在这一行。transport.port是节点之间通信的端口9300是默认值注意和9200区分开。9200是HTTP接口接收Rest API请求的9300是内部传输协议节点间的分片复制、状态同步都走9300。discovery.seed_hosts就是所谓的种子节点列表。新节点启动时要通过这个列表里的地址去发现集群里已有的节点。我在这里填的是主机名加端口生产环境建议直接用IP可以省去DNS解析的不确定性。cluster.initial_master_nodes是首次集群引导时的master候选节点列表。这个配置只在整个集群第一次启动时生效万一写错了节点名集群会一直选不出master日志里全是master not discovered之类的报错。gateway.recover_after_nodes这个参数很多人会忽略。它表示集群内达到多少个节点具备数据恢复条件时才开始做分片恢复。三节点集群设置为2可以避免在只有一个节点临时在线的情况下就开始恢复分片减少无谓的数据迁移。除此之外ES作为head的后端还需要在elasticsearch.yml里开启跨域访问http.cors.enabled: true http.cors.allow-origin: *这个配置后面还会再提因为head和ES不在同一个域下浏览器的同源策略会直接拦截跨域请求。node2和node3只需要修改node.name和network.host对应的部分其他配置保持一致这样可以确保集群元数据一致。3.3 JVM堆内存配置编辑config/jvm.options重点看这两个参数-Xms8g -Xmx8gXms和Xmx必须设置成一样目的是让JVM在启动时一次申请完堆内存运行中避免出现堆频繁扩容和缩容带来的性能抖动。堆内存大小建议是物理内存的一半比如16G物理内存就设8G不要贪大。ES的堆不是越大越好超过32G之后JVM的压缩指针会失效性能反而下降这是Lucene底层实现决定了的。剩下的物理内存留给OS page cacheLucene读索引文件主要走page cache这部分内存利用好了查询性能提升非常明显。3.4 启动三节点并验证集群状态先在node1上用es用户启动su - es cd /data/elasticsearch/elasticsearch-7.6.0 nohup bin/elasticsearch /data/es-logs/es-startup.log 21 启动后等十几秒看启动日志是否报错然后检查进程是否还在。接着把node2、node3依次启动每启动一个节点都可以在head或者命令行观察集群的节点数变化。全部启动完成后用curl验证curl http://192.168.16.101:9200/_cluster/health?pretty正常会看到status为greennodes数量为3。{ cluster_name : es-prod-cluster, status : green, number_of_nodes : 3, number_of_data_nodes : 3, active_primary_shards : 0, active_shards : 0, relocating_shards : 0, initializing_shards : 0, unassigned_shards : 0 }看到3个node都注册进来、状态是green说明集群的底层通信、master选举、分片分配都正常了。这一步完成ES集群的核心工作就结束了一大半。4. elasticsearch-head界面搭建4.1 Node环境准备与项目获取elasticsearch-head是一个Node.js项目运行grunt服务。先装Node我建议用v10这个比较稳妥的版本因为head项目有点老直接用最新的Node 16会导致依赖编译失败或者grunt跑不起来。wget https://nodejs.org/dist/v10.24.1/node-v10.24.1-linux-x64.tar.xz tar -xJf node-v10.24.1-linux-x64.tar.xz -C /usr/local ln -s /usr/local/node-v10.24.1-linux-x64/bin/node /usr/local/bin/node ln -s /usr/local/node-v10.24.1-linux-x64/bin/npm /usr/local/bin/npm接下来拉取head项目cd /data git clone https://github.com/mobz/elasticsearch-head.git cd elasticsearch-head npm install -g grunt-cli npm installnpm install这个步骤在某些网络环境会比较慢甚至会出现编译失败。如果遇到node-sass相关的报错多半是Node版本不对果断换Node版本比硬修依赖靠谱。4.2 修改监听配置并解决跨域head默认监听9100端口并且默认绑定localhost。我们希望能通过浏览器从其他机器访问所以需要修改Gruntfile.jsconnect: { server: { options: { hostname: 0.0.0.0, port: 9100, base: ., keepalive: true } } }这一步的实际用途是把head的web服务暴露到局域网。改完保存直接用grunt server启动cd /data/elasticsearch-head grunt server启动完之后在浏览器访问http://192.168.16.101:9100在页面上的连接地址栏输入ES的HTTP地址比如http://192.168.16.101:9200点击连接。这时候如果不做任何额外配置页面大概率是长期转圈或者提示连接失败。问题就出在跨域上。ES没有开启CORS时浏览器会拦截来自9100端口页面的跨域请求。解决方式就是前面提到的在elasticsearch.yml里加http.cors.enabled: true http.cors.allow-origin: *改完配置必须要重启ES节点的进程才能生效。注意是重启三个节点逐个重启不要一次性停完所有节点再启动那样可能会拖慢自动恢复过程。4.3 head页面的常用功能head界面上能直接看到三台节点都显示为绿色左边是节点列表右边是索引列表。点击索引名称可以看到分片的具体分布位置主分片和副本分片分布在哪些节点上。这个功能在排查分片分配不均匀的时候非常实用一眼就能看出是不是某个节点负载过重。head还自带一个简单的数据浏览和请求功能可以输入REST请求然后查看返回结果。我用它做过很多快速的字段验证比如确认某个索引的mapping是否正确。对于不想开Kibana的场景来说head这个轻量工具确实省时省力。不过head也有明显的缺点就是并发能力弱打开一堆索引之后页面会卡顿。所以它更适合做快速巡检和调试而不是日常长时间挂着看监控。5. Kibana搭建与汉化配置5.1 下载安装KibanaKibana的版本必须和ES完全一致这里装的就是7.6.0。下载linux-x86_64版wget https://artifacts.elastic.co/downloads/kibana/kibana-7.6.0-linux-x86_64.tar.gz tar -xzf kibana-7.6.0-linux-x86_64.tar.gz -C /data/elasticsearchKibana不需要专用的系统用户直接用es用户运行都可以。这个工具本质是一个Node.js服务本身不存数据所有数据都从ES读取。5.2 kibana.yml配置与连接ESKibana的配置都在config/kibana.yml。编辑关键几项server.port: 5601 server.host: 0.0.0.0 elasticsearch.hosts: [http://192.168.16.101:9200, http://192.168.16.102:9200, http://192.168.16.103:9200] i18n.locale: zh-CNserver.host同样设置为0.0.0.0否则只能在本机访问5601端口。elasticsearch.hosts这里可以填多个ES地址Kibana会自动发现可用的节点这样当某个ES节点挂掉时Kibana还能通过其他节点继续工作。i18n.locale配置成zh-CN就可以让界面显示中文。7.6.0版本对中文本地化支持已经做得很好从登录页到菜单栏都能完整汉化。启动Kibanacd /data/elasticsearch/kibana-7.6.0-linux-x86_64 nohup bin/kibana /data/es-logs/kibana.log 21 第一次启动可能需要几十秒可以通过日志确认tail -f /data/es-logs/kibana.log看到Kibana is running类似的输出就说明启动成功了。访问http://192.168.16.101:5601如果Kibana成功连上ES会进入首页。如果ES没准备好或者连接信息写错页面会卡在“Kibana server is not ready yet”。5.3 验证Kibana能做什么进入Kibana之后第一件事建议到Dev Tools工具里执行一条查询验证链路GET _cluster/health如果返回green状态说明Kibana到ES的连接链路完全正常。接着可以到Index Management页面看看集群里的索引列表或者去Stack Monitoring看集群的实时监控数据。7.6的Kibana自带监控功能只需要在配置里开启xpack相关的设置。我没在一开始提到xpack是因为这部分属于插件增强不是基础搭建的必要项生产环境需要监控时再配置也不迟。6. 常见问题排查实录与避坑指南6.1 集群起不来或者节点互相看不到这是新手最常见的问题。现象是每个节点都单独起来了但节点列表始终只有一个或者集群一直处于master not discovered的状态。排查优先级建议按这个顺序来先确认三台机器的防火墙确实放行了9200和9300端口。用curl验证一下HTTP端口通不通curl http://192.168.16.102:9200如果HTTP端口通但集群还是组不起来大概率是transport端口9300被堵了。用telnet测9300端口telnet 192.168.16.102 9300然后是检查discovery.seed_hosts里写的主机名能否被正确解析。如果使用的主机名但是DNS并没有配置ES会一直重试发现节点。建议要么在/etc/hosts里补上主机映射要么直接把配置改成IP地址。还有一个非常隐蔽的坑cluster.initial_master_nodes里的名字必须和node.name一模一样多一个空格都会导致选举失败。启动日志中如果看到master not discovered yet多半就是这个问题。6.2 分片无法分配导致集群yellow节点起来了集群却是yellow说明有副本分片没有分配到。常见原因有两个。第一个是设置了副本数量但节点数不够。比如单节点集群里给索引设置了1个副本那永远无法分配副本分片因为副本不能和主分片在同一个节点。解决办法要么再加节点要么把副本数调小。第二个是磁盘空间不足。ES节点默认磁盘水位线是85%超过之后不会再往该节点分配分片。查看磁盘水位curl http://192.168.16.101:9200/_cluster/allocation/explain?pretty这个API会把无法分配的原因直接列出来非常方便。如果确实是因为某个节点临时掉线导致分片未分配可以在节点恢复后执行手动重新分配curl -X POST http://192.168.16.101:9200/_cluster/reroute?pretty \ -H Content-Type: application/json \ -d {commands:[{allocate_stale_primary:{index:logstash-2025.04.01,shard:1,node:node-2,accept_data_loss:true}}]}注意这个操作有数据丢失风险必须确认掉线节点上的数据已经不可用了才建议使用。6.3 Kibana和head连接异常Kibana页面一直提示server is not ready先看ES是否正常在线再确认kibana.yml里elasticsearch.hosts的端口是不是写成了9300。9300是transport端口Kibana走的是HTTP接口必须用9200。head连不上ES的场景除了跨域问题之外还有一个常见原因是ES节点启用了xpack安全认证。如果开启了认证head的老代码不支持带登录态的请求会一直401。如果非要用head要么关掉安全认证要么给head做一层代理并注入认证信息。我的经验是既然上了Kibanahead就用在内网无认证环境最省事。6.4 运行中容易踩到的小坑ES日志中文乱码的问题很多中文服务器上会出现。解决办法是在启动ES前设置系统编码export LANGzh_CN.UTF-8然后重新启动ES。还有内存泄漏方面的坑。如果看到日志里出现OutOfMemoryError或者unable to create native thread先看系统pid或内存上限是不是设置过小了。ES运行久了如果堆内存配置不合理容易出现GC时间过长导致节点被集群踢出。这种问题排查起来费劲最好的办法是提前做好两件事一是堆内存Xms/Xmx保持一致二是给ES进程设置一个合理的线程数限制。另外强烈建议定期查看节点JVM内存使用情况curl http://192.168.16.101:9200/_nodes/stats/jvm?pretty重点关注heap_used_percent长期超过85%就需要考虑扩容堆或者减少节点承载的shard数量。写在最后的一点个人建议整个搭建过程看起来不长但实际做的时候会遇到各种环境差异带来的小问题。我这次最深的体会是搭建集群的核心不是敲命令而是理解每一个配置项的意图尤其是discovery和network这两个模块几乎所有集群组不起来的故障都源于对它们理解不够。如果只打算看一个指标来确认集群健康那一定是_cluster/health返回的status。green不代表性能好但yellow和red一定代表有问题优先把状态修到green再去做性能调优。另外还有一个小建议head这个工具它查问题方便但真的不建议当作长期监控面板来用功能太弱。Kibana里自带的Monitoring页面才是更合适的选择。后续有条件的话建议把ES的冷热数据分层也做起来日志类的索引放到机械盘或者对象存储上能省一大笔成本。
这段时间在处理一套日志检索系统的存储底座消息产线那边的数据量涨得比我预期快得多单机Elasticsearch已经被查询和写入压得有点喘不过气。翻了几台空闲机器出来之后决定把ES升级成集群架构正好也把一直欠着的可视化工具补上。于是就有了这次完整的Elasticsearch 7.6.0集群搭建过程顺手配好elasticsearch-head和Kibana前后花了一个周末。这篇内容不是官方文档的复读而是我把三台机器从裸机状态一直搞到Kibana页面正常显示中文界面的全过程。适合正在搞ES集群、准备搭head和Kibana的运维同学也适合后端开发者想在测试环境快速验证一些集群特性。涉及的内容包括版本选择考量、系统参数优化、elasticsearch.yml核心配置逐项拆解、head跨域问题、Kibana汉化等都会把“为什么这么做“讲清楚。1. 为什么选7.6.0以及这次的整体架构设计1.1 版本号背后的取舍很多人问为什么还在用7.6.0这个版本。翻一下版本历史能发现7.x系列里真正经过大规模生产验证、插件生态稳定、社区讨论最多的就是7.6和7.10。7.6.0的分片分配逻辑、节点发现机制、Kibana配套的兼容性都已经非常成熟后面虽然有7.7到7.15的不少新特性但对我们这种以日志检索为核心、不太依赖新功能的场景来说稳定性优先级远远高于新功能。而且7.6.0的Rest API结构干净很多第三方工具和脚本都是围绕7.x这套接口写的踩坑成本低。还有一点很实际Kibana的版本必须和ES严格对应7.6.0的Kibana适配做得比较好中文语言包从这一代开始也很完善。与其追新版本被各种兼容问题绊住不如先在生产需求驱动下把一个稳定组合跑起来。1.2 三节点拓扑与角色分配这次用了三台机器IP分别是192.168.16.101、102、103主机名对应node1、node2、node3。三台机器角色完全一样既是master候选节点也是data节点。很多新手会纠结要不要单独拆master节点出来其实在中小规模集群里三节点同时担任master候选和数据节点是很常见且合理的做法关键是master候选节点数量必须是奇数三台恰好满足可以避免脑裂时的投票僵局。每台机器配置是8核16G内存、500G数据盘对日志检索场景来说属于中等偏上配置。ES堆内存规划为8G留出一部分给操作系统页缓存毕竟Lucene的索引文件读取极度依赖page cache。1.3 elasticsearch-head和Kibana各自是什么角色先说明白这两个工具的关系。elasticsearch-head是一个开源的前端界面工具核心用途是快速查看集群健康状态、节点列表、索引分布以及发一些简单的REST请求做调试。它不负责数据分析更像是一个集群管理驾驶舱。Kibana则是官方出品的可视化分析平台可以查索引数据、做图表、写查询语句功能重得多。我个人的分工习惯是日常排查节点状态、索引分配情况用head因为打开快、信息直观涉及日志检索、DSL调试、看板展示就用Kibana。两者不冲突反而互补。2. 环境准备与系统参数优化2.1 基础环境与目录规划先处理Java环境。ES 7.6.0要求JDK 8或者JDK 11建议直接用JDK 11因为7.6对JDK 11的优化已经比较完善。使用tar包安装JDK解压后配置环境变量。三台机器都按同样的路径规划ES安装在/data/elasticsearch目录下数据文件放在/data/es-data日志放在/data/es-logs。把数据和程序分开是很重要的习惯后面升级ES版本时直接替换程序目录而不用动数据目录能省很多事情。ES从安全角度强制要求不能以root用户运行。需要创建专用用户useradd es passwd es mkdir -p /data/elasticsearch /data/es-data /data/es-logs chown -R es:es /data/elasticsearch /data/es-data /data/es-logs这个创建专用用户的操作不是形式主义ES启动时会检测当前用户如果是root会直接拒绝启动这是它内部的安全保护逻辑。用专用用户还可以在权限分配上做隔离避免日志数据被其他服务误操作。2.2 内核参数与文件句柄设置ES对系统参数有三个硬性要求任何一个不满足启动都会报错或者运行期不稳定。第一个是虚拟内存映射区数量。Lucene在底层大量使用mmap做文件映射如果系统默认的vm.max_map_count值太小会导致内存映射失败。修改/etc/sysctl.confvm.max_map_count262144 sysctl -p第二个是文件句柄上限。ES在运行中会打开大量文件默认的1024完全不够。修改/etc/security/limits.confes soft nofile 65536 es hard nofile 65536 es soft nproc 4096 es hard nproc 4096第三个是内存锁定限制。如果计划开启bootstrap.memory_lock让ES锁定内存防止swap必须让es用户有解锁内存的权限。在limits.conf里再加上es soft memlock unlimited es hard memlock unlimited除了这些还要把三台机器的时间同步做好。集群节点之间如果时钟偏差太大偶尔会出现一些比较诡异的问题。用chrony做时间同步就行还有防火墙方面需要放行9200、9300、5601这三个端口。9200是ES的HTTP接口9300是节点间传输通信端口5601是Kibana的Web端口。开防火墙端口时注意不要只开本机要确保三台机器之间能够互通9300和9200。3. Elasticsearch集群搭建核心全部在配置文件里3.1 下载安装与目录结构从发布页下载elasticsearch-7.6.0-linux-x86_64.tar.gz每个节点都执行同样的解压操作tar -xzf elasticsearch-7.6.0-linux-x86_64.tar.gz -C /data/elasticsearch解压后的目录结构主要有bin、config、lib、modules和plugins。bin目录是启动脚本config目录是配置文件modules里是内置模块。环境和JDK都准备好之后真正需要关心的就是config/elasticsearch.yml和config/jvm.options这两个文件。3.2 elasticsearch.yml核心参数逐项拆解这是集群搭建最关键的环节。以node1的配置为例逐项说明每个参数的意义。cluster.name: es-prod-cluster node.name: node-1 path.data: /data/es-data path.logs: /data/es-logs bootstrap.memory_lock: true network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: [node1:9300, node2:9300, node3:9300] cluster.initial_master_nodes: [node-1, node-2, node-3] gateway.recover_after_nodes: 2cluster.name如果三台机器不一致它们永远不可能组到一个集群里这是最基础的隔离标识。node.name很重要后面在head和Kibana里看到节点名都靠它。network.host这里设置为0.0.0.0表示监听所有网卡。如果只填本机IP其他节点就没办法通过transport端口连过来。很多新手第一次搭集群失败就是卡在这一行。transport.port是节点之间通信的端口9300是默认值注意和9200区分开。9200是HTTP接口接收Rest API请求的9300是内部传输协议节点间的分片复制、状态同步都走9300。discovery.seed_hosts就是所谓的种子节点列表。新节点启动时要通过这个列表里的地址去发现集群里已有的节点。我在这里填的是主机名加端口生产环境建议直接用IP可以省去DNS解析的不确定性。cluster.initial_master_nodes是首次集群引导时的master候选节点列表。这个配置只在整个集群第一次启动时生效万一写错了节点名集群会一直选不出master日志里全是master not discovered之类的报错。gateway.recover_after_nodes这个参数很多人会忽略。它表示集群内达到多少个节点具备数据恢复条件时才开始做分片恢复。三节点集群设置为2可以避免在只有一个节点临时在线的情况下就开始恢复分片减少无谓的数据迁移。除此之外ES作为head的后端还需要在elasticsearch.yml里开启跨域访问http.cors.enabled: true http.cors.allow-origin: *这个配置后面还会再提因为head和ES不在同一个域下浏览器的同源策略会直接拦截跨域请求。node2和node3只需要修改node.name和network.host对应的部分其他配置保持一致这样可以确保集群元数据一致。3.3 JVM堆内存配置编辑config/jvm.options重点看这两个参数-Xms8g -Xmx8gXms和Xmx必须设置成一样目的是让JVM在启动时一次申请完堆内存运行中避免出现堆频繁扩容和缩容带来的性能抖动。堆内存大小建议是物理内存的一半比如16G物理内存就设8G不要贪大。ES的堆不是越大越好超过32G之后JVM的压缩指针会失效性能反而下降这是Lucene底层实现决定了的。剩下的物理内存留给OS page cacheLucene读索引文件主要走page cache这部分内存利用好了查询性能提升非常明显。3.4 启动三节点并验证集群状态先在node1上用es用户启动su - es cd /data/elasticsearch/elasticsearch-7.6.0 nohup bin/elasticsearch /data/es-logs/es-startup.log 21 启动后等十几秒看启动日志是否报错然后检查进程是否还在。接着把node2、node3依次启动每启动一个节点都可以在head或者命令行观察集群的节点数变化。全部启动完成后用curl验证curl http://192.168.16.101:9200/_cluster/health?pretty正常会看到status为greennodes数量为3。{ cluster_name : es-prod-cluster, status : green, number_of_nodes : 3, number_of_data_nodes : 3, active_primary_shards : 0, active_shards : 0, relocating_shards : 0, initializing_shards : 0, unassigned_shards : 0 }看到3个node都注册进来、状态是green说明集群的底层通信、master选举、分片分配都正常了。这一步完成ES集群的核心工作就结束了一大半。4. elasticsearch-head界面搭建4.1 Node环境准备与项目获取elasticsearch-head是一个Node.js项目运行grunt服务。先装Node我建议用v10这个比较稳妥的版本因为head项目有点老直接用最新的Node 16会导致依赖编译失败或者grunt跑不起来。wget https://nodejs.org/dist/v10.24.1/node-v10.24.1-linux-x64.tar.xz tar -xJf node-v10.24.1-linux-x64.tar.xz -C /usr/local ln -s /usr/local/node-v10.24.1-linux-x64/bin/node /usr/local/bin/node ln -s /usr/local/node-v10.24.1-linux-x64/bin/npm /usr/local/bin/npm接下来拉取head项目cd /data git clone https://github.com/mobz/elasticsearch-head.git cd elasticsearch-head npm install -g grunt-cli npm installnpm install这个步骤在某些网络环境会比较慢甚至会出现编译失败。如果遇到node-sass相关的报错多半是Node版本不对果断换Node版本比硬修依赖靠谱。4.2 修改监听配置并解决跨域head默认监听9100端口并且默认绑定localhost。我们希望能通过浏览器从其他机器访问所以需要修改Gruntfile.jsconnect: { server: { options: { hostname: 0.0.0.0, port: 9100, base: ., keepalive: true } } }这一步的实际用途是把head的web服务暴露到局域网。改完保存直接用grunt server启动cd /data/elasticsearch-head grunt server启动完之后在浏览器访问http://192.168.16.101:9100在页面上的连接地址栏输入ES的HTTP地址比如http://192.168.16.101:9200点击连接。这时候如果不做任何额外配置页面大概率是长期转圈或者提示连接失败。问题就出在跨域上。ES没有开启CORS时浏览器会拦截来自9100端口页面的跨域请求。解决方式就是前面提到的在elasticsearch.yml里加http.cors.enabled: true http.cors.allow-origin: *改完配置必须要重启ES节点的进程才能生效。注意是重启三个节点逐个重启不要一次性停完所有节点再启动那样可能会拖慢自动恢复过程。4.3 head页面的常用功能head界面上能直接看到三台节点都显示为绿色左边是节点列表右边是索引列表。点击索引名称可以看到分片的具体分布位置主分片和副本分片分布在哪些节点上。这个功能在排查分片分配不均匀的时候非常实用一眼就能看出是不是某个节点负载过重。head还自带一个简单的数据浏览和请求功能可以输入REST请求然后查看返回结果。我用它做过很多快速的字段验证比如确认某个索引的mapping是否正确。对于不想开Kibana的场景来说head这个轻量工具确实省时省力。不过head也有明显的缺点就是并发能力弱打开一堆索引之后页面会卡顿。所以它更适合做快速巡检和调试而不是日常长时间挂着看监控。5. Kibana搭建与汉化配置5.1 下载安装KibanaKibana的版本必须和ES完全一致这里装的就是7.6.0。下载linux-x86_64版wget https://artifacts.elastic.co/downloads/kibana/kibana-7.6.0-linux-x86_64.tar.gz tar -xzf kibana-7.6.0-linux-x86_64.tar.gz -C /data/elasticsearchKibana不需要专用的系统用户直接用es用户运行都可以。这个工具本质是一个Node.js服务本身不存数据所有数据都从ES读取。5.2 kibana.yml配置与连接ESKibana的配置都在config/kibana.yml。编辑关键几项server.port: 5601 server.host: 0.0.0.0 elasticsearch.hosts: [http://192.168.16.101:9200, http://192.168.16.102:9200, http://192.168.16.103:9200] i18n.locale: zh-CNserver.host同样设置为0.0.0.0否则只能在本机访问5601端口。elasticsearch.hosts这里可以填多个ES地址Kibana会自动发现可用的节点这样当某个ES节点挂掉时Kibana还能通过其他节点继续工作。i18n.locale配置成zh-CN就可以让界面显示中文。7.6.0版本对中文本地化支持已经做得很好从登录页到菜单栏都能完整汉化。启动Kibanacd /data/elasticsearch/kibana-7.6.0-linux-x86_64 nohup bin/kibana /data/es-logs/kibana.log 21 第一次启动可能需要几十秒可以通过日志确认tail -f /data/es-logs/kibana.log看到Kibana is running类似的输出就说明启动成功了。访问http://192.168.16.101:5601如果Kibana成功连上ES会进入首页。如果ES没准备好或者连接信息写错页面会卡在“Kibana server is not ready yet”。5.3 验证Kibana能做什么进入Kibana之后第一件事建议到Dev Tools工具里执行一条查询验证链路GET _cluster/health如果返回green状态说明Kibana到ES的连接链路完全正常。接着可以到Index Management页面看看集群里的索引列表或者去Stack Monitoring看集群的实时监控数据。7.6的Kibana自带监控功能只需要在配置里开启xpack相关的设置。我没在一开始提到xpack是因为这部分属于插件增强不是基础搭建的必要项生产环境需要监控时再配置也不迟。6. 常见问题排查实录与避坑指南6.1 集群起不来或者节点互相看不到这是新手最常见的问题。现象是每个节点都单独起来了但节点列表始终只有一个或者集群一直处于master not discovered的状态。排查优先级建议按这个顺序来先确认三台机器的防火墙确实放行了9200和9300端口。用curl验证一下HTTP端口通不通curl http://192.168.16.102:9200如果HTTP端口通但集群还是组不起来大概率是transport端口9300被堵了。用telnet测9300端口telnet 192.168.16.102 9300然后是检查discovery.seed_hosts里写的主机名能否被正确解析。如果使用的主机名但是DNS并没有配置ES会一直重试发现节点。建议要么在/etc/hosts里补上主机映射要么直接把配置改成IP地址。还有一个非常隐蔽的坑cluster.initial_master_nodes里的名字必须和node.name一模一样多一个空格都会导致选举失败。启动日志中如果看到master not discovered yet多半就是这个问题。6.2 分片无法分配导致集群yellow节点起来了集群却是yellow说明有副本分片没有分配到。常见原因有两个。第一个是设置了副本数量但节点数不够。比如单节点集群里给索引设置了1个副本那永远无法分配副本分片因为副本不能和主分片在同一个节点。解决办法要么再加节点要么把副本数调小。第二个是磁盘空间不足。ES节点默认磁盘水位线是85%超过之后不会再往该节点分配分片。查看磁盘水位curl http://192.168.16.101:9200/_cluster/allocation/explain?pretty这个API会把无法分配的原因直接列出来非常方便。如果确实是因为某个节点临时掉线导致分片未分配可以在节点恢复后执行手动重新分配curl -X POST http://192.168.16.101:9200/_cluster/reroute?pretty \ -H Content-Type: application/json \ -d {commands:[{allocate_stale_primary:{index:logstash-2025.04.01,shard:1,node:node-2,accept_data_loss:true}}]}注意这个操作有数据丢失风险必须确认掉线节点上的数据已经不可用了才建议使用。6.3 Kibana和head连接异常Kibana页面一直提示server is not ready先看ES是否正常在线再确认kibana.yml里elasticsearch.hosts的端口是不是写成了9300。9300是transport端口Kibana走的是HTTP接口必须用9200。head连不上ES的场景除了跨域问题之外还有一个常见原因是ES节点启用了xpack安全认证。如果开启了认证head的老代码不支持带登录态的请求会一直401。如果非要用head要么关掉安全认证要么给head做一层代理并注入认证信息。我的经验是既然上了Kibanahead就用在内网无认证环境最省事。6.4 运行中容易踩到的小坑ES日志中文乱码的问题很多中文服务器上会出现。解决办法是在启动ES前设置系统编码export LANGzh_CN.UTF-8然后重新启动ES。还有内存泄漏方面的坑。如果看到日志里出现OutOfMemoryError或者unable to create native thread先看系统pid或内存上限是不是设置过小了。ES运行久了如果堆内存配置不合理容易出现GC时间过长导致节点被集群踢出。这种问题排查起来费劲最好的办法是提前做好两件事一是堆内存Xms/Xmx保持一致二是给ES进程设置一个合理的线程数限制。另外强烈建议定期查看节点JVM内存使用情况curl http://192.168.16.101:9200/_nodes/stats/jvm?pretty重点关注heap_used_percent长期超过85%就需要考虑扩容堆或者减少节点承载的shard数量。写在最后的一点个人建议整个搭建过程看起来不长但实际做的时候会遇到各种环境差异带来的小问题。我这次最深的体会是搭建集群的核心不是敲命令而是理解每一个配置项的意图尤其是discovery和network这两个模块几乎所有集群组不起来的故障都源于对它们理解不够。如果只打算看一个指标来确认集群健康那一定是_cluster/health返回的status。green不代表性能好但yellow和red一定代表有问题优先把状态修到green再去做性能调优。另外还有一个小建议head这个工具它查问题方便但真的不建议当作长期监控面板来用功能太弱。Kibana里自带的Monitoring页面才是更合适的选择。后续有条件的话建议把ES的冷热数据分层也做起来日志类的索引放到机械盘或者对象存储上能省一大笔成本。
