Elasticsearch 超大日志流量集群搭建（网关 + 独立 Master + 独立 Data 纯生产架构，角色完全分离，百万级日志吞吐）

一.背景

由于业务的场景是超大日志的收集和分析，日志采集 / 日志分析 / ELK 海量日志链路，特点是：写入吞吐量极高、日志存储量巨大、查询聚合频繁，对ES集群的稳定性、写入性能、存储扩展性要求极致。

日志场景是 「写入吞吐优先、海量存储优先、高并发查询」，如果 Master / 网关 / Data 角色混部，会出现

• 日志写入的高 IO / 高 CPU 会抢占 Master 节点的资源 → Master 节点心跳超时、集群元数据处理卡顿，引发集群状态异常、分片分配失败、脑裂 等致命问题；

• 海量客户端（Filebeat/Logstash）的日志写入请求直接打在 Data 节点 → Data 节点既要处理请求分发，又要存储数据，性能被严重消耗，写入吞吐量暴跌；

• 角色混部的集群，在日志流量峰值时，极易出现GC 频繁、节点宕机、集群雪崩。

角色分离后：各司其职，性能互不影响，集群稳定性拉满，写入吞吐量能提升 3~5 倍，是支撑「大日志流量」的唯一正确选择。

二.ES集群的角色规划

搭建的集群，严格分为 4 类节点( Master-eligible、data/ingest/coordinating**)，物理完全分离，无任何角色重叠**，所有节点各司其职，这是企业级海量日志集群的标准范式。具体规划如下

• 3 台 Master：集群大脑，纯管控，无数据，保障集群稳定；
• 2 台 Coor 网关：集群入口，纯转发，无数据，承接所有日志流量；
• ≥4 台 Data：集群核心，纯存储，处理读写，承载海量日志；
• 2 台 Ingest：日志清洗，纯预处理，提升写入性能。

1.独立【候选主节点 (Master-eligible)】 - 集群大脑，纯管控，无数据

• 角色配置 ：只开启master角色，关闭 data/ingest/coordinating` 所有其他角色；
• 核心职责：仅负责集群元数据管理、主节点选举、分片分配、节点上下线管理、集群状态维护，不存储任何日志数据、不处理任何读写请求、不承接任何客户端请求；
• 资源占用：极低（CPU / 内存 / 磁盘），只需要保障稳定性，不需要高性能配置；
• 数量要求：固定 3 台，不可多不可少 → 集群高可用的核心，选举出 1 个活跃主节点，另外 2 台为备用，防止主节点宕机导致集群瘫痪；奇数个节点可以杜绝脑裂问题。
• 日志场景核心价值：彻底隔离日志流量的冲击，Master 节点不受任何写入 / 查询影响，集群元数据绝对稳定，这是大流量下集群不崩的核心保障。

2.独立【数据节点 (Data)】 - 集群苦力，纯存储 + 读写，日志核心载体

• 角色配置 ：只开启data角色，关闭 master/ingest` 角色，默认保留轻量协调节点能力（仅内部分片请求分发）；
• 核心职责：唯一存储日志数据的节点、处理所有日志的「写入 / 查询 / 聚合 / 检索」请求，是集群的性能核心、存储核心、资源核心；
• 资源占用：极高（内存 / CPU / 磁盘 IO），日志的所有写入和查询压力都集中在这里；
• 数量要求：无上限，按需扩容 → 日志量越大、写入吞吐越高，需要的 Data 节点越多，本次建议最少 4 台起步，后续可无缝扩容到几十台；
• 日志场景核心价值：专注日志存储和读写，无任何管控压力，最大化发挥硬件性能，支撑百万级日志写入、TB/PB 级日志存储，是承载大日志流量的核心。

3.独立【协调节点 (Coordinating Only)】 - 集群网关，纯请求转发，流量入口

