一年前，小丁加入了一家初创公司，准备大干一番
刚加入公司，业务规模小，使用少量云主机就可以满足需求了
最初，业务刚上线，问题比较多；小丁通过ssh+grep的方法，有效抓住了大部分初期的bug，简单高效
过了一段时间，公司的业务获得了巨大成功，一开始的那些机器数，快顶不住压力了
幸好小丁的公司使用了云服务，一键扩容出n组机器，扛住了业务增长
不过麻烦事来了，以前通过ssh+grep 方式查日志，愉快地抓bug的日志一去不复返了
这时候，小丁的领导来了，告诉小丁，可以考虑使用开源的ELK方案，找几台机器把日志采集上来，可以轻松管理服务器上的日志，做查询和可视化
果然，小丁使用了ELK方案后，轻松化解了日志难题，查问题找Bug又变得驾轻就熟
随着运营推广，用户规模开始指数级增长，机器又要扩容了
没问题，有云计算一键扩容在，轻松搞定
不过，很快用来采集日志的ELK出现了瓶颈。原来Elasticsearch虽然查得快，奈何写入慢呀。经过各种调优也没有得到很好缓解。
于是，小丁找领导请教。原来有一个叫Kafka的开源软件，可以解决这个问题
有了Kafka在ElasticSearch前做缓冲，终于可以缓解ElasticSearch的写入压力，虽然有时候从采集到ElasticSearch查询可以见，有一段时间延迟，总体来说还在接受范围
过了好长一段愉快的程序员时光，忽然有一天财务找到小丁，说要核算机器成本。一看吓一跳，原来自建的Kafka和ElasticSearch竟然占了这么多机器。原来，这些机器规模都是按照日志高峰时期设定的规模，低峰时这些机器的利用率非常低。这是有点浪费呀
小丁带着疑惑，又跑去请教领导。领导这次也有新发现：阿里云的SLS服务提供了完全Serverless的日志托管功能，也就意味着不用购买机器就可以使用SLS了。
并且它提供了一站式的日志查询、分析、可视化、告警、AIOps、Trace等各类日志功能，真是应有尽有啊。 不仅如此，它还兼容了Kafka的写入协议，也就是意味着之前的采集配置可以换一个写入端，就可以轻松写到SLS
”哎呦，不错呢“，小丁回到自己的电脑前，调研了起来，发现SLS确实很适合他的场景。 把自建的Kafka+ES的机器和SLS做了一个成本对比，发现SLS的方案可以省好一笔钱了。不仅如此，SLS提供的All In One的能力，就再也不用为各种调优和运维的问题烦恼了。 这就用起来
从此，小丁过上了幸福的程序员生活～
附：
阿里云SLS服务介绍 https://help.aliyun.com/product/28958.html
联系阿里云SLS
