在分布式搜索引擎的运维江湖中，最可怕的不是集群挂了，而是集群变慢了、偶尔报错了，你却不知道为什么。
Easysearch 每天可能会产生数 GB 的日志。对于新手运维来说，这些密密麻麻的文本简直是天书。但对于专家来说，这里面藏着集群健康的“心电图”。
本文将为你剥离噪音，提炼出 Easysearch 运维中最值得关注的四大类日志指标，助你从被动救火转向主动预防。
一、 生命线指标：GC 与 JVM 日志 #
在 Java 世界里，垃圾回收（GC）是影响性能的头号杀手。对于 Easysearch 这种内存密集型应用，GC 日志是判断节点是否即将“假死”的风向标。
1. 关键关键词 #
[gc][young]/[gc][old]overheadmonitor
2. 怎么看？ #
- Young GC：频率高但耗时短是正常的。但如果频繁连续出现，说明写入压力过大，Eden 区瞬间被填满。
- Old GC (Full GC)：这是红色警报。如果日志中频繁出现
[gc][old]且耗时超过几秒，或者出现overhead limit exceeded，说明堆内存不足，集群极有可能发生 OOM（内存溢出）或节点脱离集群。 - 长时间停顿：关注
duration。如果 GC 耗时超过 30秒，主节点可能会认为该节点已死（因为无法响应心跳），从而将其剔除，引发集群震荡。
3. Easysearch 优化 #
Easysearch 在内核层面优化了内存管理，并引入了更灵敏的断路器（Circuit Breaker）。关注日志中是否有 CircuitBreakingException，这是 Easysearch 在主动保护节点不被撑爆，而非简单的报错。
二、 性能杀手：Slow Logs（慢日志） #
Easysearch 默认不开启慢日志，但在排查“查询慢”或“写入卡”的问题时，这是第一把手术刀。
1. 开启配置（动态设置） #
建议在排查问题时对特定索引开启：
PUT my_index/_settings
{
"index.search.slowlog.threshold.query.warn": "2s",
"index.search.slowlog.threshold.query.info": "500ms",
"index.indexing.slowlog.threshold.index.warn": "2s"
}
2. 关键关注点 #
- Search Slow Log：关注
source字段。这里记录了具体的 DSL。 - 常见凶手：深度翻页（Deep Pagination）、以
*开头的通配符查询、巨型的Terms查询、复杂的脚本（Script）。 - Indexing Slow Log：写入慢。
- 常见凶手：复杂的 Analyze（分词）过程、巨大的单个文档（几 MB 一个 JSON）、磁盘 I/O 瓶颈。
三、 拥塞信号：线程池拒绝 (Rejected Execution) #
当客户端收到 429 Too Many Requests 错误时，对应的 Easysearch 服务端日志就是 EsRejectedExecutionException。这代表集群处理不过来了。
1. 关键关键词 #
rejected executionwrite thread poolsearch thread pool
2. 问题定位 #
- Write 拒绝：通常是因为并发写入过高，或者磁盘 I/O 太慢导致写入积压。
- 对策：增加节点、优化 Bulk 批次大小、检查磁盘性能（Easysearch 的 ZSTD 虽然省空间，但对 CPU 有一定要求，需平衡）。
- Search 拒绝：查询 QPS 过高或单个查询太耗时（占着线程不释放）。
- 对策：配合慢日志抓出耗时查询，或者横向扩容 Data 节点。
四、 稳定性指标：集群状态与磁盘水位 #
这一类日志通常预示着架构层面的风险。
1. 集群状态变更 #
- 关键词：
Cluster state change、master node changed、node-left、node-join。 - 解读：如果你的集群日志里整天都是节点加入、离开的信息，说明网络环境极不稳定，或者某个节点存在严重的内存泄漏导致频繁重启。
2. 磁盘水位线 (Watermark) #
- 关键词：
flood stage disk watermark、low disk watermark。 - 解读：
- Low Watermark (85%)：Easysearch 停止向该节点分配新分片。
- High Watermark (90%)：开始尝试将分片搬离该节点。
- Flood Stage (95%)：致命。为了防止磁盘写满导致数据损坏，Easysearch 会强制将索引设为
read_only_allow_delete（只读）。 - 注意：一旦进入 Flood Stage，清理磁盘后，你必须手动解除只读状态！
五、 如何高效管理这些日志？ #
靠人工 tail -f 去看几十个节点的日志是不现实的。在 Easysearch 的生态中，我们推荐以下组合拳：
- INFINI Console（统一管控平台）：
Easysearch 配套的 Console 提供了可视化的监控大屏。它能通过 Agent 自动采集上述指标，并以图表形式展示 GC 频率、线程池堆积情况。这是运维的“驾驶舱”。 - 日志自监控：
将 Easysearch 的日志（Server logs）通过 Agent 采集，上报写入到一个独立的 Easysearch 监控集群中。用 Easysearch 监控 Easysearch，设置告警规则（例如：1分钟内出现 5 次 Full GC -> 发送钉钉告警）。 - 标准化 Error 捕捉：
重点监控日志级别为ERROR和WARN的条目。对于 Easysearch，忽略那些 INFO 级别的分片移动日志，聚焦于Exception堆栈信息。
结语 #
日志是 Easysearch 向运维人员发出的“求救信号”。
- GC 日志告诉你它累不累（内存）；
- Slow Logs 告诉你它在磨蹭什么（查询优化）；
- Rejected 日志 告诉你它撑不住了（容量规划）；
- Watermark 日志 告诉你房子要塌了（磁盘空间）。
读懂这四类指标，你就能从“救火队员”晋升为“集群架构师”，让 Easysearch 跑得更稳、更久、更快。
