开源之殇ELK
运维就要无所不能，无所不会
大家好，我是Stanley「史丹利」，今天聊聊日志服务ELK。
ELK作为日志UI产品，自诞生就备受关注，时至今日也热度不减，在Github上有着高达 54.7k的关注。
K8S、MESOS、微服务技术出现后，更助力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收费，我们认为还算合理。3年总花费大概10W, 5年在17W,算是良心便宜
只用SLS吃不消，需要永久保存的数据，按架构设计放在OSS。
OSS其实才是费用一大支出。
3年费用在19.3w,5年大概45W, 这些费用都是基于折扣后的费用。其中OSS的花费逐年上涨，且比例攀升。主因是数据是增长且永久存放。
做一个费用整体对比
依然能看的出，SLS确实在费用投入上，无论是1年、3年，还是5年，确实投入要比自建的要便宜很多，如果只用其基本功能，乐观估计，成本可以优化 39%。
诺亚现在使用的是K8S, 在k8s 环境下，接入SLS也很方便，我们目前采用的方案是 sidecar + logtail的方式。
开发基本无需改造； 新业务使用sdk的方式，无缝接入；
SLS的UI大致长这个样子:
左侧是logstore,相当于项目的概念，基于logstore级别可以：
二次数据加工，这个功能非常强大； 基于logstore级别做权限管控； 自动投递数据到OSS；
sql语法很灵活：
支持mysql sql 语法； 鼠标点划自动生成语句； 最主要是，百亿级数据量查询速度仍然是秒级。 原始数据支持二次过滤、开发 默认支持多种类型图表UI
功能确实赞爆了。至此，我对阿里 SLS 的评价是：
sls的数据过滤加工功能异常强大，几乎可以加工达成我们想要的任何数据。目前发现也有一些缺陷：
价格不便宜 语法入门快，深入成本不低 速度慢，及时性一般。首次接入测试最少6分钟后才有数据 数据加工后，是基于原有的logstore 复制流量修改后，重新录入到一个全新的 logstore 。即数据双份存储。成本翻倍(还不算加工的成本) 但总的来讲，sls 算是目前接触的最强大的日志产品了。
唠了这么多，最后想说的是啥呢？...别再自己折腾ES了，包括一些开源产品，公有云PAAS产品真的很香...
基于开源改造优化后的产品是真的香。。。