需手动配置index.slowlog.threshold.index.warn等参数并带单位（如1s），在elasticsearch.yml全局设置或通过API动态更新；日志级别、appender配置及轮转策略也需同步检查，否则日志不输出。

如何开启 Elasticsearch 的 index.slowlog.threshold.index.warn

慢查询日志不是默认打开的，得手动配。关键在 index.slowlog.threshold.index.warn 这类设置上——它控制索引写入阶段多慢才记日志，单位是时间字符串（比如 1s、500ms），不是毫秒整数。

常见错误是直接写 1000，结果没生效：Elasticsearch 会静默忽略非法值，日志照常不输出。必须带单位。

• 在 elasticsearch.yml 里全局设（影响所有索引）：

  index:
    slowlog:
      threshold:
        index:
          warn: 1s
          debug: 500ms

• 或用 API 动态更新单个索引：

  PUT /my-index/_settings
  {
    "index.slowlog.threshold.index.warn": "1s"
  }

• 注意：该配置只对新写入的文档生效；已存在的索引操作不会回溯记录

slowlog 输出内容里哪些字段真正有用

日志本身格式固定，但多数人只扫一眼耗时就跳过，其实 source 和 types 字段才是定位根因的关键。

source 是原始 DSL 查询体（如果有的话），但会被截断；types 表示操作类型（index、update、delete），而真正容易被忽略的是 took_in_millis 和 processing_time_in_nanos 的差值——如果后者远大于前者，说明瓶颈不在网络或协调节点，而在本地 Lucene 写入（比如 merge 压力大、磁盘慢）。

• 查日志时别只 grep "took"，加一句 grep -A 5 "source:" 看上下文
• 如果 source 是空或只有 {}，大概率是 bulk 请求里的某条出问题，得结合 bulk 的 response status 定位具体 doc
• 日志中 index 字段值可能和预期不符——某些插件或 alias 操作会让实际写入的索引名和请求路径不一致

为什么设置了 slowlog 却看不到日志

最常见原因是日志级别压得太低。Slowlog 默认走 index_indexing_slowlog.log，但它的输出受两层控制：一是配置里的 level（如 WARN），二是 logging.yml 中对应 appender 的 root level。

• 检查 config/logging.yml 是否有这一行：

  logger.index_indexing_slowlog: DEBUG

  （即使你设了 warn，这里也得至少是 WARN）
• 确认 appender.rolling.strategy.action.condition.age.gte 没把日志轮转得太激进——有些集群配成 1d，结果日志刚生成就被删了
• 使用 _nodes/logging API 实时验证配置是否加载成功：

  GET /_nodes/logging?pretty

  ，搜索 "index_indexing_slowlog" 看 level 是否匹配

bulk 写入场景下 slowlog 怎么对应到具体文档

bulk 请求是一次发多条，但 slowlog 只按整个请求记一条，source 字段里混着 N 条操作，根本分不清哪条拖慢了整体。

这时候不能只依赖 slowlog，得配合 profile API 或开启 index.indexing.slowlog.level 到 DEBUG，让每条子请求单独打日志（代价是 I/O 增加，仅临时开启）。

• 临时启用细粒度日志：

  PUT /my-index/_settings
  {
    "index.indexing.slowlog.level": "debug"
  }

• bulk 中每条操作的 index、update 会在日志里带独立 id 和 type（7.x 后 type 固定为 _doc）
• 注意：profile 对 bulk 不友好，建议先用小批量（如 10 条）复现，再开 profile 查 time 和 breakdown

日志能告诉你“谁慢”，但查不到“为什么慢”——比如是 mapping 设计不合理导致动态字段爆炸，还是 bulk size 超过 10MB 触发了 JVM GC 暂停。这些得结合 hot_threads 和 node stats 交叉看。