日志分析
日志，想必大家不陌生，程序遇到一个意想不到的问题（俗称BUG），研发同学会本能的想到看下运行日志；网站受到攻击，安全同学第一反应会是查下访问日志找出凶手；需要统计业务的PV/UV，运营同学也是会想到日志，做个统计。这些都是在做日志分析。
上图可以看到，日志分析面对业务场景、时效性要求以及相关业务角色都很多，另外，产生日志的服务器、程序多的都数不过来。密码对这么复杂的场景，如果我们还是用原始的 Linux 命令来做分析，那头发绝对是保不住了。
有没有一个一体化的平台来帮我们解决这个问题呢，既能方便的把数据接入，又能快速的进行各种业务分析，还能把分析结果展示到酷炫的报表，甚至，都不用我整天盯着，系统发现问题自动告警。SLS 就是为此而生的。
SLS
SLS 是阿里巴巴自主研发的、云上一站式日志分析平台。请看下图 SLS 的生态图，SLS 已经做到了数据想来就来（各种数据协议和工具、SDK）、不服就干（查询百亿数据秒级返回、各种报表供选择）、说走就走（对接各种数据平台）。
你以为就这么多？当然不止！！！除了数据分析的一站式服务，SLS 还提供了不同数据业务场景的增值服务，比如新冠病毒疫情APP（全免费）、阿里云成本管家、K8S事件中心，以及日志审计服务。
SLS vs ELK
除了 SLS，业界也有一些很优秀的日志分析产品和解决方案，这里就选广受欢迎的自建 ELK 方案做一个对比。对比方案如下：
数据写入性能和存储压缩效率
从下图测试结果可以看出，相同数据量写入，SLS 的时间开销只有 ELK 的 35%，这里自建 ELK 可以通过加入 Kafka 来提高写入性能，接近 SLS，所以 SLS 并不算是绝对优势。从落盘数据量大小来看，SLS 的压缩效率更优。
数据读取性能
这里数据读取对比测试有两个常用的场景：简单日志查询和涉及统计分析的聚合计算。下图为测试结果，在日志查询场景中，在面对亿级数据量，二者都达到了秒级返回。当查询并发度较低时，二者性能接近，随着并发度增加，SLS 优势凸显出来。在聚合计算场景下，二者的性能旗鼓相当。
成本费用
下图是成本对比计算细节，SLS 有绝对优势。有一点，SLS 的费用随着数据量增长而线性增长，也就是说跟数据量比较敏感；但是 ELK 的投入是阶段性的，直觉上是增长较慢，这其实是一种错觉。
综合对比
从以上对比测试结果来看，SLS 在并发较高的查询场景，以及成本费用上有明显优势。
从综合的场景来看，自建 ELK 是一套日志分析解决方案，需要自行搭建和运维。而 SLS 则是一站式的日志分析平台，用户无需关心平台实现和运维，而是将精力放在业务分析上。
所以整体来说，SLS 的性价比远要比自建 ELK 高。
从 ELK 迁移到 SLS
我的自建 ELK 里面存储大量的数据，通过全方位对比，决定转向使用 SLS，我的这些历史数据怎么迁移到 SLS？
其实 SLS 早有方案，3个命令即可解决：
> pip install aliyun-log-python-sdk aliyun-log-cli -U --no-cache
> aliyunlog configure <access_id> <access_key> <endpoint>
> aliyunlog log es_migration \
--cache_path='/root/es_migrate/nginx.access' \
--hosts='elastic:OAD5RvzCOVBKD8KVKnEd@127.0.0.1:9200' \
--indexes='nginx.access.2020-*' \
--logstore_index_mappings='{"nginx-access-log": "nginx.access*"}' \
--project_name='my-project' \
--time_reference='@timestamp' \
--pool_size=3要是你说“迁移过程中意外中断了怎么办”，优秀！且看下文。
Q：迁移程序跑到一半意外中断了，怎么办？重新开始是不是会从头开始迁一遍？数据会重复吗？
A：调用参数中 cache_path 指定迁移状态的存放位置，当迁移程序中断后，重新打开时指定相同的 cache_path 便可以继续迁移任务，不会有数据重复。也可以主动中断，更改迁移参数后，比如 pool_size，batch_size，再重启。
Q：ES 中存储大量冷数据，index 都是 closed 状态，全部打开会给服务器很大压力，怎么做迁移？
A：基于断点续传功能，分批进行迁移。在确定好迁移任务后，开启一部分 index，执行迁移指令开始迁移，完成后关闭这些 index，开启另一批 index，执行完全相同的迁移命令，会自动继续执行新的迁移任务。分批依次执行，直到全部完成。
Q：迁移程序正常退出，但是数据迁移不全，怎么解决？
A：如果 ES 的吞吐量较小，大规模的数据读取可能会导致 ES 中的 index 暂时不可用，迁移会跳过这些 index，建议改小 pool_size。出现数据迁移不全时，可以确认 cache_path 中的内容没有被更改后，重新运行相同的迁移指令，会继续迁移被跳过的数据。这个继续迁移过程可以执行多次。
还有问题？没关系，这里有深入灵魂的数据迁移官方最佳实践，还有技术风的使用文档。
什么，看文档不是你的风格？没关系，拿起手机，钉钉扫文末二维码，直接找客服做技术支持。
结语
如上文所说，ELK 是一个很优秀的日志分析解决方案，但是如果你只想专注在业务，不想浪费宝贵时间在平台搭建、运维、性能优化这些技术细节，那就交给 SLS。
又或者说，你在追求极致的数据分析性能，而且又对性价比特别挑剔，那 SLS 特别适合你。
有任何问题请拿起手机，打开钉钉，扫描下面二维码加入 SLS 服务群，技术支持会第一时间回复。
另外，还可以关注公众号，不定期发送干货技术文章，就等你来。
