十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
这篇文章给大家分享的是把ELK日志系统改进成ELFK的方法,相信大部分人都还没学会这个技能,为了让大家学会,给大家总结了以下内容,话不多说,一起往下看吧。
创新互联建站主营相山网站建设的网络公司,主营网站建设方案,成都app开发,相山h5小程序开发搭建,相山网站营销推广欢迎相山等地区企业咨询刚来公司的时候,我们公司的日志收集系统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 主节点也是数据节点,导致有时候查询较慢
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的新版本在性能上优化,查询和写入速度会更快)
因为我们的主要业务的开发语言是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消费,于是有了下面的内容。
如果自己写程序代替 Logstash消费,自己熟悉的语言是Python 和 Golang,于是决定用这两者中的其中一个进行编写,考虑到Python是解释性语言,有全局锁的限制。而 Golang 是编译型语言,而且天生支持协程。支持并发。所以采用 Golang进行kafka消费
架构图解如下:
整个架构的具体的操作方法如下:
1、不同的日志类型建立不同的 topic
2、Filebat打不同的tag采集数据到不同的 topic
3、Golang 开启协程消费不同的 topic发送到ElasticSearch集群
到此我们再使用 Kafak-Manager去查看Kafka的状态信息之后,即便再高峰期也不会出现消息少量堆积的情况了
关于把ELK日志系统改进成ELFK的方法就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果喜欢这篇文章,不如把它分享出去让更多的人看到。
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。