# Elastic Stack

Elastic Stack早期的名字叫ELK,是由三个开源软件组成的数据处理框架。后期由于有新的成员加入到ELK中,ELK更名为Elastic Stack以反映其组成成员的变化情况。Elastic Stack家族成员既可以放在一起使用,也可以单独使用,它们要解决的核心问题都是数据。在当前的互联网时代,数据已经成为企业的核心财富之一。如何收集、存储并且挖掘数据价值是每一个企业必须要面对的关键问题,而Elastic Stack则给出一套完整的解决方案。正是Elastic Stack完整的方案,使得它在国内和国外得到了越来越广泛的应用。对于许多开发和运维人员来说,Elastic Stack甚至已经成为一种必须要掌握的知识。

# 从ELK到Elastic Stack

如果从单词的角度看待ELK,它的英文含义是麋鹿。所以在ELK相关的一些文献中,经常会有卡通小鹿的形象出现。但实际上ELK是三个单词的首字母缩写,即Elasticsearch、Logstash和Kibana,这三者就是ELK最初创建的成员。其中,Elasticsearch用于数据存储与检索,Logstash用于数据传输与清洗,而Kibana则用于数据可视化等领域。目前,它们由一家名为Elastic的公司司管理,并按Apache Licence 2.0开放了源代码。Elastic公司的官方网站为http://www.elastic.co (opens new window),在这个网站上包含了非常丰富的权威文档,对于学习Elastic Stack很有帮助。

# 历史

按照Elastic官方说法,ELK的一切都从Elasticsearch开始。Elasticsearch的第一个版本叫Compass,是Elastic创始人Shay Banon在2004年创建的一个搜索引擎。这个搜索引擎最初的目的是为了搜索食谱,而它的第一个用户是Shay Banon正在学习厨艺的妻子。这个搜索引擎的第二个版本基于Apache Lucene开发,并在2010年以Elasticsearch为名开源。由于Elasticsearch受到了社区用户的极大关注,Shay Banon在2012年创办了Elasticsearch公司,并于2015年更名为Elastic,专门从事与Elasticsearch相关的商业服务。由于Elasticsearch的影响不断扩大,催生了两个与其相关的开源项目,它们就是Logstash和Kibana。由于这两个项目填补了Elasticsearch在数据传输、数据可视化等方面的欠缺,所以不久之后这两个项目也加入了Elastic公司,于是ELK就这样诞生了。

在2015年,一个名为Packetbeat的开源项目引起了Elastic公司的重视。它是由一对德国夫妻设计的、以一种轻量级方式将网络数据发送到Elasticsearch的开源项目。Elastic开发团队由此引申,计划开发出一组专门用于数据传送的轻量级组件,可以将网络、日志、指标、审计等各种数据从不同的数据源头发送到Logstash或Elasticsearch。Elastic公司给这种组件起了一个统一的名字,这就是Beats组件。

Beats组件的加入,使得ELK这个名称不能再概括Elastic的所有开源项目了,于是ELK就自然而然地更名为ELK Stack。但ELK这个名称本身又有一定的缩写含义,依然容易引起误会,所以最终它们被统一称为Elastic Stack。名称的变化说明Elastic Stack不仅只是Elasticsearch、Logstash、Kibana和Beats,未来还可能会有新的软件加入其中。但它们作为一个整体,目的依然是要提供一套整体处理大数据的解决方案,包括数据的收集、清洗、整理、传输、存储、检索、应用等各个方面。

2018年10月6日,Elastic公司在纽约证券交易所挂牌上市,Shay Banon为妻子开发Elasticsearch的故事也流传得更广泛了。从Elasticsearch公司创立到最终上市只用了六年时间,演绎了又一出程序员创业的科技神话。

# 版本演变

早期,由于Elastic Stack包含的开源项目“各自为政”,每个项目都有一套自己管理版本的办法。Kibana使用betas, Logstash使用里程碑,Elasticsearch则使用数字,这使得Elastic Stack家族成员的版本异常混乱。不仅如此,由于这些开源项目的不同版本之间又无法自动处理兼容问题,使得用户必须要了解并处理不同版本之间的兼容问题。这不仅给用户造成极大困扰,Elastic开发团队也不得不维护一个巨大的版本支持表格。

2015年ELK 2.0作为一个整体同时发布,解决了版本协调同步与兼容问题,也是ELK整体迈向成熟产品的第一步。到2016年,ELK 5.0发布时,ELK整体变得更加友好、更加稳定,同时还提供了丰富的文档,使用户在入门时更加容易易掌握。尽管如此,在使用Elastic Stack时,版本问题还是存在不兼容情况。例如,由于Kibana完全基于Elasticsearch,所以Kibana和Elasticsearch主版本号必须要一致,否则将导致兼容问题。

# 许可授权

在ELK 5.0版本以后,Elastic将所有的商用插件捆绑到一个名为X-Pack的扩展中,它包含了类似安全、监控、报警等扩展功能,这应该是Elastic Stack商业化的一次尝试。在2018年2月,Elastic将这些商用X-Pack开放了源代码,但依然需要商用授权许可。在Elastic Stack文档中也有多处提及X-Pack,读者可以将它们理解为Elastic Stack的扩展组件。至2017年,Elastic发布了名为ECE(Elastic Cloud Enterprise)的云服务平台,这应该是Elastic在商业化道路上的又一次尝试。

