当前位置：首页 > news >正文

ES101系列09 | 运维、监控与性能优化

news 2025/6/7 17:33:08

本篇文章主要讲解 ElasticSearch 中 DevOps 与性能优化的内容，包括集群部署最佳实践、容量规划、读写性能优化和缓存、熔断器等。

集群部署最佳实践

在生产环境中建议设置单一角色的节点。

Dedicated master eligible nodes：负责集群状态的管理。使用低配置的 CPU，RAM 和磁盘。
Dedicated data nodes：负责数据存储及处理客户端请求使用高配置的 CPU，RAM 和磁盘。
Dedicated ingest nodes：负责数据处理使用高配置 CPU，中等配置的 RAM，低配置的磁盘。

从高可用 & 避免脑裂的角度出发，一般生产环境需要配置 3 台 Delicate Master Node。

拓展方式

当磁盘容量无法满足需求时，可以增加数据节点；磁盘读写压力大时，增加数据节点。
当系统中有大量的复杂查询及聚合时候，增加 Coordinating 节点，增加查询的性能。

Hot & Warm Architecture

Hot & Warm Architecture
- 数据通常不会有 Update 操作；适用于 Time based 索引数据（生命周期管理），同时数据量比较大的场景。
- 引入 Warm 节点，低配置大容量的机器存放老数据，以降低部署成本。
两类数据节点，不同的硬件配置
- Hot 节点（通常使用 SSD）：索引有不断有新文档写入。通常使用 SSD。
- Warm 节点（通常使用 HDD）：索引不存在新数据的写入；同时也不存在大量的数据查询。

分片设计

单个分片

7.0 开始，新创建一个索引时，默认只有一个主分片。
- 单个分片，查询算分，聚合不准的问题都可以得以避免。
单个索引，单个分片时候，集群无法实现水平扩展。
- 即使增加新的节点，无法实现水平扩展。

两个分片

新增节点后，ElasticSearch 会自动进行分片的移动（Shard Rebalancing）。也就实现了水平拓展。

如何设计分片数

当分片数＞节点数时
- 一旦集群中有新的数据节点加入，分片就可以自动进行分配。
- 分片在重新分配时，系统不会有 downtime。
多分片的好处：一索引如果分布在不同的节点，多个节点可以并行执行
- 查询可以并行执行。
- 数据写入可以分散到多个机器。

如何确定主分片数

从存储的物理角度看
- 日志类应用，单个分片不要大于 50GB
- 搜索类应用，单个分片不要超过 20GB
为什么要控制分片存储大小
- 提高 Update 的性能
- Merge 时，减少所需的资源
- 丢失节点后，具备更快的恢复速度/便于分片在集群内 Rebalancing

如何确定副本分片数

副本是主分片的拷贝
- 提高系统可用性：相应查询请求，防止数据丢失。
- 需要占用和主分片一样的资源。
对性能的影响
- 副本会降低数据的索引速度：有几份副本就会有几倍的 CPU 资源消耗在索引上。
- 会减缓对主分片的查询压力，但是会消耗同样的内存资源。
  - 如果机器资源充分，提高副本数，可以提高整体的查询 QPS。

集群容量规划

一个集群总共需要多少个节点？一个索引需要设置几个分片?
- 规划上需要保持一定的余量，当负载出现波动，节点出现丢失时，还能正常运行。
做容量规划时，一些需要考虑的因素
- 机器的软硬件配置。
- 单条文档的尺寸 / 文档的总数据量 / 索引的总数据量（Time base 数据保留的时间）/ 副本分片数。
- 文档是如何写入的（Bulk 的尺寸)。
- 文档的复杂度，文档是如何进行读取的（怎么样的查询和聚合）。

业务性能评估

数据呑吐及性能需求
- 数据写入的吞吐量，每秒要求写入多少数据？
- 查询的吞吐量？
- 单条查询可接受的最大返回时间？
了解你的数据
- 数据的格式和数据的 Mapping。
- 实际的查询和聚合长的是什么样的。

硬件配置

数据节点尽量用 SSD。
日志类或并发查询低的场景可以用机械硬盘。
单节点数据控制在 2TB 以内，最高不超过 5TB。
JVM 配置机器内存的一半，不建议超过 32G。

集群扩容

