以下是更为详细的 Elasticsearch（ES）监控、巡检及异常指标处理指南，分为 监控内容、巡检方式 和 异常指标及处理方案 三大部分，内容更加全面，适用于生产环境中的深入管理。

---

一、监控内容

1. 集群健康状态

• 指标说明：

  • 集群状态：
    • Green（绿色）：所有主分片和副本分片正常工作。
    • Yellow（黄色）：主分片正常，但部分副本未分配。
    • Red（红色）：主分片丢失或不可用。
  • 重要字段：
    • status：集群状态（green/yellow/red）。
    • number_of_nodes：当前节点数。
    • number_of_data_nodes：数据节点数。
    • active_shards：活动分片数。
    • unassigned_shards：未分配分片数。

• 命令及样例：

  GET /_cluster/health
  

  {"cluster_name": "my_cluster","status": "green","number_of_nodes": 5,"number_of_data_nodes": 3,"active_primary_shards": 15,"active_shards": 30,"unassigned_shards": 0
  }
  

• 处理建议：

  • **Green 状态：**无需操作。
  • Yellow 状态：
    • 检查节点故障原因。
    • 检查副本分片策略和硬件资源分布。
  • Red 状态：
    • 立即检查主分片状态，分析日志查找异常原因。
    • 根据备份策略恢复数据或修复分片。

---

2. 节点状态

• 关键指标：

  • **节点数：**是否符合预期。
  • CPU 使用率：
    • 正常值：50% 以下。
    • 关注：> 70%。
    • 高危：> 90%。
  • 内存（JVM Heap）：
    • 使用率超过 75% 可能触发频繁 GC。
  • 磁盘使用率：
    • 超过 85% 触发分片迁移。
    • 超过 90% 写入失败。
  • 网络带宽：
    • 主要关注吞吐量（吞入和吞出）。

• 命令及样例：

  GET /_cat/nodes?v
  

  ip         heap.percent ram.percent cpu load_1m load_5m load_15m node.role
  10.0.0.1   65           75          50  1.2     0.8     0.6      d
  10.0.0.2   50           70          30  0.6     0.4     0.2      d
  

• 处理建议：

  • CPU 高使用率：优化查询、增加节点。
  • JVM Heap 高：增大堆大小或减少缓存策略。
  • 磁盘高使用率：清理旧索引或扩容磁盘。

---

3. 索引和分片状态

• 关键指标：

  • 索引状态：
    • 分片分配是否均匀。
    • 是否存在未分配分片。
  • 分片数量：
    • 单索引分片建议不超过 50。
    • 单分片大小建议控制在 30-50GB 之间。
  • 索引吞吐量：
    • 写入速率：是否出现堆积。
    • 查询延迟：是否存在慢查询。

• 命令及样例：

  GET /_cat/shards?v
  GET /_cat/allocation?v
  

• 处理建议：

  • 分片未分配：
    • 检查磁盘容量。
    • 使用 _cluster/reroute 强制分片重新分配。
  • 分片过多：
    • 合并索引或调整分片数。

---

4. 慢查询

• 慢查询指标：

  • 查询耗时：是否超过预期。
  • 执行频率：是否过于频繁。
  • 查询类型：深度分页、高频聚合等。

• 排查方法：

  • 开启慢查询日志：

    index.search.slowlog.threshold.query.warn: "10s"
    index.search.slowlog.threshold.fetch.warn: "5s"
    

• 处理建议：

  • 优化索引结构（Mapping）。
  • 使用 scroll 替代深度分页。

---

5. 快照和备份

• 关键点：

  • 确保快照周期性执行。
  • 检查快照状态是否成功。
  • 确保快照目录权限正常。

• 命令及样例：

  GET /_snapshot/<repository>/_status
  

• 处理建议：

  • 定期验证快照可用性。
  • 发生问题时重新注册仓库。

---

二、巡检方式

1. 自动化巡检

• 使用工具：
  • **Elastic Stack 自带监控模块：**Kibana 的监控 UI。
  • **Prometheus + Grafana：**用于大规模监控。
  • Curator：定期清理索引和快照。

---

2. 手动巡检

• 每日检查：集群状态、节点状态、索引状态。
• 每周检查：分片分布、慢查询、任务队列。
• 每月检查：硬件资源、快照备份。

---

三、异常指标处理

1. CPU 使用率高

• 原因：

  • 大量聚合查询。
  • 分片分布不均匀。

• 解决：

  • 优化查询，限制返回数据大小。
  • 增加节点。

---

2. JVM Heap 使用率高

• 原因：

  • 数据量过大。
  • 缓存策略问题。

• 解决：

  • 增加堆内存大小。
  • 清理缓存。

---

3. 分片未分配

• 原因：

  • 磁盘空间不足。
  • 分片损坏。

• 解决：

  • 强制重新分配分片：

    POST /_cluster/reroute
    

---

4. 查询延迟高

• 原因：

  • 深度分页或聚合。
  • 查询频率过高。

• 解决：

  • 开启慢查询日志。
  • 使用 filter 替代 query。

---

通过系统化监控和及时巡检，可以大大降低问题的出现频率，保证 ES 集群的高效运行。