Elastic Stack授权分为四级,即开源、基础级、黄金级和白金版,它们支持的功能依次增加。其中,开源和基础级授权所提供的功能可免费使用,而黄金级和白金版的功能则属于商业授权。在Elastic Stack早期版本上使用开源或基础级授权时存在一个非常大的问题,那就是它们都不支持用户身份认证、访问控制等基础的安全功能。所以为了保证数据安全,用户在实际商用时要么自

行开发认证和授权机制,要么使用Elastic Stack商业授权,这成为许多公司商用Elastic Stack的最大障碍之一。可喜的是,从Elastic Stack 6.8和7.1版本开始,Elasticsearch的核心安全功能(TLS加密、原生和基于文件的身份验证,以及基于角色的访问控制)已经可以免费使用了。一些高级安全功能,比如单点登录、LDAP等目前依然没有开放,但这些核心安全功能对于大多数应用来说已经足够了。

从监控的角度来看,开源和基础级授权提供了监控组件运行状态的功能,但不支持在组件运行异常时报警的功能。另外,在分布式环境下组件的集中管理功能也不被开源和基础级授权支持。但对于Beats组件来说,集中管理功能几乎是一项必备的功能。因为Beats组件往往分散于集群的各个应用中且数量众多,如果没有集中的停止和启动功能,那么Beats在管理上将是一个非常大的问题。除此之外,白金版中还提供了机器学习的相关功能,这也是当下数据应用的一个热点。

尽管如此,Elastic Stack提供的开源和基础级授权仍然可以满足实际应用中的绝大多数需求。用户可以根据需求定制使用Elastic Stack的不同授权,或是在开源授权基础之上做二次开发以满足实际需要。

# 应用场景

由于同属一个家族,Elastic Stack四大组件放在一起使用当然最为方便。Beats组件从分布式环境中的主机节点上采集数据发送给Logstash,而Logstash根据配置将数据过滤、清洗后再发送给Elasticsearch并编入索引,最后在Kibana中配置仪表盘、画布等并从Elasticsearch中读取数据将它们可视化。最典型的应用场景就是使用Elastic Stack从文件中收集日志,如图所示的就是一个在分布式环境中收集日志数据的部署图。

在典型的微服务应用场景中,日志文件分散在不同的主机节点上。这种分散的日志文件不仅不利于查看,对于日后的数据分析和数据挖掘也是很大的阻碍。但是将这些日志数据集中写入到传统的关系型数据库中又不现实,因为日志数据是典型的大数据,大多数互联网应用一天产生的日志量就有几十GB甚至上百GB。传统的关系型数据库不仅存储不了这么大量的数据,而且随着数据量的增加,查询数据也会变得越来越慢。而Elasticsearch不仅自身天然支持分片和复制,而且还可以通过倒排索引等机制来提供快速检索的能力,能够完美地解决大数据查询、存储和容灾等问题,所以使用Elastic Stack收集存储日志几乎是多数应用的备选方案之一。在图1-1中,Filebeat组件与微服务组件部署在同一台主机或同一个Docker容器中,它负责从微服务产生的日志文件中将日志采集出来并发送给Logstash。Logstash和Elasticsearch一般需要搭建成集群,以实现负载均衡和容灾容错。

An image

Elastic Stack另一个典型应用场景是系统运行状态监控。与收集日志不同的是,在这种应用场景下部署在主机节点上的Beats组件是Metricbeat或者Heartbeat,收集到的数据是系统指标数据和系统是否可达数据。这些监控数据不仅可通过Kibana轻松地实现可视化,还可以与Watcher组件或其他第三方应用结合起来实现报警功能。

除了组合在一起使用,Elastic Stack中的每一种组件又可以独立使用,或者是与第三方应用结合在一起使用。一种典型的应用场景是与Kafka等第三方MQ组件结合使用,以防止瞬间流量爆发导致的系统崩溃,如图所示。

An image

在上图中,在容器或服务器中使用Filebeat、Scribe、Flume等组件收集日志,然后发送给Kafka集群。这一方面起到了适配Logstash的作用,更重要的是Kafka集群能在流量瞬间爆发时起到削峰填谷平滑流量的作用。Logstash也可以脱离Beats和Elasticsearch作为一个数据传输管道单独使用,比如可以使用Logstash从关系型数据库中收集表格中的数据,然后将它们传输到类似MogonDB这样的NoSQL数据库中,这其实就是结构化数据实现全文检索的典型应用场景。与此同时,还可以将这些结构化数据存储到S3、HDFS等分布式文件系统中,这其实就实现了海量结构化数据的备份功能。如下图所示为Logstash在这两种场景下的部署图。

An image

另一方面,Beats组件也可以跳过Logstash直接将数据发送给Elasticsearch,甚至是类似Redis、Kafka这样的第三方数据源。在更多的应用场景中,Elasticsearch则会被单独拿出来使用。Elasticsearch在很多时候都被视为一种基于文档的NoSQL数据库,这与MongoDB的定位完全相同,所以Elasticsearch的应用场景比其他组件更加广泛。可能惟一不会独立使用的组件就是Kibana,因为至少到目前它还是基于Elasticsearch的可视化工具,所以一般都需要与Elasticsearch共同使用。

总之,无论是整体应用Elastic Stack组件,还是单独应用其中的任意一个组件,Elastic Stack都可以完全胜任。

Last Updated: 7/9/2021, 10:02:27 AM