使用 man ascii 来查看 ASCII 表。

【工程实践】Elasticsearch 集群监控实战指南

默认分类 | 作者 search_engineer | 发布于6 小时前 | | 阅读数:65

大家好,我是 @search_engineer,今天分享 Elasticsearch 集群监控的实战经验。

为什么监控很重要?

在生产环境中,Elasticsearch 集群的健康状况直接影响搜索服务的可用性。完善的监控体系可以帮助我们:

  • 提前发现潜在问题
  • 快速定位故障原因
  • 优化资源使用效率

核心监控指标

1. 集群健康状态

GET /_cluster/health

关键字段:

  • status: green(正常) / yellow(警告) / red(异常)
  • unassigned_shards: 未分配分片数,>0 需要关注
  • relocating_shards: 正在迁移的分片数

2. 节点级指标

指标 说明 告警阈值
JVM Heap 使用率 内存压力 > 85%
CPU 使用率 计算负载 > 80%
磁盘使用率 存储空间 > 85%
搜索延迟 P99 延迟 > 200ms

3. 索引级指标

GET /_stats/indexing,search,get

关注:

  • indexing_rate: 写入速率
  • search_rate: 查询速率
  • query_time: 查询耗时

监控工具推荐

方案一:Kibana 监控

Elasticsearch 自带的监控功能,无需额外部署。

方案二:Prometheus + Grafana

开源监控方案,适合大规模集群。

方案三:INFINI Console

国产一站式搜索管控平台,支持多集群管理。

实战:设置告警规则

# 示例:磁盘使用率告警
- alert: ElasticsearchDiskHigh
  expr: elasticsearch_filesystem_data_available_bytes / elasticsearch_filesystem_data_size_bytes < 0.15
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "ES 节点磁盘空间不足"

常见问题排查

场景一:集群状态 Yellow

原因:副本分片未分配 解决:检查节点数量是否满足副本要求

场景二:查询延迟高

原因:可能是分片过多或查询复杂 解决:优化分片数量,添加查询缓存

场景三:GC 频繁

原因:堆内存不足或内存泄漏 解决:增加堆内存,检查是否有大聚合查询

总结

完善的监控体系是保障 ES 集群稳定运行的基础。建议至少监控:

  1. 集群健康状态
  2. JVM 内存使用
  3. 磁盘空间
  4. 查询延迟

参考资源

讨论

你在 ES 监控方面有什么经验?欢迎在评论区分享!


本文由 @search_engineer 原创发布,转载请注明出处。


[尊重社区原创,转载请保留或注明出处]
本文地址:http://searchkit.cn/article/15673


6 个评论

ES集群监控用什么工具比较好?Prometheus还是自带的?
ES在Linux上的性能优化有什么特别建议?
ES的源码阅读从哪里入手比较好?
SRE如何处理ES集群故障?
实习生想学习ES,有什么学习路径?
@pythoner 推荐Prometheus+Grafana,社区有很多现成的ES exporter。INFINI Console也不错,国产的,对Easysearch支持更好。

要回复文章请先登录注册