问题根因分析 #

先给你拆解下这个报错的核心原因：

object mapping for [service] tried to parse field [service] as object, but found a concrete value

意思是Elasticsearch 中 service 字段的映射被定义成了「对象类型」，但 Logstash 传过来的日志里 service 是字符串值（比如 "api-gateway"），类型不匹配直接导致写入失败，所以索引是空的。

那为什么关闭 ILM 就正常？

• 关闭 ILM 时，你直接写入 service-logs-all-%{+YYYY.MM.dd} 这种日期命名的索引，Elasticsearch 会自动生成动态映射，识别 service 为字符串类型，所以没问题；
• 启用 ILM 后，你用了 service-logs-all 这个滚动别名，Elasticsearch 会自动使用和该别名关联的索引模板来创建新的滚动索引。如果这个模板里把 service 错误定义成了 object 类型，或者有其他高优先级的模板（比如 Beats 默认模板）覆盖了映射规则，就会触发这个冲突。

分步解决办法 #

1. 排查现有索引模板（定位冲突源）

先确认和 service-logs-all 匹配的索引模板是什么，用 ES API 快速排查：

# 替换成你的ES地址、用户名密码
curl -u ${ELASTIC_USER}:${ELASTIC_PASSWORD} -k https://${ELASTIC_HOSTS}/_index_template | grep -E "service-logs-|service"
# 有jq工具的话可以更精准过滤：
curl -u ${ELASTIC_USER}:${ELASTIC_PASSWORD} -k https://${ELASTIC_HOSTS}/_index_template | jq '.index_templates[] | select(.index_patterns[] | test("service-logs-*"))'

如果返回的模板里 service 字段是 object 类型，那就是问题所在。

2. 创建正确的自定义索引模板（绑定ILM策略）

创建一个优先级更高的索引模板，明确指定 service 为字符串类型（keyword 适合聚合查询，text 适合全文检索，按需选择），同时关联你的 Pong-logs-policy ILM 策略：

curl -u ${ELASTIC_USER}:${ELASTIC_PASSWORD} -k -X PUT https://${ELASTIC_HOSTS}/_index_template/service-logs-all-template \
-H "Content-Type: application/json" \
-d '{
  "index_patterns": ["service-logs-all-*"],  # 匹配ILM生成的所有滚动索引
  "template": {
    "settings": {
      "index": {
        "lifecycle": {
          "name": "Pong-logs-policy"  # 绑定你的ILM策略
        }
      }
    },
    "mappings": {
      "dynamic": "strict",  # 可选：严格模式，禁止自动生成未知字段的映射，避免后续冲突
      "properties": {
        "category": {"type": "keyword"},
        "correlationId": {"type": "keyword"},
        "environment": {"type": "keyword"},
        "level": {"type": "keyword"},
        "message": {"type": "text"},
        "service": {"type": "keyword"},  # 明确指定为字符串类型（keyword）
        "timestamp": {"type": "date", "format": "yyyy-MM-dd HH:mm:ss"}
      }
    }
  },
  "priority": 101,  # 优先级高于默认模板（比如Beats模板默认是100），确保生效
  "version": 1
}'

3. 清理错误旧索引并初始化滚动别名

之前生成的空索引（比如 service-logs-all-000001）已经带有错误映射，必须清理后重新初始化：

# 1. 删除所有错误的滚动索引
curl -u ${ELASTIC_USER}:${ELASTIC_PASSWORD} -k -X DELETE https://${ELASTIC_HOSTS}/service-logs-all-*

# 2. 初始化第一个滚动索引，绑定写入别名
curl -u ${ELASTIC_USER}:${ELASTIC_PASSWORD} -k -X PUT https://${ELASTIC_HOSTS}/service-logs-all-000001 \
-H "Content-Type: application/json" \
-d '{
  "aliases": {
    "service-logs-all": {
      "is_write_index": true  # 标记为当前可写入的索引
    }
  }
}'

4. 优化 Logstash 输出配置（可选但更规范）

启用 ILM 滚动别名后，不需要再指定 index 字段（Elasticsearch 会自动管理索引命名），可以删掉这一行简化配置：

output {
  elasticsearch {
    hosts => "${ELASTIC_HOSTS}"
    user => "${ELASTIC_USER}"
    password => "${ELASTIC_PASSWORD}"
    cacert => "/usr/share/logstash/config/certs/ca/ca.crt"
    # index => "service-logs-all-%{+YYYY.MM.dd}"  # 删掉这行，ILM会自动生成索引
    ilm_enabled => true
    ilm_rollover_alias => "service-logs-all"
    ilm_pattern => "000001"
    ilm_policy => "Pong-logs-policy"
  }
}

验证效果 #

重启 Logstash 后，发送测试日志，然后用以下命令验证：

# 查看索引是否有数据
curl -u ${ELASTIC_USER}:${ELASTIC_PASSWORD} -k https://${ELASTIC_HOSTS}/service-logs-all-000001/_count

# 查看索引映射，确认service字段是keyword类型
curl -u ${ELASTIC_USER}:${ELASTIC_PASSWORD} -k https://${ELASTIC_HOSTS}/service-logs-all-000001/_mapping/field/service

如果返回的 count 大于0，且映射显示 type: keyword，就说明问题解决啦！

另外提醒下：如果你的日志后续可能出现新字段，不想用 dynamic: strict，可以改成 dynamic: false（忽略未知字段），避免自动生成错误的映射导致类似问题。