ELK的崛起(Rise of the ELK)

前言

忽如一夜春风来,千树万树梨花开,恍惚之间,ELK亦是遍地开花,甚至提供类似ELK解决方案的专业公司数量已然可观。

ELK的用途

传统意义上,ELK是作为替代Splunk的一个开源解决方案。Splunk 是日志分析领域的领导者。日志分析并不仅仅包括系统产生的错误日志,异常,也包括业务逻辑,或者任何文本类的分析。而基于日志的分析,能够在其上产生非常多的解决方案,譬如:

  1. 问题排查。我们常说,运维和开发这一辈子无非就是和问题在战斗,所以这个说起来很朴实的四个字,其实是沉甸甸的。很多公司其实不缺钱,就要稳定,而要稳定,就要运维和开发能够快速的定位问题,甚至防微杜渐,把问题杀死在摇篮里。日志分析技术显然问题排查的基石。基于日志做问题排查,还有一个很帅的技术,叫全链路追踪,比如阿里的eagleeye 或者Google的dapper,也算是日志分析技术里的一种。

  2. 监控和预警。 日志,监控,预警是相辅相成的。基于日志的监控,预警使得运维有自己的机械战队,大大节省人力以及延长运维的寿命。

  3. 关联事件。多个数据源产生的日志进行联动分析,通过某种分析算法,就能够解决生活中各个问题。比如金融里的风险欺诈等。这个可以可以应用到无数领域了,取决于你的想象力。

  4. 数据分析。 这个对于数据分析师,还有算法工程师都是有所裨益的。

为啥ELK突然火了?

ELK之前,有没有类似解决方案呢? 某大神说是有的,当时应该是基于 Sphinx + Google char的。 Sphinx 对应ES, Google char 对应 Kibana。

那为啥当时它没有火而现在的ELK火了呢?一种比较玄幻的解释是:

事实上开源界永远有多种选择,比如基于java的lucene的es,也有基于c的lucy的dezi。但是谁火谁不火,真的是一个很玄妙的事情

我觉得原因有很多方面。一个简单而较为核心的因数是时机。所谓时势造英雄是也。

当然,任何一件事情不可能是一个因子引起的,或者我们说时机是一个较为宽泛抽象的因子。

下面我会尝试从多个因子去阐述为什么ELK突然蓬勃发展。

数据(日志)的日益增多

早年能够产生足够数据的就那么一些站点,而现在一个初创的企业可能都需要面临海量用户/海量请求/海量分析的压力,其中产生的日志自然也是非常可观,而随着业务越来越复杂,微服务重新得到重视,无论系统日志,还是业务日志都更进一步了。运维或者开发们发现,我要从这么大规模的系统中(几百个上千个服务)产生的这么多日志(千亿规模),去排查问题,简直是没有可能了。以前有这么大数据量的公司,都是有实力的公司,他们可能有内部专用的系统去处理。然而现在突然成为了一个普遍需求,这个时候ELK顺势而上,也就水到渠成。

开源

开源现在已经融入到IT社区的血液里。虽然我们说商业,自研,还有开源三者之间是相辅相成,相濡以沫或者偶尔会相爱相杀,但是如果有开源可以选择,显然大部分开发或者运维还是首选开源的。有位大牛说的好:

开源及其便利性,开源的好处,学习成本底,招一个人就能培养他开干,一个内部维护的系统,新人上火总会问题很多;比如要重构还不如重写,或者不愿在人家的代码基础上开发

ELK其开源属性,显然是比Splunk 略胜一筹的。

行业属性

有些行业对日志的依赖是非常大的,比如 CDN 日志除了能排查错误,对其分析还能对CDN调度等很多方面产生影响,这些都是实打实的经济效益。

运维自身发展

运维本身也在发展,不可能一直在刀耕火种的年代。而日志对于运维来说,应该算是命根子了。对一个成体系的,标准化的日志分析方案的需求,也是历史发展的必然。ELK在恰当的时候产生,运维接受他就是自然而然的了。

ELK自身属性问题

引用一位大神的说法:

ELK能解决的核心问题,覆盖面也广,标准化,易扩展集成,开发和运维都对其感冒

ELK 本身非常易用,现在也有一个非常好的社区,加上需求如此之大,不火都不行。

大数据导致机器开始变得廉价

大数据的一个很好的副作用是让机器在某种意义上变得廉价了。少则几十上百台,多则上万甚至几十万台。服务器数量的急速攀升促进了很多技术的发展,典型的比如现在火的不要不要的深度学习。这就意味着,拿出几十台,上百台服务器做日志分析,一点问题也没有,集中式的日志分析慢慢成为主流。而ELK也是一个典型的集中式日志分析方案。

写入时计算->查询时计算

所谓写入时计算是指将数据经过较为复杂的处理,聚合,得到的结果直接面向查询。 写入时计算规则由查询需求决定。

随着存储格式的不断进步,譬如列式存储等的普及,以及强大的计算资源(一个ES集群动则上百台),使得直接存储原汁原味的数据,然后查询的时候做各种计算变得可能。而ELK已经提供较为强大的查询功能。

总体而言,写入时计算的大方向是往查询时计算转化。查询时计算最大的优势是支持任意查询,不丢失信息。

总结

每个时期的软件们兴衰,就像历史长河中的各个王朝一样。有百花齐放的时候,也有一统江湖的时候。ELK的崛起,最主要还是大势造就而成,譬如移动互联网冲击,大数据/云计算的火热,技术的更新换代,运维/开发群体的不断的成长。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,029评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,395评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,570评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,535评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,650评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,850评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,006评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,747评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,207评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,536评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,683评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,342评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,964评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,772评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,004评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,401评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,566评论 2 349

推荐阅读更多精彩内容