从ELK到ELFK的转变，知足企业PB级日志系统的实践之路

一： ELK日志系统初期

刚来公司的时候，咱们公司的日志收集系统ELK常常会出现查询不了最新的日志的状况，后面去查发现 ES的节点常常也是yellow或者red的状况。有时候会收到开发的投诉。这一套ELK系统也是另一个同事搭建的，

架构图解以下:

其中ElasticSearch 是三台服务器构成的集群，

其中ElasticSearch的版本为 6.2.x 的版本，Logstash跑在每一个服务器上，各类日志经过Logstash搜集，Grok，Geoip等插件进行处理而后统一送到ElasticSearch的集群。

Kibana作图形化的展现。

咱们以前的elk架构比较简单，也存在一些问题：

一、Logstash依赖Java虚拟机占用系统的内存和CPU都比较大，

二、Logstash在数据量较大的时候容易致使其余业务应用程序崩溃，影响业务正常使用

三、随着时间的积累，es空间不能知足现状

四、Kibana没有安全管控机制，没有权限审核，安全性较差。

五、ElasticSearch 主节点也是数据节点，致使有时候查询较慢

二： ELK日志系统改进之引入Filebeat

ElasticSearch的版本，咱们仍是选择原来的 6.2.x的版本，而后从新搭建了一套ELK的日志系统。

ElasticSearch 6.x 的版本若是要作用于鉴权的话，必须依赖X-Pack，可是X-pack是付费的产品，因而咱们在网上寻找破解补丁，而后对ElasticSearch 6.x 进行破解。

架构图解以下:

整个架构的具体的改进方法以下:

一、客户端选用更轻量化的Filebeat，Filebeat 采用 Golang 语言进行编写的，优势是暂用系统资源小，收集效率高。

二、Filebeat 数据收集以后统一送到多个 Logstatsh进行统一的过滤，而后将过滤后的数据写入ElasticSearch集群。

三、将原有的3个es节点增长至6个节点，其中3个ES节点是master节点，其他的节点是数据节点，若是磁盘不够用能够横向扩展数据节点。

四、引入x-pack，实现 Index 级别的权限管控，确保数据安全。

五、ElasticSearch集群的硬盘采用 SSD的硬盘

到此，咱们的日志系统算暂时是正常而且能知足日志查日志的需求了，也不多出现卡顿的现象了，而且服务器的资源使用率直接降低了一半。

可是要查几个月以前的数据仍是会慢，因而咱们在上面的基础上又作了下面几个优化:

六、ElasticSearch 作冷热数据分离

七、60天以前的索引数据进行关闭，有须要用的时候手工打开

八、ElasticSearch的版本采用ElasticSearch 7.x的版本，用户鉴权采用其免费的 basic 认证明现（由于7.x的新版本在性能上优化，查询和写入速度会更快）

 三： ELK日志系统改进之ELFK

由于咱们的主要业务的开发语言是PHP，PHP产生的 日志并很少，可是PHP毕竟是解释性的语言，运行效率并不高，可是咱们公司业务并发却很是高。并发至少有10万以上。有些业务是Java，好比位置上报的业务，微服务也是公司本身开发的，多是框架也不完善，不像Spring Boot那样成熟，打出的日志特别多，一个Java的微服务天天就要产生就几个T的数据。有些微服务的日志仍是info级别的。

随着时间的积累，日志量有几百T以及有PB级别的日志量了。

同时大数据部门也是查ElasticSearch集群的接口，致使ElasticSearch的压力特别大。这样致使有时候查询历史日志会很慢。

目前采用的 Filbeat + Logstash+ ElasticSearch+ Kibana的架构已经没法知足需求了。因而咱们想到使用MQ进行缓冲，消息队列进行缓冲那应该选哪一个产品了，消息中间件考虑的几个软件又 Redis，Rabitmq，ActiveMq，Kafka等，对于这几个的考虑咱们坚决果断的选择了Kafka，由于Kafak的吞吐量比其余都高，Kafka性能远超过ActiveMQ、RabbitMQ等。

架构图解以下:

整个架构的具体的改进方法以下:

一、Filebeat数据收集以后存放于kafka，而后用 Logstash来逐条消费，写入es，确保数据的完整性。

二、Logstash 跑多个节点多个进程以及多线程进行消费。

三、Kafka 多Topic 多分区存储，从而保证吞吐量。

四、大数据部门从开始的直接查ElasticSearch集群的接口，改为直接消费Kafka的数据，这样ElasticSearch的压力下降了很多。

到此，就目前的架构已经知足企业的PB级的日志需求了，查历史日志也不卡了，也能知足平常的需求。

当咱们经过 Kafka—Manager 去监控和 管理 Kafka 的状态信息的时候，发如今业务高峰期的时候，Kafka的topic有不多量的堆积，

可是并不影响开发和运维查日志。因而爱折腾的我，决定本身手工写程序代替 Logstash消费，因而有了下面的内容。

四：  Filbeat+Go+ElasticSearch+Kibana 日志收集系统架构

若是本身写程序代替 Logstash消费，本身熟悉的语言是Python 和 Golang，因而决定用这二者中的其中一个进行编写，考虑到Python是解释性语言，有全局锁的限制。而 Golang 是编译型语言，并且天生支持协程。支持并发。因此采用 Golang进行kafka消费

架构图解以下:

整个架构的具体的操做方法以下:

一、不一样的日志类型创建不一样的 topic

二、Filebat打不一样的tag采集数据到不一样的 topic

三、Golang 开启协程消费不一样的 topic发送到ElasticSearch集群

到此咱们再使用 Kafak-Manager去查看Kafka的状态信息以后，即使再高峰期也不会出现消息少许堆积的状况了

 

五： 经验记录

针对从ELK到ELFK的架构演变，因而本身录制了视频在51CTO上，分享给你们。点击下面的超连接便可。

ELK/ELFK（7.3版本）企业PB级日志系统实战