【 ES 私房菜】系统运维数据分析平台架构

原创

张戈

修改于 2017-10-18 09:34:36

3.1K0

修改于 2017-10-18 09:34:36

文章被收录于专栏：张戈的专栏张戈的专栏

一、ES是什么？

说到ELK，大家会联想到ElasticSearch+Logstash+Kibana，而这里的ES却不仅仅是ElasticSearch，而是ElasticStack。

Elastic 团队在收购了 Packetbeat 团队，建立了轻量级日志系列 Beat，最终将 ELK + Beat 命名为 Elastic Stack，并将整个产品线的版本提升至 5.0。

ElasticStack族谱：

ElasticStack成员介绍：

1、Elasticsearch

Elasticsearch 基于java，是个开源分布式搜索引擎，它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。

2、Logstash

Logstash 基于java，是一个开源的用于收集,分析和存储日志的工具。

3、Kibana

Kibana 基于nodejs，也是一个开源和免费的工具，Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以汇总、分析和搜索重要数据日志。

4、Beats

Beats是elastic公司开源的一款采集系统监控数据的代理agent，是在被监控服务器上以客户端形式运行的数据收集器的统称，可以直接把数据发送给Elasticsearch或者通过Logstash发送给Elasticsearch，然后进行后续的数据分析活动。

Beats由如下组成:

Packetbeat：是一个网络数据包分析器，用于监控、收集网络流量信息，Packetbeat嗅探服务器之间的流量，解析应用层协议，并关联到消息的处理，其支持ICMP (v4 and v6)、DNS、HTTP、Mysql、PostgreSQL、Redis、MongoDB、Memcache等协议；
Filebeat：用于监控、收集服务器日志文件，其已取代 logstash forwarder；
Metricbeat：可定期获取外部系统的监控指标信息，其可以监控、收集 Apache、HAProxy、MongoDB、MySQL、Nginx、PostgreSQL、Redis、System、Zookeeper等服务；
Winlogbeat：用于监控、收集Windows系统的日志信息；

----整理自网络

二、用来做什么？

网管系统在日常运行过程中会产生各类日志数据，比如WEB、DB以及系统等。以往我们对于日志一直又爱又恨。爱的是日志可以在异常时帮助我们定位问题，恨的是日志散布在各个角落，非常不好管理，而且我们一般都会做定期删除处理，也不便于回溯。

所以，我们急需一个可以集中收集、分析并输出表报的日志平台，毋庸置疑，ES就是最佳“人选”。既解决了日志集中收集难题，又可以灵活的组合分析、输出运维数据报表，而且整个系统还可以平行扩容。

三、架构设计

1、引入Filebeat

网管这边需要收集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

2、引入Kafka

在实际应用过程中发现存在一些问题：

①、数据丢失：由于经常有新的日志类型加入，因此logstash的规则文件会经常需要修改并重启，重启时就可能丢掉一些数据；

②、热点问题：随着日志源的持续增加，难以避免会出现日志上报热点问题。

因此，这里引入Kafka，实现了发送端和接收端负载解耦，并且解决了Logstash重启丢数据的问题。

3、引入UDPServer

自研程序日志上报有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 删除。

java

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

java

登录后参与评论

0 条评论

热度