场景
当我们考虑把elk的数据链路迁移到sls时，往往希望做到平滑的迁移，减少迁移的代价。本文介绍几种迁移方案，供大家在做elk迁移时参考。
使用filebeat+logtail双采迁移（推荐）
适合场景，希望在新老数据链路更多时间验证，并且平滑迁移。 sls链路验证OK后旧的es数据链路可以完整下线
场景一： 原架构为filebeat->es
原先es 日志方案的架构如下
双采方案是一个文件可以被多个agent采集，因此可以同时在机器上安装sls的Logtail （由c++开发，性能优秀），采集业务日志到sls，同时使用sls的es兼容方案，可以实现继续使用Grafana和Kibana进行日志查询。
双采的链路如下。
通过安装Logtail 采集将数据写入sls，即可实现SLS的数据链路和原ES的数量链路共存，确保可以稳定切换。等SLS侧的功能充分验证后，择机下线原es的链路即可完成切换。
场景二: 原架构为filebeat+kafka+es
相比场景一的架构，多了Kafka、logtash以及其他消费程序
没关系，之前的双写链路还是适合的，有一个考虑点是消费程序原先是消费kafka，现在数据链路如果转到sls上后是否可以不改程序，只改配置继续复用吗？ 当然可以，使用sls的kafka消费兼容功能可以做到。
下面来看一下双链路的方案：
还有一个问题，如果我的logtash中有很多日志格式处理逻辑，新增sls的链路如何cover这块内容？ 有两种方式解决这个问题：
- 使用Logtail的processor来处理
- 使用SLS的数据加工能力
上面两种日志处理引擎提供了更强大方式，以更高性能可以处理。
使用Kafka导入迁移ES链路
适用希望保留原先的kafka链路，但是希望替换掉es的场景
使用sls的Kafka导入功能，可以将原Kafka中的数据方便地导入SLS中，并且使用SLS的ES兼容复用原先的Grafana和Kibana。
如果原先的logtash中有较多规则需要迁移的，同样适用sls的数据加工、logtail的processor都可以进行处理。
使用Kafka协议上传直切
适用场景：
- 希望复用原先的agent（包括复用原先agent中的各种处理逻辑、采集配置等）
- 适合新部署的场景或确定从原es直接使用sls方案
例如fielbeat场景，可以直接用filebeat写sls kafka兼容接口，该方式同时适合众多开源agent
小结
SLS除了提供Logtail的标准采集方式外，还提供了Kafka兼容、Kafka导入等方式写入数据的方法。这些灵活的写入方案和实际部署架构结合可以很方便地实现从原ES的日志架构中实现平滑迁移。本文对于es迁移sls的场景抛砖引玉，提供了一些思路，希望可以帮助您。