• 角色配置：关闭 master/data/ingest 所有角色，只保留「协调节点」能力（默认开启，无需配置），也叫专用网关节点；
• 核心职责：集群的唯一入口，承接所有客户端的日志写入请求（Filebeat/Logstash/ 业务服务）和查询请求，不存储任何数据、不参与集群选举、不处理数据读写；仅做「请求分发 + 结果聚合」：收到请求后，根据分片分布，把请求转发到对应 Data 节点，再汇总所有 Data 节点的返回结果，统一返回给客户端；
• 资源占用：中高（CPU / 内存），主要消耗在请求分发和结果聚合，无磁盘压力；
• 数量要求：2 台及以上 → 负载均衡 + 高可用，防止网关节点单点故障，所有日志流量全部经过网关节点进入集群；
• 日志场景核心价值：核心流量网关，隔离客户端与 Data 节点，所有日志写入请求先经过网关分发，避免海量客户端直接连接 Data 节点导致连接数打满；网关节点可以做请求限流、负载均衡，是大日志流量的「缓冲池」，极大降低 Data 节点的连接压力。

4.可选【预处理节点 (Ingest)】 - 日志清洗机，纯数据预处理（日志场景强烈推荐）

• 角色配置 ：只开启ingest角色，关闭其他所有角色；
• 核心职责 ：日志写入 ES 前的数据预处理：日志字段过滤、格式转换、时间戳修正、敏感信息脱敏、新增 / 删除字段、日志拆分 / 合并等；
• 日志场景核心价值：把日志清洗的压力从 Data 节点剥离，Data 节点只负责纯存储和读写，进一步提升写入吞吐量，百万级日志场景必加，建议 2 台。

三.日志场景核心硬件配置

ES 是「内存密集型 + IO 密集型」中间件，日志场景对 内存、磁盘 IO、CPU 要求极高，硬件配置直接决定集群的吞吐能力和稳定性，以下是「最低生产标准」，预算充足建议高配，性能提升立竿见影。

• Master 节点（3 台）：CPU：4 核 ｜ 内存：8G ｜ 磁盘：100G SSD（仅存集群元数据，无日志）｜ 网卡：千兆
• Coordinating 网关节点（2 台）：CPU：8 核 ｜ 内存：16G ｜ 磁盘：100G SSD ｜ 网卡：千兆 / 万兆（大流量必上万兆）
• Data 数据节点（≥4 台） ：CPU：16 核及以上 ｜ 内存：32G 及以上 ｜ 磁盘：1T*4 SSD RAID0 ｜ 网卡：万兆 → 【日志核心】，SSD 是机械硬盘的 10 倍 IO，万兆网卡保障大流量传输，内存越大，缓存越多，写入性能越高；磁盘越大，存储日志越多。
• Ingest 预处理节点（2 台，可选）：CPU：8 核 ｜ 内存：16G ｜ 磁盘：100G SSD ｜ 网卡：万兆

四.ES集群安装

1.操作系统初始化（所有节点必执行，一键脚本，启动 ES 的前置条件）

Elasticsearch 对 Linux 系统的内核参数、文件句柄、线程数、swap 分区有强制要求，不做这些配置，ES 直接启动失败，或启动后频繁崩溃，所有节点（Master / 网关 / Data/Ingest）都要逐行执行以下命令，一键完成初始化，无需手动修改

# 1. 永久关闭防火墙+SELINUX
systemctl stop firewalld && systemctl disable firewalld
sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
setenforce 0

# 2. 永久禁用swap分区（ES强制要求，swap开启会导致性能暴跌+OOM）
swapoff -a && sed -i '/swap/s/^/#/' /etc/fstab

# 3. 修改系统文件句柄和线程数限制（ES需要大量文件句柄和线程）
cat >> /etc/security/limits.conf <<EOF
* soft nofile 655350
* hard nofile 655350
* soft nproc 40960
* hard nproc 40960
elastic soft memlock unlimited
elastic hard memlock unlimited
EOF

# 4. 修改内核参数（ES核心优化，必须配置）
cat >> /etc/sysctl.conf <<EOF
vm.max_map_count=262144
net.ipv4.ip_local_port_range=1024 65535
net.core.somaxconn=65535
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_fin_timeout=30
EOF
sysctl -p

# 5. 创建ES专用运行用户（ES禁止ROOT启动，必建）
useradd elastic
echo "Es@123456" | passwd --stdin elastic

# 6. 时间同步（日志场景必做，防止日志时序错乱）
yum install ntpdate -y && ntpdate ntp1.aliyun.com
echo "*/5 * * * * ntpdate ntp1.aliyun.com" >> /var/spool/cron/root && crontab -l

