开源之殇ELK
运维就要无所不能，无所不会
大家好，我是Stanley「史丹利」，今天聊聊日志服务ELK。
ELK作为日志UI产品，自诞生就备受关注，时至今日也热度不减，在Github上有着高达 54.7k的关注。
K8S、MESOS、微服务技术出现后，更助力ELK成为企业级日志系统标配。
常见的构架如下：
elk
但如上架构通常会造成
- logstash压力过大，出现数据录入延迟过大；
- 毛刺高峰数据写入甚至会拖垮 Logstash；
- 支持的Input 端有限；
等问题。为了解决如上问题，业内通用方案是在ELK再加入一个 Kafka 实时流处理器，借助 Kafka 接入海量吞吐，但"平滑"输出数据的能力，很好的解决了如上三个问题。
事已至此，新的问题和瓶颈出现在 ElasticSearch 「后面简称ES」，当数据量大到一定程度，TB级别，ES的查询和成本投入简直就是灾难现场，主要有如下问题：
- ES高内存、高CPU、高存储占用，50TB，硬件投入乐观估计在50W，费用高昂；
- 随热数据不断增加，定期清理策略逐步失效，搜索返回时间越来越长，分布、聚合优化时间恶性延长；
- 扩缩容成本巨大，技术门槛高昂；
主要优化方案有：
- 冷热数据隔离；
- 增加缓存；
- 提高数据预热频次；
- 增加分页性能优化；
但只能缓解，无法根除！自建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的数据过滤加工功能异常强大，几乎可以加工达成我们想要的任何数据。目前发现也有一些缺陷：
- 价格不便宜
- 语法入门快，深入成本不低
- 速度慢，及时性一般。首次接入测试最少6分钟后才有数据
- 数据加工后，是基于原有的logstore 复制流量修改后，重新录入到一个全新的 logstore 。即数据双份存储。成本翻倍(还不算加工的成本)
但总的来讲，sls 算是目前接触的最强大的日志产品了。
唠了这么多，最后想说的是啥呢？...别再自己折腾ES了，包括一些开源产品，公有云PAAS产品真的很香...
基于开源改造优化后的产品是真的香。。。