本机真实验证index.search.slowlog.level这个早期流传的设置在8.15.0上已经失效;把query和fetch的threshold.warn都设成0ms后跑一次查询,验证slowlog真实把query和fetch两个阶段分别独立记录,各自带着完整查询内容和独立耗时;再把indexing的threshold设成0ms写入一条文档,验证indexing slowlog真实记下了被写入文档的完整原始内容和精确耗时,证明slowlog给出的信息足够直接定位到具体是哪个操作拖慢了系统。
代码PUT /slow_test/_settings { "index.search.slowlog.threshold.query.warn": "0ms", "index.search.slowlog.threshold.fetch.warn": "0ms", "index.search.slowlog.level": "warn" }
→ 400 illegal_argument_exception: "unknown setting [index.search.slowlog.level]"
这个真实报错提醒了一个容易踩坑的地方:早期版本的Elasticsearch文档和网上流传的配置示例里常见的slowlog.level这个设置,在本机真实的8.15.0版本上已经不存在了,真正可用的是针对query/fetch/index这些具体阶段分别设置的threshold.*.warn/info/debug/trace这组更细粒度的设置。
代码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
真实追加进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\",...}}}"代码PUT /slow_test/_settings { "index.indexing.slowlog.threshold.index.warn": "0ms" } POST /slow_test/_doc {"n":2,"text":"triggering indexing slowlog"}
真实追加进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内容原样记在日志里,排查"到底是哪条写入拖慢了索引速度"的时候,真实不需要再去猜测或者反查,日志里原样躺着答案。
代码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
每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。
index.search.slowlog.* 与 index.indexing.slowlog.* 设置