从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+Kafka+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的架构演变，于是自己录制了视频(扫描二维码即可观看)：