2.软件版安装

所有节点 下载解压 ES 安装包（7.17.9 LTS 稳定版，统一版本）

# 所有节点执行，统一安装目录
cd /usr/local
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.17.9-linux-x86_64.tar.gz
tar -zxvf elasticsearch-7.17.9-linux-x86_64.tar.gz
mv elasticsearch-7.17.9 es
chown -R elastic:elastic /usr/local/es
chmod -R 755 /usr/local/es

3.各个角色配置

• 整个集群的 cluster.name 必须完全一致，这是节点组成集群的唯一标识；
• 每个节点的 node.name 必须唯一 ，建议命名规则：master-01/coor-01/data-01，便于识别；
• discovery.seed_hosts 填写 所有 Master 节点的 IP 地址，仅 Master 节点参与集群发现和选举，这是角色分离的核心；
• cluster.initial_master_nodes 仅集群第一次启动时需要配置，填写所有 Master 节点 IP，后续扩容无需修改；
• 所有节点的 network.host 填写本机真实内网 IP，禁止填写 0.0.0.0；
• 所有节点的配置文件：/usr/local/es/config/elasticsearch.yml，修改后保存，仅首次配置需要修改，后续无需变动。

配置一：独立【Master 候选主节点】（3 台，配置完全一致，仅 node.name 不同），

# ===================== Elasticsearch Master 节点配置 =====================
cluster.name: es-log-cluster  # 集群名称，所有节点必须一致
node.name: master-01           # 节点名，master-01/master-02/master-03 依次修改
node.roles: [master]           # 核心：仅开启MASTER角色，关闭所有其他角色
node.master: true
node.data: false
node.ingest: false
node.ml: false
xpack.ml.enabled: false
xpack.security.enabled: false  # 关闭安全认证，生产可按需开启

network.host: 10.10.1.10     # 本机真实IP，对应修改
http.port: 9200
transport.port: 9300

# 集群发现：仅填写3台Master节点的IP，核心！！！
discovery.seed_hosts: ["10.10.1.10", "10.10.1.11", "10.10.1.12"]
# 集群初始化主节点列表，仅首次启动需要，填写所有Master节点IP
cluster.initial_master_nodes: ["10.10.1.10", "10.10.1.11", "10.10.1.12"]

# 跨域开启（Kibana/Head插件连接必开）
http.cors.enabled: true
http.cors.allow-origin: "*"

# Master节点核心优化：低负载，高稳定
node.max_local_storage_nodes: 1
cluster.routing.allocation.cluster_concurrent_rebalance: 1
cluster.routing.allocation.node_concurrent_recoveries: 1

核心：只开启 master 角色，关闭所有其他角色，纯管控，无数据

配置二：独立【Coordinating 网关节点】（2 台，配置完全一致，仅 node.name 不同）

# ===================== Elasticsearch Coor网关节点配置 =====================
cluster.name: es-log-cluster  # 集群名称，和Master一致
node.name: coor-01             # 节点名，coor-01/coor-02 依次修改
node.roles: []                 # 核心：关闭所有角色，纯协调节点
node.master: false
node.data: false
node.ingest: false
node.ml: false
xpack.ml.enabled: false
xpack.security.enabled: false

network.host: 10.10.1.20    # 本机真实IP，对应修改
http.port: 9200
transport.port: 9300

# 集群发现：填写3台Master节点的IP，网关节点通过Master加入集群
discovery.seed_hosts: ["10.10.1.10", "10.10.1.11", "10.10.1.12"]

# 跨域开启
http.cors.enabled: true
http.cors.allow-origin: "*"

# 网关节点核心优化：高并发请求分发，调大线程池
thread_pool.search.size: 16
thread_pool.write.size: 16
thread_pool.bulk.size: 32      # 日志场景核心：批量写入线程池调大，支撑大日志批量写入

核心：关闭所有角色，仅保留协调节点能力，纯网关，无数据，无管控

配置 3：独立【Data 数据节点】（≥4 台，配置完全一致，仅 node.name 不同）

