bigywater.tech
Elasticsearch · 144

Slow Log 配置与慢查询定位

本机真实验证index.search.slowlog.level这个早期流传的设置在8.15.0上已经失效;把query和fetch的threshold.warn都设成0ms后跑一次查询,验证slowlog真实把query和fetch两个阶段分别独立记录,各自带着完整查询内容和独立耗时;再把indexing的threshold设成0ms写入一条文档,验证indexing slowlog真实记下了被写入文档的完整原始内容和精确耗时,证明slowlog给出的信息足够直接定位到具体是哪个操作拖慢了系统。

想设置slowlog.level
真实直接被拒绝,这个版本已经没有这个设置
query/fetch阈值设为0ms后查询
slowlog真实记下2条独立记录
indexing阈值设为0ms后写入
slowlog真实记下完整原始文档内容

做的事:本机真实想一并设置index.search.slowlog.level这个设置,看这个版本是否真实还支持它

代码PUT /slow_test/_settings { "index.search.slowlog.threshold.query.warn": "0ms", "index.search.slowlog.threshold.fetch.warn": "0ms", "index.search.slowlog.level": "warn" }

验证:真实直接被拒绝,报错写的是unknown setting——这个版本真实已经没有level这个设置了

实测 · 本机 Elasticsearch 8.15.0 执行输出
→ 400 illegal_argument_exception:
  "unknown setting [index.search.slowlog.level]"

这个真实报错提醒了一个容易踩坑的地方:早期版本的Elasticsearch文档和网上流传的配置示例里常见的slowlog.level这个设置,在本机真实的8.15.0版本上已经不存在了,真正可用的是针对query/fetch/index这些具体阶段分别设置的threshold.*.warn/info/debug/trace这组更细粒度的设置。

真实去掉level这个无效设置,只保留query和fetch的threshold.warn设成0ms,意味着任何耗时的查询都会被记录下来

代码PUT /slow_test/_settings { "index.search.slowlog.threshold.query.warn": "0ms", "index.search.slowlog.threshold.fetch.warn": "0ms" } GET /slow_test/_search?q=text:slow

验证:真实跑一次普通查询之后,slowlog文件真实多了2条记录,一条对应query阶段,一条对应fetch阶段,各自精确记录了独立的耗时

实测 · 本机执行输出
真实追加进es-lab_index_search_slowlog.json的2条记录:
→ log.logger: "index.search.slowlog.query", took: "732.4micros"
→ log.logger: "index.search.slowlog.fetch", took: "2.1ms"

两条记录都真实带着完整的查询内容:
  "source":"{\"query\":{\"query_string\":{\"query\":\"text:slow\",...}}}"
这组真实数据直接呼应了本系列前面验证过的"query阶段和fetch阶段是两件独立的事"这条结论:slowlog真实把这两个阶段分开单独记录,各自有自己独立的耗时和独立的日志器名字(index.search.slowlog.query和index.search.slowlog.fetch),这意味着真实定位慢查询的时候,能够精确判断到底是"找出哪些文档匹配"慢,还是"把匹配到的文档内容组装出来"慢——这两种慢的真实根因和优化方向完全不同。每条记录里真实还带着完整的查询JSON原文,不需要靠猜就能直接定位到是哪个具体的查询拖慢了系统。

真实再把indexing slowlog的threshold也设成0ms,写一条文档,看indexing slowlog会记录下什么

代码PUT /slow_test/_settings { "index.indexing.slowlog.threshold.index.warn": "0ms" } POST /slow_test/_doc {"n":2,"text":"triggering indexing slowlog"}

验证:indexing slowlog真实记下了这次写入的完整原始内容和精确耗时,连文档的_id都原样带着

实测 · 本机执行输出
真实追加进es-lab_index_indexing_slowlog.json的记录:
→ elasticsearch.slowlog.id: "a5HQ-aABgXnfze4ECcp3"   ← 真实跟写入响应的_id完全一致
→ elasticsearch.slowlog.source: "{\"n\":2,\"text\":\"triggering indexing slowlog\"}"
→ elasticsearch.slowlog.took: "697.4micros"

这组真实数据说明indexing slowlog真实比search slowlog给出的信息更直接:它不仅记录耗时,还真实把被写入的那条文档的完整原始JSON内容原样记在日志里,排查"到底是哪条写入拖慢了索引速度"的时候,真实不需要再去猜测或者反查,日志里原样躺着答案。

收尾:真实把两组slowlog的阈值都清除恢复默认,清理测试索引

代码PUT /slow_test/_settings { "index.search.slowlog.threshold.query.warn": null, "index.search.slowlog.threshold.fetch.warn": null, "index.indexing.slowlog.threshold.index.warn": null } DELETE /slow_test

分步演示:从失效的slowlog.level设置,到query/fetch两阶段的独立记录,再到indexing slowlog带出的完整文档原文

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。

slowlog把query/fetch/indexing各阶段分别记录,每条记录都带着足够定位问题的完整原始内容
这一步新验证的slowlog场景

    本文用到的工具

    • 本机真实部署的 Elasticsearch 8.15.0(单节点,tar包直接启动)
    • 真实的 index.search.slowlog.* 与 index.indexing.slowlog.* 设置
    京ICP备2026067502号-1京公网安备11010502063487号