Elasticsearch 运维实践
Elasticsearch 常被当作“装好就能搜”的组件，真正上线后才会发现：分片怎么切、堆内存怎么给、写入与查询如何互不拖累，才是运维的日常。本页从极客运维的实战视角，把 ES 拆成集群规划、索引与分片、查询与写入调优、监控与故障处置几个可执行的层面，帮你在自建或托管环境中把搜索服务跑稳。
3
节点角色分层
1:20
堆内存与磁盘参考比
30s
集群健康巡检间隔
7d
慢查询日志保留周期
一、集群规划：先把角色分清楚
小规模集群最容易犯的错误，是让每个节点同时承担 master、data、ingest 全部职责。一旦写入压力上来，master 选举就会被拖慢，集群出现短暂的“假死”。建议至少在逻辑上分离：
- master 节点：3 个专用节点，只负责集群状态，不存数据
- data 节点：承载分片，按热/温分层部署
- coordinating 节点：承接查询聚合，缓解 data 节点压力
- ingest 节点：日志预处理，避免占用 data 资源
二、索引与分片：别让分片数失控
分片不是越多越好。每个分片都是一个 Lucene 实例，占用堆内存与文件句柄。经验上单分片控制在 10GB～50GB，按天滚动的日志索引配合 ILM 生命周期策略，比手工建索引更省心。下面这张表是常见场景的配置参考：
三、写入与查询调优要点
写入侧
- 批量写入控制在 5～15MB 单批，避免过大请求
- 日志场景 refresh_interval 调到 30s 以上
- 关闭不必要的 _source 字段或使用 mapping 精简
- translog 落盘策略按可靠性要求选择
查询侧
- 避免深分页，改用 search_after 或 scroll
- 聚合前先 filter 缩小范围，减少 doc_values 扫描
- 为高频查询字段配置 keyword 子字段
- 开启慢查询日志，定位超过 1s 的语句
四、监控与常见故障处置
ES 自身暴露了 _cluster/health、_nodes/stats、_cat 系列接口，配合 Prometheus 的 elasticsearch_exporter 就能覆盖大部分指标。重点盯住 JVM 老年代使用率、线程池队列、未分配分片数和磁盘水位线。以下是最常见的几类告警与处置思路：
黄色 / 红色状态
先查 _cluster/allocation/explain，多为磁盘水位或节点离线导致副本无法分配。
写入拒绝 rejected
bulk 队列满，通常是分片过少或磁盘 IO 瓶颈，考虑扩容 data 节点或临时降副本。
查询延迟升高
查看慢日志与 hot_threads，常见原因是聚合范围过大或 fielddata 被误开启。
五、常见问题 FAQ
Q：堆内存到底给多少？
A：不超过物理内存的 50%，且不超过 31GB 以避免压缩指针失效；剩余内存留给文件系统缓存。
Q：单节点能不能跑生产？
A：可以，但必须接受无副本、无高可用的事实，建议至少三节点并显式设置 discovery.seed_hosts。
Q：索引重建期间如何不影响线上？
A：使用别名指向索引，重建完成后原子切换别名，旧索引保留一段时间再删除。