# ===================== Elasticsearch Data数据节点配置 =====================
cluster.name: es-log-cluster  # 集群名称，和Master一致
node.name: data-01             # 节点名，data-01/data-02/data-03/data-04 依次修改
node.roles: [data]             # 核心：仅开启DATA角色，关闭所有其他角色
node.master: false
node.data: true
node.ingest: false
node.ml: false
xpack.ml.enabled: false
xpack.security.enabled: false

network.host: 10.10.1.30    # 本机真实IP，对应修改
http.port: 9200
transport.port: 9300

# 集群发现：填写3台Master节点的IP，数据节点通过Master加入集群
discovery.seed_hosts: ["10.10.1.10", "10.10.1.11", "10.10.1.12"]

# 跨域开启
http.cors.enabled: true
http.cors.allow-origin: "*"

# ===================== 日志场景 核心性能优化（重中之重，必配）=====================
# 1. 磁盘水位线：日志场景磁盘使用率高，调大水位线，避免提前触发只读保护
cluster.routing.allocation.disk.watermark.low: 85%
cluster.routing.allocation.disk.watermark.high: 90%
cluster.routing.allocation.disk.watermark.flood_stage: 95%
cluster.info.update.interval: 1m

# 2. 批量写入优化：日志都是批量写入，调大批量处理参数，提升写入吞吐量
indices.bulk.size: 100mb
indices.bulk.concurrent_streams: 8

# 3. 内存缓存优化：调大索引缓冲区，提升写入性能
indices.memory.index_buffer_size: 20%
indices.fielddata.cache.size: 20%

# 4. 线程池优化：调大读写线程池，支撑高并发
thread_pool.search.size: 32
thread_pool.write.size: 32
thread_pool.bulk.size: 64      # 核心：批量写入线程池拉满，百万日志写入核心配置

# 5. 分片恢复优化：节点重启后快速恢复分片，不影响写入
cluster.routing.allocation.node_concurrent_recoveries: 8
indices.recovery.max_bytes_per_sec: 100mb

核心：只开启 data 角色，关闭 master 角色，纯存储 + 读写，日志核心载体，日志场景所有性能优化都集中在这里。

配置 4：可选【Ingest 预处理节点】（2 台，日志场景强烈推荐，配置完全一致）

cluster.name: es-log-cluster
node.name: ingest-01
node.roles: [ingest]
node.master: false
node.data: false
network.host: 10.10.1.40
http.port: 9200
transport.port: 9300
discovery.seed_hosts: ["10.10.1.10", "10.10.1.11", "10.10.1.12"]
http.cors.enabled: true
http.cors.allow-origin: "*"
xpack.security.enabled: false

核心：只开启 ingest 角色，关闭其他所有角色，纯日志清洗

五.集群启动

严格的启动顺序（重中之重，角色分离集群必须遵守），ES 集群的启动有强依赖关系，必须按照「先启动管控节点，再启动业务节点」的顺序执行，否则节点无法加入集群、集群状态异常，严格执行以下顺序。

第一步：启动 3台 Master节点 → 等待3台全部启动完成（约30秒）

第二步：启动 2台 Coor网关节点 → 等待网关节点加入集群

第三步：启动 所有Data数据节点 → 日志核心节点，启动后集群开始提供存储服务

第四步：启动 2台 Ingest预处理节点（可选）

服务启动命令如下（所有节点）

su elastic
cd /usr/local/es
# 后台启动ES，日志输出到logs目录，生产推荐方式
./bin/elasticsearch -d
# 验证启动成功：查看9200端口是否监听
netstat -tulpn | grep 9200

查看集群状态

# 网关节点IP：192.168.1.20
# 验证1：查看集群健康状态 → 必须返回 green 绿色，最优状态
curl http://10.10.1.20:9200/_cluster/health?pretty

# 验证2：查看集群所有节点信息 → 能看到所有Master/Coor/Data/Ingest节点，状态都是up
curl http://10.10.1.20:9200/_cat/nodes?v

# 验证3：查看集群详细信息 → 确认角色分配正确，分片数正常
curl http://10.10.1.20:9200/_cluster/state?pretty

正常的集群返回结果如下

