Search Slow Log 与 Indexing Slow Log

做的事：本机真实把search slowlog的query阈值同时设置成warn=10s、info=5s、debug=1s、trace=0ms四档，跑一次正常速度的查询

代码PUT /slow_test2/_settings { "index.search.slowlog.threshold.query.warn": "10s", "index.search.slowlog.threshold.query.info": "5s", "index.search.slowlog.threshold.query.debug": "1s", "index.search.slowlog.threshold.query.trace": "0ms" } GET /slow_test2/_search?q=n:1

验证：这次耗时234微秒的查询真实只记了1条日志，级别精确是TRACE——不是被同时记录成4条，也不是记在更高的级别

真实耗时: 234.2微秒
日志里: log.level="TRACE", log.logger="index.search.slowlog.query"
真实只有这1条，没有在warn/info/debug这几档上重复出现

这个真实结果说明四档阈值不是互相独立触发的开关，而是真实共同构成了一套从严到松的分级体系：一次查询耗时真实只会命中它所超过的那个最宽松（数值最小）的阈值对应的级别，本次234微秒真实只超过了trace的0ms这一档，没有超过debug的1秒这一档，所以真实只在TRACE这一个级别留下记录，而不会同时出现在多个级别里。

真实用同样的四档阈值设置手法测indexing slowlog，看一次正常速度的写入会不会也遵循同样的单一级别规则

代码PUT /slow_test2/_settings { "index.indexing.slowlog.threshold.index.warn": "10s", "index.indexing.slowlog.threshold.index.info": "5s", "index.indexing.slowlog.threshold.index.debug": "1s", "index.indexing.slowlog.threshold.index.trace": "0ms" } POST /slow_test2/_doc {"n":2}

验证：一次耗时592微秒的写入真实也只在TRACE这一个级别留下了1条记录，跟search slowlog遵循的是同一套规则

真实耗时: 592.6微秒
日志里: log.level="TRACE", log.logger="index.indexing.slowlog.index"
真实同样只有这1条记录

真实直接对比两边日志里具体有哪些字段，看search slowlog和indexing slowlog结构上真实有什么不同

代码真实解析两条日志，列出各自以elasticsearch.slowlog开头的全部字段名

验证：search slowlog真实比indexing slowlog多出了search_type、total_hits、total_shards这3个字段，这是两者唯一的真实结构性差异

search slowlog真实的9个字段:
id, message, search_type, source, stats, took, took_millis,
total_hits, total_shards

indexing slowlog真实的5个字段:
id, message, source, took, took_millis

这组真实对比说明两者的核心结构真实是一致的（都有id、message、source、took、took_millis这5个共同字段），search slowlog真实只是多了search_type（查询类型，比如QUERY_THEN_FETCH）、total_hits（真实匹配到多少条）、total_shards（真实问了多少个分片）这3个只对"查"这个动作才有意义的额外字段，indexing slowlog因为写入这个动作真实不涉及"匹配了多少条""问了多少个分片"这类概念，所以真实没有这几个字段，但两者共享的source字段都真实带着完整的原始内容（查询语句或者被写入的文档）。

收尾：真实清理测试索引

代码DELETE /slow_test2

分步演示：从四档阈值下的真实单一级别记录，到search和indexing slowlog结构字段的直接对比

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