ElasticSearch 运维

🚀 ElasticSearch 运维指南（生产环境必备）

内容覆盖：

集群规划
配置优化（写、查、内存、GC）
监控指南
常见故障排查
索引管理最佳实践
备份与恢复（快照）
磁盘、分片、JVM 调优
安全与权限配置
Kubernetes 部署建议
高可用架构示例

1. 集群规划（核心）

节点类型

生产必须拆分角色：

类型	作用	推荐配置
master	管理集群元数据	CPU低、内存低、稳定即可
data	存储+搜索+写入	高 CPU + 高 IO + 大内存
ingest	pipeline、logstash 替代	适量
coordinating	路由查询负载	可选

推荐配置：

3 master（奇数）
若干 data node（2+）
可选 1~2 coordinating

避免 master/data 混用（大规模更易故障）。

2. 生产配置（最关键部分）

修改 elasticsearch.yml 时 不要乱改上百个参数，生产只关注下面核心配置。

2.1 Java Heap 配置（非常关键）

-Xms16g
-Xmx16g

原则：

固定 heap，不要让 ES 自动扩容
Heap ≈ 物理内存的 50%
不超过 32GB（超过 32GB 会关闭压缩指针 OOP，性能骤降）

2.2 避免 swap（强制）

bootstrap.memory_lock: true

并设置：

ulimit -l unlimited

2.3 分片数量（核心）

单 shard 30~50GB 最优。

常用公式：

shards = ceil(总数据量 / 40GB)

错误示例：

单索引 1TB + 1 分片（太大）
单索引 50GB + 20 分片（太乱）

2.4 生产必须禁用自动创建索引

action.auto_create_index: false

避免写错索引名导致野生索引。

2.5 最优 refresh_interval

日志场景：

refresh_interval: 30s

搜索实时性要求低：

refresh_interval: 10s

默认 1s 会导致写入压力巨大！！

2.6 translog 优化

高写入量推荐：

index.translog.durability: async
index.translog.sync_interval: 30s

写日志系统（ELK）非常好用。

2.7 写入性能优化

启用吞吐模式：

index.number_of_replicas: 0
refresh_interval: 30s

写入完成后再设置为：

number_of_replicas: 1
refresh_interval: 1s

3. 监控（可观测性）

3.1 必须监控的指标

节点层面

JVM heap 使用率（>75%不健康）
GC 时间（Full GC 说明堆太大）
CPU
IO 延迟
Disk 使用率（90% 会导致只读）

集群层面

cluster health（red/yellow/green）
unassigned shards 数量
indexing throughput（写入速率）
search latency（TP50/TP95）
segment merges 耗时

3.2 Kibana 监控

安装 X-Pack -> Monitoring -> Node / Index / Cluster

3.3 Prometheus + Grafana

使用 exporter：

prometheus-elasticsearch-exporter

核心 dashboard：

JVM heap
indexing rate / search rate
segment merge
cache hit ratio

4. 常见故障排查（最实用部分）

4.1 RED 状态

通常原因：

分片丢失
节点宕机
副本无法分配 -> 机器空间不够
磁盘 > 90% -> ES 自动只读

解决：

GET _cluster/allocation/explain

4.2 分片无法分配（最常见）

原因：

节点磁盘不足
节点角色不匹配
设置了 shard allocation filtering

恢复：

PUT _cluster/settings
{
  "transient": {"cluster.routing.allocation.enable": "all"}
}

4.3 写入报错：FORBIDDEN/12/index read-only / allow delete

原因：磁盘超过 90% 阈值

解除：

PUT */_settings
{
  "index.blocks.read_only_allow_delete": false
}

4.4 查询耗时高

常见原因：

深度分页 from=100000
过多 wildcard 查询
nested 数量巨大
聚合过多 bucket
keyword 字段未开启 doc_values（默认开启）

4.5 写入慢

原因：

refresh_interval 太小
replica 太多
shard 太多
merge 过程过多

5. 索引管理最佳实践

5.1 不要一个索引永远增长

日志类索引必须滚动：

命名方式：

logs-2025.01.01
logs-2025.01.02

使用 Index Lifecycle Management（ILM）：

{
  "policy": {
    "phases": {
      "hot": { "actions": { "rollover": { "max_age": "1d", "max_size": "40GB" } }},
      "warm": { "actions": { "forcemerge": {"max_num_segments": 1 }}},
      "cold": {},
      "delete": { "actions": { "delete": {"min_age": "30d"} }}
    }
  }
}

5.2 mapping 必须提前设计，禁止动态 mapping

index.mapper.dynamic: false

避免字段爆炸（field explosion）。

6. 备份与恢复（Snapshot）

ES 自带 snapshot（非常强大）。

1 注册仓库

PUT _snapshot/my_backup
{
  "type": "fs",
  "settings": {
    "location": "/data/es-backup"
  }
}

2. 创建快照

PUT _snapshot/my_backup/snap-20250101

3. 恢复

POST _snapshot/my_backup/snap-20250101/_restore

7. 磁盘调优

文件描述符

ulimit -n 65536

禁用 swap

swapoff -a

挂载 ext4/xfs（推荐）

禁用 atime

8. 安全与权限

启用 xpack（ES 8 默认开启）：

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true

创建用户角色：

POST /_security/user/admin

权限粒度支持 index-level / field-level。

9. Kubernetes 部署建议（重点推荐）

推荐结构：

3x master StatefulSet
n x data StatefulSet
1~2 x coordinating Deployment

必须配置：

anti-affinity（避免 master 放同一节点）
local storage or SSD
设置 JVM heap
readiness/liveness probes
nodeSelector（固定节点）

数据节点 StatefulSet Volume：

volumeClaimTemplates:
  - name: data
    storageClassName: local-ssd
    resources:
      requests:
        storage: 500Gi

10. 高可用参考架构（生产）

3 x dedicated master (2CPU/4G)
6 x data node (8CPU/32G/SSD)
1 x coordinating node
1 x machine for kibana
1 x machine for logstash / ingest