第 29 章：监控告警

这是《Elasticsearch 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 监控的目标不是画很多图，而是在问题影响业务前发现它，并在事故中快速回答四个问题：影响面多大、瓶颈在哪、先做什么、什么时候恢复。

本章建立 Elasticsearch 的监控体系：集群、节点、索引、查询、写入、JVM、磁盘和告警 Runbook。

29.1 监控分层

常用快照：

GET /_cluster/health?pretty
GET /_cat/nodes?v
GET /_cat/indices?v&health=yellow
GET /_cat/allocation?v
GET /_cat/thread_pool/write,search?v&h=node_name,name,active,queue,rejected

生产监控建议通过 Prometheus 采集，而不是人肉执行 Cat API。

29.2 集群健康

GET /_cluster/health?timeout=5s

关键字段：

告警示例：

29.3 节点指标

查看节点统计：

GET /_nodes/stats/jvm,os,fs,indices,thread_pool?human

29.3.1 CPU 与负载

关注：

• CPU percent；
• load average；
• IO wait；
• 进程 CPU 与系统 CPU；
• hot threads。

CPU 高的常见原因：

• 查询扇出过大；
• 高基数聚合；
• 分词和脚本；
• segment merge；
• recovery；
• 节点分片热点。

29.3.2 JVM

关注：

• heap used percent；
• old GC 频率和耗时；
• young GC；
• breakers 触发；
• pool 使用趋势。

GET /_nodes/stats/jvm?human

告警：

29.3.3 磁盘

GET /_cat/allocation?v
GET /_nodes/stats/fs?human

关注：

• disk used percent；
• 可用空间绝对值；
• IO read/write；
• IO latency；
• inode 使用率；
• 磁盘增长速率。

告警：

提前告警比等到 flood stage 更重要。

29.4 索引指标

GET /_stats/indexing,search,merge,refresh,flush,segments?human

29.4.1 写入

延迟计算：

avg index latency = index_time_in_millis / index_total

29.4.2 查询

29.4.3 合并与刷新

关注：

• merge.current；
• merge.total；
• merge.total_time；
• merge.total_throttled_time；
• refresh.total_time；
• flush.total_time。

如果 merge throttled time 很高，说明磁盘压力或写入放大已经明显。

29.4.4 Segment

GET /_stats/segments?human

关注：

• count；
• memory_in_bytes；
• terms_memory_in_bytes；
• doc_values_memory_in_bytes；
• stored_fields_memory_in_bytes；
• index_writer_memory_in_bytes。

Segment 数量异常增长通常与 refresh 过频、写入毛刺或 merge 跟不上有关。

29.5 慢查询日志

设置慢查询阈值：

PUT products-v3/_settings
{
  "index.search.slowlog.threshold.query.warn": "3s",
  "index.search.slowlog.threshold.query.info": "1s",
  "index.search.slowlog.threshold.query.debug": "500ms",
  "index.search.slowlog.threshold.fetch.warn": "1s",
  "index.search.slowlog.threshold.fetch.info": "500ms",
  "index.indexing.slowlog.threshold.index.warn": "1s",
  "index.indexing.slowlog.threshold.index.info": "500ms"
}

慢日志应接入日志平台，并至少提取：

• 索引；
• 来源 IP 或用户；
• 查询语句；
• 总命中；
• 耗时；
• 分片数；
• 客户端 trace id。

注意 info/debug 级别会产生大量日志，生产环境要控制保留时间和磁盘。

29.6 采集链路监控

日志系统还要监控 ES 之前的链路：

如果 Kafka lag 增长但 ES 写入指标下降，问题可能在消费器；如果 ES write rejected 上升，问题可能在集群侧；如果应用无日志，问题可能在应用输出或采集器。

29.7 Prometheus 指标

常用 exporter 会把 Cat API 和 stats API 转为 Prometheus 指标。核心 PromQL 示例：

# cluster status
elasticsearch_cluster_health_status{cluster="prod"}

# node heap
elasticsearch_jvm_memory_used_bytes{area="heap"} / elasticsearch_jvm_memory_max_bytes{area="heap"}

# write rejected
rate(elasticsearch_thread_pool_rejected_count{name="write"}[5m])

# search latency
rate(elasticsearch_indices_search_query_time_seconds[5m]) / rate(elasticsearch_indices_search_query_total[5m])

# disk usage
elasticsearch_filesystem_data_available_bytes / elasticsearch_filesystem_data_size_bytes

Grafana 建议看板：

1. Cluster Overview：健康、节点数、分片、pending tasks；
2. Node Health：CPU、heap、GC、磁盘、网络；
3. Index Throughput：写入 QPS、失败、429；
4. Search Performance：P95/P99、超时、取消；
5. Merge & Recovery：merge、refresh、flush、recovery；
6. Pipeline：Kafka lag、采集失败、死信；
7. Capacity：磁盘增长、分片大小、节点均衡。

29.8 告警设计

告警要满足：

• 有明确负责人；
• 有可执行动作；
• 有严重级别；
• 有抑制和静默机制；
• 能关联到业务影响；
• 不重复轰炸。

29.9 Runbook 模板

每类告警应有标准 Runbook：

告警名称：
严重级别：
业务影响：
确认命令：
常见原因：
止血动作：
升级路径：
恢复标准：
事后动作：

示例：write rejected。

确认：
GET /_cat/thread_pool/write?v
GET /_nodes/stats/indices/indexing,merge?human

止血：
1. 写入端降低并发 50%
2. 开启指数退避
3. 暂停低优先级导入

排查：
1. 查看 rejected 所在节点
2. 查看磁盘水位
3. 查看 merge throttled
4. 查看 bulk item 错误
5. 查看是否有节点离线

恢复标准：
rejected 不再增长，写入 P99 回到基线

29.10 容量预测

容量监控不只看当前使用率，还要看趋势：

剩余天数 = 可用容量 / 最近 7 天日均增长

需要记录：

• 每日新增文档数；
• 每日新增磁盘量；
• 副本系数；
• 索引保留期；
• 快照增长率；
• 查询峰值 QPS；
• 写入峰值 docs/s；
• 分片平均大小。

建议每周发布容量报告：

29.11 监控清单

• 集群健康和 master 稳定性；
• 节点在线数和角色；
• JVM heap 和 GC；
• 磁盘使用率和增长趋势；
• write/search rejected；
• query/fetch 延迟；
• 慢查询日志；
• merge、refresh、flush；
• unassigned shard 原因；
• recovery 进度；
• 快照成功率；
• 采集链路 lag 和死信；
• 业务侧无结果率和错误率；
• 每类 P0/P1 告警都有 Runbook。

本章小结

Elasticsearch 监控要同时覆盖集群资源、请求执行、分片状态和上游链路。真正有效的告警不是“CPU 高”，而是能说明影响面、根因方向和处理动作。容量趋势、快照、恢复和慢查询是生产系统最容易被忽视的部分。

思考题

1. yellow 持续 10 分钟和 red 持续 1 分钟，告警级别如何设计？
2. 为什么 JVM 告警不能只看瞬时 heap used？
3. write rejected 上升时，应先检查哪些指标？
4. 如何计算磁盘预计触达水位时间？
5. 慢查询日志应该采集哪些上下文字段？