这篇文章给大家分享的是把ELK日志系统改进成ELFK的方法，相信大部分人都还没学会这个技能，为了让大家学会，给大家总结了以下内容，话不多说，一起往下看吧。

专注于为中小企业提供成都网站设计、成都网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业麒麟免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了上千企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

一： 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的方法就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果喜欢这篇文章，不如把它分享出去让更多的人看到。

当前文章：怎样把ELK日志系统改进成ELFK
文章链接：http://scyanting.com/article/iedphg.html