说到ELK,大家会联想到ElasticSearch+Logstash+Kibana,而这里的ES却不仅仅是ElasticSearch,而是ElasticStack。
Elastic 团队在收购了 Packetbeat 团队,建立了轻量级日志系列 Beat,最终将 ELK + Beat 命名为 Elastic Stack,并将整个产品线的版本提升至 5.0。
ElasticStack族谱:
Elasticsearch 基于java,是个开源分布式搜索引擎,它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负载等。
Logstash 基于java,是一个开源的用于收集,分析和存储日志的工具。
Kibana 基于nodejs,也是一个开源和免费的工具,Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面,可以汇总、分析和搜索重要数据日志。
Beats是elastic公司开源的一款采集系统监控数据的代理agent,是在被监控服务器上以客户端形式运行的数据收集器的统称,可以直接把数据发送给Elasticsearch或者通过Logstash发送给Elasticsearch,然后进行后续的数据分析活动。
Beats由如下组成:
----整理自网络
网管系统在日常运行过程中会产生各类日志数据,比如WEB、DB以及系统等。以往我们对于日志一直又爱又恨。爱的是日志可以在异常时帮助我们定位问题,恨的是日志散布在各个角落,非常不好管理,而且我们一般都会做定期删除处理,也不便于回溯。
所以,我们急需一个可以集中收集、分析并输出表报的日志平台,毋庸置疑,ES就是最佳“人选”。既解决了日志集中收集难题,又可以灵活的组合分析、输出运维数据报表,而且整个系统还可以平行扩容。
网管这边需要收集WEB、系统以及MySQL慢日志。最开始将日志上报链路设计为:
LogFile-->Logstash-->ES-->Kibana
后面发现每台服务器都要安装logstah,实在太臃肿,从而引入了Filebeat。
Filebeat是Beat成员之一,基于Go语言,无任何依赖,并且比logstash更加轻量,非常适合安装在生产机器上,不会带来过高的资源占用,轻量意味着简单,所以Filebeat并没有集成和logstash一样的正则功能。
Filebeat会将收集的日志原样上报,若日志源程序支持json格式输出(比如Nginx或Apache),那么可以直接上报ES。但是,还有很多程序不支持修改日志格式,比如MySQL慢日志、Linux系统日志等。因此,我们使用logstash作为中间处理和转发组件。
此时,上报方案变为:
LogFile-->Filebeat-->Logstash-->ES-->Kibana
在实际应用过程中发现存在一些问题:
①、数据丢失:由于经常有新的日志类型加入,因此logstash的规则文件会经常需要修改并重启,重启时就可能丢掉一些数据;
②、热点问题:随着日志源的持续增加,难以避免会出现日志上报热点问题。
因此,这里引入Kafka,实现了发送端和接收端负载解耦,并且解决了Logstash重启丢数据的问题。
自研程序日志上报有2种可用方案:
方案①:自研程序-->生成json日志文件-->filebeat读取-->Kafka-->ES
方案②:自研程序-->生成json日志数据-->上报Kafka-->ES
对比分析2个方案,会发现都存在问题,方案①会生成额外日志文件,实在冗余;方案②在上报Kafka时使用的是TCP连接,可能会产生阻塞问题。
因此,最终在开发同学支持下引入了自研的UDPServer,使用UDP的方式收集数据,然后写入Kafka,从而解决了日志上报可能引起程序侧阻塞的隐患。
最终架构设计如下:
开源程序:filebeat负责从日志源读取数据上报到kafka,并按照日志类型指定topics,logstash通过topics从kafka读取日志,并通过filter插件进行数据处理后上报到elasticsearch,最终通过Kibana展示;
自研程序:自研程序可以自己控制日志格式,所以这里不再需要落地日志文件,而是直接按需生成json结构化日志数据,先上报到自研的UDPServer(规避应用阻塞),然后转发到Kafka,之后的路径则和开源程序日志收集方案一致。
好了,架构方面就简单介绍到这里,剩余内容请阅读后续系列文章。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。