开源之殇ELK

2021-04-29 00:00:00 数据 成本 阿里 费用 加工

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

大家好,我是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产品真的很香...

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

来自:https://mp.weixin.qq.com/s/WRU_6TaoPnaRtVnPpGRc0Q

相关文章