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

一： ELK日志系统初期

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

创新互联建站专业为企业提供郴州网站建设、郴州做网站、郴州网站设计、郴州网站制作等企业网站建设、网页设计与制作、郴州企业网站模板建站服务，十载郴州做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

架构图解如下:

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

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

Kibana做图形化的展示。

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

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

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

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

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

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

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

ElasticSearch的版本，我们还是选择原来的 6.2.x的版本，然后重新搭建了一套ELK的日志系统。

ElasticSearch 6.x 的版本如果要做用于鉴权的话，必须依赖X-Pack，但是X-pack是付费的产品，于是我们在网上寻找破解补丁，然后对ElasticSearch 6.x 进行破解。

架构图解如下:

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

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

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

3、将原有的3个es节点增加至6个节点，其中3个ES节点是master节点，其余的节点是数据节点，如果磁盘不够用可以横向扩展数据节点。

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

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

到此，我们的日志系统算暂时是正常并且能满足日志查日志的需求了，也很少出现卡顿的现象了，并且服务器的资源使用率直接下降了一半。

但是要查几个月之前的数据还是会慢，于是我们在上面的基础上又做了下面几个优化:

6、ElasticSearch 做冷热数据分离

7、60天之前的索引数据进行关闭，有需要用的时候手工打开

8、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等。

架构图解如下:

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

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

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

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

4、大数据部门从开始的直接查ElasticSearch集群的接口，改成直接消费Kafka的数据，这样ElasticSearch的压力降低了不少。

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

当我们通过 Kafka—Manager 去监控和 管理 Kafka 的状态信息的时候，发现在业务高峰期的时候，Kafka的topic有很少量的堆积，

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

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

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

架构图解如下:

整个架构的具体的操作方法如下:

1、不同的日志类型建立不同的 topic

2、Filebat打不同的tag采集数据到不同的 topic

3、Golang 开启协程消费不同的 topic发送到ElasticSearch集群

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

五： 经验记录

针对从ELK到ELFK的架构演变，于是自己录制了视频在51cto上，分享给大家。点击下面的超链接即可。

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