{
  "cluster_name" : "es-log-cluster",
  "status" : "green",       //必须是green
  "number_of_nodes" : 9,    //节点数=3Master+2Coor+4Data 正确
  "number_of_data_nodes" : 4, //数据节点数正确
  "active_primary_shards" : 0,
  "active_shards" : 0,
  "unassigned_shards" : 0,  //无未分配分片
  "active_shards_percent_as_number" : 100.0
}

六.日志场景专属：集群优化 + 索引最佳实践（百万日志吞吐核心，必配）

搭建好集群只是基础，想要支撑「大日志流量」，必须对 ES 做日志场景的专属优化，这部分是「能否扛住大流量」的核心，所有配置都是生产环境百万日志场景的实战经验.

日志索引的核心配置（创建索引时必配，写入性能提升 3 倍）

日志的特点是：写多读少、时序存储、按时间查询、过期删除，ES 索引的默认配置不适合日志，必须按以下规则创建索引，核心是「合理分片 + 合理副本 + 时序索引 + 关闭无用功能」：

分片数设计（日志场景黄金法则）

• 主分片数：每个 Data 节点配置 2~3 个主分片 → 4 台 Data 节点，建议索引主分片数 = 8~12；
• 副本分片数：生产建议 1 个副本 → 兼顾高可用和存储成本，日志场景不建议多副本（写入性能会下降）；
• 核心原则：主分片数一旦创建不可修改，副本数可动态调整。

日志索引最优创建模板

# 网关节点执行，创建日志专用索引 log-2026-01
curl -XPUT http://10.10.1.20:9200/log-nginx-2026-01 -H 'Content-Type: application/json' -d '{
  "settings": {
    "number_of_shards": 8,    # 主分片8个，适配4台Data节点
    "number_of_replicas": 1,  # 副本1个，高可用
    "refresh_interval": "30s",# 核心：刷新间隔调大，默认1s，日志场景30s足够，写入性能暴增
    "translog.durability": "async", # 异步刷盘，提升写入性能，日志场景允许少量数据丢失
    "translog.sync_interval": "5s",
    "index.codec": "best_compression", # 开启极致压缩，日志存储量减少50%，查询性能无影响
    "max_result_window": 10000
  },
  "mappings": {
    "_source": {"enabled": true},
    "properties": {
      "log_time": {"type": "date", "format": "yyyy-MM-dd HH:mm:ss"},
      "log_level": {"type": "keyword"},
      "service_name": {"type": "keyword"},
      "content": {"type": "text"},
      "ip": {"type": "keyword"}
    }
  }
}'

使用规范

• 按时间创建索引 ：比如 log-2026-01、log-2026-02，按月 / 按天拆分，便于过期删除，避免单索引过大；
• 开启索引生命周期管理（ILM）：自动实现「日志写入→分片滚动→过期删除」，无需手动维护，百万日志场景必用；
• 关闭字段分词 ：日志中的大部分字段（IP、服务名、日志级别）用keyword类型，不分词，提升查询性能；
• 合理设置刷新间隔 ：refresh_interval=30s，是日志场景的黄金配置，写入性能提升 3 倍以上。
• 所有日志采集客户端（Filebeat/Logstash）必须连接网关节点，配置负载均衡；
• 开启批量写入 ：Filebeat/Logstash 的批量大小设置为 1000~5000，批量请求大小设置为 10~50MB；
• 日志写入用 bulk API，这是 ES 最高效的写入方式，日志场景 99% 的写入都是 bulk 请求。
• 所有客户端必须连接网关节点，禁止直连 Master/Data；
• Master 节点只做管控，不碰任何数据和请求；
• Data 节点专注日志存储和读写，所有性能优化都集中在这里；
• 日志索引按时间拆分，开启压缩和异步刷盘，提升写入性能。

七.集群扩容（日志场景核心需求，无缝扩容，零停机）

日志量会持续增长，集群扩容是必然需求，ES 集群支持无缝水平扩容，零停机，业务无感知，扩容步骤极其简单：

1. 扩容 Data 节点：新增服务器→系统初始化→配置 Data 节点 yml→启动节点→自动加入集群→ES 自动分片均衡，完成扩容；
2. 扩容网关节点：新增服务器→配置 Coor 节点 yml→启动节点→客户端增加新网关 IP 即可；
3. Master 节点无需扩容，3 台足够支撑任何规模的集群。