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

一、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,之后的路径则和开源程序日志收集方案一致。

好了,架构方面就简单介绍到这里,剩余内容请阅读后续系列文章。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏人人都是极客

聊聊Linux IO(下)

广义上Cache的同步方式有两种,即Write Through(写穿)和Write back(写回). 从名字上就能看出这两种方式都是从写操作的不同处理方式引出...

981
来自专栏QQ空间开发团队的专栏

TPatch动态补丁系统(iOS)

对于每一个开发,从写Hello World开始,到使用各种语言,可能都会遇到各种BUG。有的BUG能快速解决,比如Web侧的,发个JS或者Html即可。但是在终...

2.4K0
来自专栏aCloudDeveloper

冲突域和广播域的区分

一、概念理解: 1、冲突域(物理分段): 连接在同一导线上的所有工作站的集合,或者说是同一物理网段上所有节点的集合或以太网上竞争同一带宽的节点集合。这个域代表了...

2346
来自专栏双十二技术哥

Android性能优化(一)之启动加速35%

随着项目版本的迭代,App的性能问题会逐渐暴露出来,而好的用户体验与性能表现紧密相关,从本篇文章开始,我将开启一个Android应用性能优化的专题,从理论到实战...

1273
来自专栏IT大咖说

基于Go的MongoDB实时同步工具及 Docker 化实践

摘要 讯联数据高级软件工程师马艳云分享了基于Go的MongoDB实时同步工具Magisync及 Docker化实践。 ? Magisync是什么 Magisyn...

3494
来自专栏coding

RabbitMQ实战1.消息代理01.消息代理02.安装RabbitMQ03.生产者-消费者模式04.队列操作

肯定不是,这种直接与生产者交易的成本太大了!大到不可承受。因此有了中间商的存在。中间商将生产者与消费者的所有环节都透明化,使最终的交易流程极其简单。

531
来自专栏杨建荣的学习笔记

闪回数据库不是“万金油”(r11笔记第73天)

闪回数据库这个特性在很多Oracle DBA眼里就是鸡肋特性,因为谁会因为恢复数据而需要在主库闪回,最后可能丢掉更多的数据,这个观点没错。 但是...

3156
来自专栏北京马哥教育

Linux内存被吃掉了,它去哪里了?

在Windows下资源管理器查看内存使用的情况,如果使用率达到80%以上,再运行大程序就能感觉到系统不流畅了,因为在内存紧缺的情况下使用交换分区,频繁地从磁盘上...

882
来自专栏美团技术团队

Mt-Falcon——Open-Falcon在美团点评的应用与实践

前言 监控系统是整个业务系统中至关重要的一环,它就像眼睛一样,时刻监测机房、网络、服务器、应用等运行情况,并且在出现问题时能够及时做出相应处理。 美团点评刚开始...

5385
来自专栏技术分享

后端服务性能压测实践

后端服务性能压测实践 标签(空格分隔): 性能 压测 后端服务 压测实践 作者:王清培(Plen wang) 背景 环境检测 压力机及压力工具检测 Linux...

4059

扫码关注云+社区