增加 Coordinating / Ingest Node
- 解决 CPU 和内存开销的问题。
增加数据节点
- 解决存储的容量的问题。
- 为避免分片分布不均的问题，要提前监控磁盘空间，提前清理数据或增加节点（70%）。

监控 & 排查 API

类别	API 路径	核心用途	关键返回字段说明	生产环境关注点
集群健康	`GET /_cluster/health`	集群整体状态概览	`status`(green/yellow/red), `unassigned_shards`, `active_shards_percent`	红色状态立即处理；黄色状态检查未分配分片
节点资源	`GET /_nodes/stats`	节点级资源监控	`heap_used_percent`, `cpu.percent`, `disk_free_percent`	Heap >75% 需扩容；磁盘<20% 需清理或扩容
索引性能	`GET /_cat/indices?v`	索引存储与文档统计	`docs.count`, `store.size`, `pri.store.size`	分片数合理性；定期清理无用索引
慢查询定位	`GET /_search?pretty&q=slow`	定位高延迟请求	`took` 时间（需预设慢日志阈值）	优化 `took` >1s 的查询/索引设计
线程池积压	`GET /_cat/thread_pool?v`	线程队列监控	`search.queue`, `write.queue`	队列>0 表示资源瓶颈，需扩容或限流
分片分布	`GET /_cat/shards?v`	分片负载均衡检测	`node`, `state`, `store`	均衡分片分布；避免单节点负载过高
任务监控	`GET /_tasks?detailed`	长任务跟踪	`running_time_in_nanos`, `description`	监控耗时任务（如 reindex），避免阻塞集群
磁盘水位	`GET /_cat/allocation?v`	节点磁盘使用率	`disk.avail`, `disk.used`	预警 `disk.avail` <30% 的节点
Segment 状态	`GET /_cat/segments?v`	索引碎片监控	`segment.count`, `size`	过多小 segment 增加 Heap 压力；触发 `force_merge` 需谨慎
JVM 状态	`GET /_nodes/stats/jvm`	垃圾回收监控	`young.collection_count`, `old.collection_time_in_millis`	Young GC >2 次/秒或 Old GC >10 秒/次需调优堆大小

关键监控指标 API 详解

集群健康 (/_cluster/health)
- status: red 表示主分片缺失（数据丢失风险）
- unassigned_shards 常见原因：节点离线或分片分配规则冲突。

节点资源 (/_nodes/stats)

JVM Heap 示例：

"jvm": { "mem": { "heap_used_percent": 65 } }

持续>75% 需扩容或优化内存（如减少 fielddata/cache）。

线程池积压 (/_cat/thread_pool)

node2 search 8 0 8 0 # search.queue=8 表示队列积压

queue>0 需扩容或优化查询并发度。

慢查询阈值配置

在 elasticsearch.yml 中设置：

index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s

生产环境排查流程建议

集群异常 → 用 GET /_cluster/allocation/explain 定位未分配分片原因。
节点负载高 → 执行 GET /_nodes/hot_threads 抓取热点线程栈。
查询延迟 → 使用 GET /_search?profile=true 分析执行计划。
磁盘告警 → 优先清理大型临时索引或扩容冷节点。

分片没有被分配的一些原因

INDEX_CREATE：创建索引导致。在索引的全部分片分配完成之前，会有短暂的 Red，不一定代表有问题。
CLUSTER_RECOVER：集群重启阶段会有这个问题。
INDEX_REOPEN：Open 一个之前 Close 的索引。
DANGLING_INDEX_IMPORTED：一个节点离开集群期间，有索引被删除。这个节点重新返回时，会导致问题。

集群变红的常见问题与解决方法

集群变红，需要检查是否有节点离线。如果有，通常通过重启离线的节点可以解决问题。
由于配置导致的问题，需要修复相关的配置（例如错误的 box_type，错误的副本数）。如果是测试的索引，可以直接删除。
因为磁盘空间限制，分片规则（ShardFiltering）引发的，需要调整规则或者增加节点。

读写性能优化

写性能优化

目标增大写吞吐量，越高越好。

客户端：多线程批量写，通过性能测试确定最佳并发度。
服务端：
- 使用更好的硬件，观察 CPU / IO Block。
- 降低 IO 操作，使用 ES 自动生成文档 id。
- 降低 CPU 和存储开销，减少不必要的分词。
- 尽可能做到写入和分片的均衡负载，实现水平扩展。

一切优化都基于高质量的数据建模。

