无预设Schema时CloudWatch日志同步到AWS Elasticsearch的映射错误如何解决

优先推荐方案：保留按天索引规则，配置索引模板 #

该方案完全适配你当前大体量日志的场景，不用改动现有Lambda写入逻辑，还能保留按天索引的核心优势：方便日志生命周期管理（过期日志直接删索引，性能远高于单索引删文档）、冷热分层存储、大日志量下查询性能更稳定，改造成本最低。
操作步骤如下：

• 在AWS Elasticsearch中创建索引模板，匹配所有cloudwatch-logs-*格式的索引，提前定义所有可能出现类型冲突的字段类型，例如将CPU字段指定为float，其他可能出现数值类型波动的字段统一指定更宽泛的兼容类型，字符串字段可根据查询需求配置为keyword或text+keyword多类型。
• 核心配置参考：

{
  "index_patterns": ["cloudwatch-logs-*"],
  "mappings": {
    "properties": {
      "CPU": {
        "type": "float"
      },
      "memory_usage": {
        "type": "float"
      },
      "message": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword",
            "ignore_above": 256
          }
        }
      }
      // 其他需要固定类型的字段按需补充
    }
  }
}

• 模板配置完成后，所有新生成的按天索引都会自动套用该映射规则，不会再出现自动识别类型错误的问题。已经生成的旧索引如果需要修复可以做reindex操作，被拒收的日志批次可重新触发Lambda推送即可。
• 额外兜底配置：可在模板中添加dynamic_templates规则，统一设置未知字段的类型映射，例如所有数值类字段自动设为float，所有字符串字段默认设为多类型，避免后续新增字段再出现映射冲突。

备选方案：切换为单索引固定映射（仅适合小体量日志场景） #

你提到的调整Lambda写入固定索引cloudwatch-logs、手动配置映射的方案可行，但仅适合日志总存储量长期低于100GB、保留周期小于7天的场景。该方案缺点明显：大日志量下单索引分片压力大，查询性能下降明显，日志过期清理需要删除文档，会产生大量磁盘碎片，运维成本更高，不适合你当前的大体量日志场景。

内容的提问来源于stack exchange，提问作者alexis