【 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 条评论
登录 后参与评论

相关文章

来自专栏大数据架构

Spark 灰度发布在十万级节点上的成功实践 CI CD

目前主流的代码管理工具有,Github、Gitlab等。本文所介绍的内容中,所有代码均托管于私有的 Gitlab 中。

1062
来自专栏恰同学骚年

Hadoop学习笔记—14.ZooKeeper环境搭建

从字面上来看,ZooKeeper表示动物园管理员,这是一个十分奇妙的名字,我们又想起了Hadoop生态系统中,许多项目的Logo都采用了动物,比如Hadoop采...

662
来自专栏容器化

转载NodePort,LoadBalancer还是Ingress?我该如何选择 - kubernetes

2524
来自专栏Java技术

ELK Stack之Beats简介

Beats 是ELK Stack技术栈中负责单一用途数据采集并推送给Logstash或Elasticsearch的轻量级产品。

815
来自专栏程序你好

使用服务网格增强安全性:Christian Posta探索Istio的功能

Istio帮助使“服务网格”概念变得更加具体和可访问,随着Istio 1.0的最新发布,我们可以预期人们对它的兴趣会激增。Jasmine Jaksic在Info...

722
来自专栏PHP技术

不同场景下 MySQL 的迁移方案

原文出处: 温国兵(@dbarobin) 一 为什么要迁移 MySQL 迁移是 DBA 日常维护中的一个工作。迁移,究其本义,无非是把实际存在的物体挪走,...

3955
来自专栏散尽浮华

Redis+TwemProxy(nutcracker)集群方案部署记录

Twemproxy 又称nutcracker ,是一个memcache、Redis协议的轻量级代理,一个用于sharding 的中间件。有了Twemproxy,...

26310
来自专栏张善友的专栏

为首次部署MongoDB做好准备:容量计划和监控

如果你已经完成了自己新的MongoDB应用程序的开发,并且现在正准备将它部署进产品中,那么你和你的运营团队需要讨论一些关键的问题: 最佳部署实践是什么? 为了...

2418
来自专栏idba

有赞MySQL自动化运维系统--ZanDB

有赞作为"新零售"的软件服务供应商,随着业务的不断发展,从第一批几十家商户到现在300万商家,涉及零售,美业,餐饮,自媒体等众多商家,业务规模以及访问量爆发式...

1222
来自专栏Hadoop实操

CDH5.14和CM5.14的新功能

Fayson在2017年的10月12日介绍了《CDH5.13和CM5.13的新功能》,今天1月26日,Cloudera正式发布了CDH5.14。三个月零几天,2...

1K6

扫码关注云+社区