Bulk、线程池和队列大小

客户端
- 单个 bulk 请求体的数据量不要太大，官方建议大约 5-15mb。
- 写入端的 bulk 请求超时需要足够长，建议 60s 以上。
- 写入端尽量将数据轮询打到不同节点。
服务器端
- 索引创建属于计算密集型任务，应该使用固定大小的线程池来配置。来不及处理的放入队列，线程数应该配置成 CPU 核心数 +1，避免过多的上下文切换。
- 队列大小可以适当增加，不要过大，否则占用的内存会成为 GC 的负担。

读性能优化

尽可能 Denormalize 数据，从而获取最佳的性能。

避免查询的时候使用脚本。
避免使用通配符开头的正则。
控制聚合的数量。

优化分片

避免 Over Sharding。
控制单个分片的大小，查询场景尽量 20GB 以内。
将只读的索引进行 force merge。

段合并优化

ES 和 Lucene 会自动进行 Merge 操作，该操作较重，需要优化降低对系统的影响。

降低分段产生的数量/频率

可以将 Refresh Interval 调整到分钟级别。
尽量避免文档的更新操作。

降低最大分段大小，避免较大的分段继续参与 Merge，节省系统资源。

Index.merge.policy.max_merged_segment 默认 5GB，操作此大小以后就不再参与后续的合并操作。

Force Merge

当 Index 不再有写入操作的时候，建议对其进行 force merge。能够提升查询速度/减少内存开销。

最终分成几个 segments 比较合适?

越少越好，最好可以 merge 成 1 个，但是 Force Merge 会占用大量的网络、IO 和 CPU。
如果不能在业务高峰期之前做完，就需要考虑增大最终的分段数。包括 Shard 的大小、Index.merge.policy.max_merged_segment 的大小。

缓存与内存

缓存类型	作用域	主要作用	触发条件	失效条件
Node Query Cache (Filter Cache)	节点级	缓存过滤查询（Filter）的结果（文档 ID 位图）	`filter` 上下文查询	索引数据变更、手动清除、段合并、LRU 淘汰
Shard Request Cache	分片级	缓存整个搜索请求的完整结果（如聚合查询）	`size:0` 的请求或显式启用	索引数据变更、手动清除、分片 Refresh、LRU 淘汰
Fielddata Cache	分片级	缓存字段值到文档 ID 的映射（用于排序、聚合）	对 `text` 字段进行聚合/排序	手动清除、段合并、LRU 淘汰

管理内存的重要性

ElasticSearch 高效运维依赖于内存的合理分配。可用内存一半分配给 JVM，一半留给操作系统缓存索引文件。

内存问题可能会导致 GC 和 OOM 问题。

一些常见的内存问题

Segments 个数过多，导致 full GC。集群响应慢但没有特别多是读写，节点在持续 full GC。查看内存发现 segments.memory 占用很大空间。通过 force merge 段合并。
Field data cache 过大，导致 full GC。集群响应慢但没有特别多是读写，节点在持续 full GC。查看内存发现 fielddata.memory.size 占用很大空间。将 indices.fielddata.cache.size 设小，重启节点，堆内存恢复正常。

Circuit Breaker

熔断器名称	主要功能	触发条件（默认阈值）
Parent Circuit Breaker	总内存保护，防止所有子熔断器总和超过节点内存	所有子熔断器申请内存总和 > 95% JVM 堆
Fielddata Circuit Breaker	防止加载字段数据（如 `text` 字段聚合）耗尽堆内存	字段数据内存 > 40% JVM 堆
Request Circuit Breaker	限制单个请求（查询、聚合等）的内存使用，防止大请求压垮节点	单个请求内存 > 60% 父熔断器剩余内存
In Flight Requests Circuit Breaker	限制传输中请求（未完成）的总内存，保护网络和内存资源	传输中请求总内存 > 100% JVM 堆
Accounting Circuit Breaker	跟踪分片级资源（如 Lucene 段内存），确保资源释放后及时回收	未释放资源 > 100% JVM 堆
Script Compilation Circuit Breaker	限制一定时间窗口内脚本编译次数，防止频繁编译消耗 CPU	15 分钟内编译次数 > 75 (默认)
Disk Usage Circuit Breaker	防止节点磁盘写满导致集群故障（触发只读保护）	磁盘空间 > 低水位线 (默认 85%)