节点统计是干什么的
节点统计接口返回每个节点的 JVM 堆与 GC、文件系统、操作系统负载、线程池与断路器状态，是监控采集与判断"瓶颈在哪个节点"的主要入口。响应体很大，所以接口提供按分段取数（jvm、fs、os 等）与 filter_path 精确取字段两种瘦身方式，采集端应始终配合使用。
基本信息
| 接口 | GET /_nodes/stats 或 /_nodes/stats/jvm,fs,os |
|---|---|
| 常用分段 | jvm、fs、os、indices、thread_pool、breaker、transport |
| 瘦身参数 | filter_path=nodes.*.jvm.mem.heap_used_percent |
| 单节点 | GET /_nodes/<node_id>/stats/jvm |
| 适用版本 | Elasticsearch 5.x 起接口稳定，指标分段随版本增加 |
示例
示例
# 只取堆使用率与磁盘总量，避免拉回完整响应
GET /_nodes/stats/jvm,fs?filter_path=nodes.*.name,nodes.*.jvm.mem.heap_used_percent,nodes.*.fs.total
# 断路器水位：判断是否接近触发
GET /_nodes/stats/breaker?filter_path=nodes.*.breakers.parent
# 线程池排队与拒绝情况
GET /_nodes/stats/thread_pool?filter_path=nodes.*.thread_pool.search
# 单节点细看 GC 次数与耗时
GET /_nodes/<node_id>/stats/jvm?filter_path=nodes.*.jvm.gc典型使用场景
- 监控采集：定时抓堆、GC、线程池指标送入时序库
- 热点定位：比较各节点负载与磁盘使用，识别资源不均衡
- 容量判断：堆使用率长期高位说明查询形态或堆配置需要调整
- 拒绝排查：线程池 queue 与 rejected 上升说明处理能力不足
- 断路器预估：观察 breaker 估算值与上限之间的距离
分段与关键指标
| 分段 | 关键指标 | 关注点 |
|---|---|---|
| jvm | mem.heap_used_percent、gc.collectors | 堆高且 GC 频繁说明分配压力大 |
| fs | total.available_in_bytes、io_stats | 按数据路径聚合，接近满盘提前扩容 |
| os | cpu.percent、load_average | 负载高而 CPU 不高多为 IO 等待 |
| thread_pool | queue、rejected、active | rejected 持续增长说明线程池被打满 |
| breaker | estimated_size_in_bytes、limit_size_in_bytes | 接近上限时聚合类请求开始报错 |
堆使用率要与 GC 时间一起看：堆水位不高但 GC 频繁，同样说明对象分配压力大，只看堆使用率会漏掉这类问题。
fs 分段按数据路径聚合展示，多路径节点的总容量被合并；要按单块盘告警需结合系统层采集（如磁盘采集器或 iostat）。
指标怎么用来定位问题
排查顺序一般是先看基础资源、再看请求侧：堆与 GC 反映内存压力，fs 反映容量与 IO，thread_pool 的 queue 与 rejected 反映请求是否积压，breaker 的估算值反映内存分配是否逼近安全线。同一指标要在节点之间横向比较：只有个别节点明显偏离，问题多出在该节点的分片分布或宿主机上；所有节点一起劣化，则要从查询形态或容量规划上找原因。
横向对比各节点指标时要注意分片分布并不均匀：承载数据多的节点本身就会占用更多堆与磁盘，先看它挂了多少分片与索引，再判断资源是否真的异常。