开源之殇ELK

运维就要无所不能，无所不会

大家好，我是Stanley「史丹利」，今天聊聊日志服务ELK。

ELK作为日志UI产品，自诞生就备受关注，时至今日也热度不减，在Github上有着高达 54.7k的关注。

K8S、MESOS、微服务技术出现后，更助力ELK成为企业级日志系统标配。

常见的构架如下：

elk

但如上架构通常会造成

1. logstash压力过大，出现数据录入延迟过大；
2. 毛刺高峰数据写入甚至会拖垮 Logstash；
3. 支持的Input 端有限；

等问题。为了解决如上问题，业内通用方案是在ELK再加入一个 Kafka 实时流处理器，借助 Kafka 接入海量吞吐，但"平滑"输出数据的能力，很好的解决了如上三个问题。

事已至此，新的问题和瓶颈出现在 ElasticSearch 「后面简称ES」，当数据量大到一定程度，TB级别，ES的查询和成本投入简直就是灾难现场，主要有如下问题：

1. ES高内存、高CPU、高存储占用，50TB，硬件投入乐观估计在50W，费用高昂；
2. 随热数据不断增加，定期清理策略逐步失效，搜索返回时间越来越长，分布、聚合优化时间恶性延长；
3. 扩缩容成本巨大，技术门槛高昂；

主要优化方案有：

1. 冷热数据隔离；
2. 增加缓存；
3. 提高数据预热频次；
4. 增加分页性能优化；

但只能缓解，无法根除！自建ES的成本及问题随数据量增长，日趋明显。

综合考量，我们对自建ES和阿里SLS日志解决方案做了对比，如下为日志架构及数据存储方案对比：

架构图对比

• 关注

橘红方框为架构核心变动项。主要为 SLS 日志服务取代ELK， OSS存储取代原来的硬件存储。

除此外，我们还针对

• 收费
• 人力
• 时间
• 功能

四方面进行更为详尽的对比。

资源投入对比

这个表格算的脑壳疼，不得不说，商人就是商人，在费用计算上，永远算不清楚...和算到凌晨，还依然差了3分钱和阿里计算器对不上。

使用阿里SLS，主要费用有2大块「里面有很多其它收费项，比如读写费用、数据加工费用、投递费用等...难算。。」：

• sls应用收费
• OSS存储收费

sls收费

如果只看SLS收费，我们认为还算合理。3年总花费大概10W, 5年在17W,算是良心便宜

只用SLS吃不消，需要永久保存的数据，按架构设计放在OSS。

OSS其实才是费用一大支出。

OSS费用

3年费用在19.3w,5年大概45W, 这些费用都是基于折扣后的费用。其中OSS的花费逐年上涨，且比例攀升。主因是数据是增长且永久存放。

做一个费用整体对比

费用整体对比

依然能看的出，SLS确实在费用投入上，无论是1年、3年，还是5年，确实投入要比自建的要便宜很多，如果只用其基本功能，乐观估计，成本可以优化 39%。

诺亚现在使用的是K8S, 在k8s 环境下，接入SLS也很方便，我们目前采用的方案是 sidecar + logtail的方式。

• 开发基本无需改造；
• 新业务使用sdk的方式，无缝接入；

sls存取策略

SLS的UI大致长这个样子:

SLS UI

左侧是logstore,相当于项目的概念，基于logstore级别可以：

• 二次数据加工，这个功能非常强大；
• 基于logstore级别做权限管控；
• 自动投递数据到OSS；

sql语法很灵活：

• 支持mysql sql 语法；
• 鼠标点划自动生成语句；
• 最主要是，百亿级数据量查询速度仍然是秒级。
• 原始数据支持二次过滤、开发
• 默认支持多种类型图表UI

功能确实赞爆了。至此，我对阿里 SLS 的评价是：

sls的数据过滤加工功能异常强大，几乎可以加工达成我们想要的任何数据。目前发现也有一些缺陷：

1. 价格不便宜
2. 语法入门快，深入成本不低
3. 速度慢，及时性一般。首次接入测试最少6分钟后才有数据
4. 数据加工后，是基于原有的logstore 复制流量修改后，重新录入到一个全新的 logstore 。即数据双份存储。成本翻倍(还不算加工的成本)

但总的来讲，sls 算是目前接触的最强大的日志产品了。

唠了这么多，最后想说的是啥呢？...别再自己折腾ES了，包括一些开源产品，公有云PAAS产品真的很香...

基于开源改造优化后的产品是真的香。。。