Elastic Stack版本6.3.0引入了一些breaking changes，最值得注意的是Beats运送主机名的方式。以前，这只是一个包含主机名的简单host字段，而从6.3.0开始，它变成了具有嵌套属性的复杂字段。现在，该名称存储在host.name中。
重大更改页面包含有关如何迁移到Elastic Common Schema的说明，具体取决于您当前管理索引的方式。 When using versioned indices (containing the Beats version), nothing has to be changed really。每个索引将始终仅包含host属性的单个映射，并且没有映射冲突。
用例：您使用Beats索引模板和版本索引
在此用例中，按照Beats输入插件文档中的建议，您手动加载版本模板，并使用Beats版本索引模式
%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}。这将导致6.2索引中的host字段和6.3索引中的host.name字段。没有映射冲突，但是使用host的任何可视化或搜索将不再显示6.3索引的结果。您需要更改什么？
如果您之前搜索了主机字段，请修改搜索以使用
beat.hostname字段。beat.hostname字段早于6.3，并且包含与host.name相同的信息。使用此字段可确保您的查询和聚合将按早期版本和6.3的预期运行。
当您的索引模式跨越多个索引时（例如filebeat-*），就会出现问题。 Kibana将抱怨host字段的映射冲突。一种解决方案是为节拍输入的每个不同版本具有不同的索引模式，但是对于许多不同版本来说，这变得笨拙。此外，它使通过不同索引进行分析/搜索变得困难/不可能（例如，Kibana仪表板）。
当然，如果您没有访问可视化或仪表板中的host字段，那么一切都会按预期进行。但是我的内部OCD是通过在设置对话框中显示“冲突映射”警告来触发的。此外，如果存在 real 映射冲突，将更难发现。基本上相同，如果您有一个无法修复的失败测试–您将不会关注新的失败测试，因为»结果始终为红色«。
那么现有索引遵循新映射格式的迁移策略是什么？创建新索引并使用Elasticsearch的reindex API？新索引应命名为什么，换句话说：它们应获得哪个版本号？这里的最佳做法是什么？还是我只需要忽略的东西？