一万台云服务器如何监控:G云平台搭建监控统计体系的实践

嘉宾介绍:  夏学锋  

盛大游戏G云平台研发负责人

内容概要:

今天和大家分享的是G云平台搭建监控统计体系的实践。

监控统计数据能够帮助业务方正确和及时的了解系统的运行状态,发现影响整体系统运行的瓶颈,帮助系统维护、开发人员进行必要的优化和改造,以及为系统的升级和扩容提供重要的依据。

我们今天聊的话题和开源的软件如Zabbix, Nagios, Cacti等的关联不多,主要聊聊怎么利用Kafka、Elasticsearch快速搭建可高度定制、能存储非常非常非常非常久远监控历史数据,在跨越长时间段查询数据时不需要长时间等待的监控统计体系。

本主题的关键词:Kafka,Elasticsearch,消息队列,分布式,高可用。

主题目录

分享的内容由五部分组成:

一、Kafka简介

二、Elasticsearch简介

三、我们的目标

四、搭建实践

五、部分成果展示

内容分享

一、Kafka 简要介绍

      Apache Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发,之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的,分区的和可复制的提交日志服务。

Apache Kafka与传统消息系统相比,有以下不同:

1.      它被设计为一个分布式系统,易于向外扩展;

2.      它同时为发布和订阅提供高吞吐量;

3.      它支持多订阅者,当失败时能自动平衡消费者;

4.      它将消息持久化到磁盘,因此可用于批量消费。

借用网上几个热门消息队列测试对比图:

可见Kafka在消息生产和消费的处理效率上明显要高于另外两者。

目前越来越多的开源分布式处理系统都支持与Kafka集成。

二、  Elasticsearch 简要介绍

Apache Lucene是一个非常高效的全文检索引擎的架构,提供了完整的查询引擎和索引引擎,部分文本分析引擎。 但是Lucene只是一个框架,要充分利用它的功能,需要很多的学习和了解才能明白它是如何运行的,Lucene确实非常复杂。

Elasticsearch使用Lucene作为内部引擎,但它并不仅仅是Lucene这么简单,它不但包括了全文搜索功能,还可以进行以下工作:

1. 分布式实时文件存储,每一个字段都可以被索引和搜索;

2. 实时分析的分布式搜索引擎;

3. 扩展能力非常强,也非常简单,能够处理PB级别的结构化或非结构化数据。

Elasticsearch的使用非常简单,它附带了很多非常合理的默认值,这让初学者很好地避免一上手就要面对复杂的理论,通过它的RESTfulAPI可以非常轻松的完成数据的索引和查询。

早在2013年github.com就开始使用Elasticsearch 索引了20TB的数据,包括13亿的文件和1300亿行的代码。(官方介绍https://github.com/blog/1381-a-whole-new-code-search )

三、  我们的目标

1. 扩大监控统计对象和规模

云计算服务需要监控的对象包括底层硬件、云计算平台各服务、虚拟机、虚拟机内部跑的业务、业务客户端产生和汇报上来的数据等等一系列需要监控的数据尽可能提供简单快速,稳定的接入方式完成接入。

2. 集中监控与报警

将需要监控的对象和报警规划统一到一个监控平台上进行管理,实现故障与异常的实时发现与通知。

3. 稳定和高效

稳定和高效率是监控平台最基础和最重要的功能,云主机和业务产生的数据往往会出现指数级的增长,稳定的接收和高效的分析监控统计数据是监控统计系统的源动力。

4. 良好的扩展性

要解决数据越存越多导致分析和展示数据越来越慢的问题,就需要解决计算和存储能力水平扩展,以分布式计算和存储为主体设计思想的软件和服务是我们优先考虑使用和整合的目标。

四、搭建实践

整个监控统计系统说简单点就是数据的收集和分析过程。让业务场景中的数据能尽快的汇报到平台上,并且能快速对这些数据进行一次或多次的分析和汇总,这就是我们要搭些服务,写些代码进行整合的工作。

本次话题中,限于时间和篇幅原因我们不深入讨论Kafka、Elasticsearch如何做到高可用,它的高可用原理是什么等话题,这方面官方网站以及网上有太多资料可以查看。

我们关注的焦点是怎么将这些服务利用起来,整合到我们的监控统计体系中。

我们搭建的监控统计体系整体分成六个部分组成:

1. 数据采集代理

2. 数据接收服务端

3. 消息队列服务

4. 数据分析服务

5. 数据索引、查询服务

6. 管理平台

1. 数据采集代理

统计数据的来源点非常复杂,有硬件、软件之分,有系统层、应用层之分,有服务提供方、业务使用方之分,有服务端上报、客户端、移动终端上报之分。不管来源和分类如何复杂这些数据最终是上报到服务端,如果服务端不可用,数据上报就可能出现丢失或有很长时间的延时,因此我们设计出数据采集代理模块,它的功能可以简单的理解为带本地缓存的Proxy。

它具有以下主要功能和特点:

a) 使用Go语言编写,独立文件无依赖,多并发无压力;

b) 本地开启http服务接收业务接收业务系统上报的数据;

c) 和服务接收服务端保持TCP长连,将http接收到的数据由TCP通道转发给数据接收服务端,并且通过消息确认机制确保投递成功;

d) 本地有独立的key-value数据库,未投递到服务端的数据在本地保存,消息和重传机制确保离线消息能再次投递到服务端;

e) 本地有定时任务模块,定期从服务端获取并在本地指定时间或周期性的执行数据采集,日志清理等任务;

f) 完善的自我更新机制,通过数据接收服务端的版本比较和通知能实时和自动的进行自我更新,不需要人工干预。

数据采集代理拓扑图如下:

2. 数据接收服务端

数据采集代码上报的数据需要有接收方将这些数据存储起来,之后进行分析,同时也因业务和场景不同需要开启很多套数据接收的服务,因此我们将数据接收和存储的封装为一个服务。

此服务具有以下功能和特点:

a) 使用Go语言编写,高并发下性能依然强劲;

b) 开启监听服务,接收客户端长连接和转发进来的统计数据;

c) 使用连接池与消息队列服务长连,将TCP接收到的数据PUSH给消息队列服务;

d) PUSH给消息队列的消息如未成功侧将消费写入到MySQL数据库,由后续重传机制从MySQL中读出重新投递给消息队列服务;

e) 根据客户端的类型、角色、特定IP等条件的分类和筛选,主动下发和被动查询定时任务;

f) 通过版本对比、手动触发更新等机制强制或提醒客户端自动更新;

g) 记录时间点和消息位于消息队列中offset的关联关系,后续重新跑数据时可根据时间点快速定位到消息队列中指定位置的消息。

数据接收服务端拓扑图如下:

测试时单节点长连100W万客户端

3. 消息队列服务

消息队列服务由Kafka提供,Kafka本身的实现复杂,但配置和使用确是很简单的,上默认配置就可以跑,搭建集群需要配置的参数也不多。消息队列服务具有以下功能和特点:

a) 提供消息生产、消费通道;

b) 分布式持久化保存消息数据,支持读取历史消息;

c) 分布式多副本提高生产和消费的效率;

d) 增加节点能线性提高生产性能和存储容量;

e) 按时间点记录消息存储于消息队列中的位置,方便按时间点对消息进行重新分析和处理;

f) 消息和重传机制确保接收到的消息一定会投递到消息队列中;

g) 提供API接口达到给客户端下发配置文件或任务;

消息队列服务拓扑图如下:

4. 数据分析服务

数据分析服务的逻辑就是从消息队列中取出数据,进行分析和计算,并将最终需要报表和查询的数据存储到搜索服务中。

此服务具有以下功能和特点:

a) 消息队列消费者,同一消息队列可同时产生一个或多个消费者进行处理

b) 从消费队列中读取数据进行解析,从本地缓存和搜索服务中查询时间段或汇总数据进行计算,并将结果写入缓存或搜索服务中。

c) 从平台读取告警规则,如消息或汇总数据达到预警要求侧触发相应的告警提醒逻辑

数据分析服务拓扑图如下:

5. 数据索引、查询服务

索引和查询服务由Elasticsearch提供,与Kafka类似Elasticsearch服务的配置也不需要花费太多的时间和精力,看配置文件中的注释就可以快速完成集群的配置。

此服务具有以下功能和特点:

a) 分布式实时文件存储,每一个字段都可以编入索引,可以被搜索

b) 实时分析的分布式搜索引擎

c) 可以扩展到上百台服务器,处理PB级别的结构化或非结构化数据

搜索服务拓扑图如下:

6. 管理平台

管理平台其实只是为了方便查看报表和查询数据为自动化处理做一些配置的修改的更新,对统计体系来说不是必要的组成部分。

它提供以下功能:

a) 用户和授权的管理

b) 数据的查询和报表

c) 告警规则的定制

d) 采集任务的下发

以上几个模块组成的完整拓扑图如下:

五、 成果

监控统计体系搭建完成后达到了预期的效果,尤其在数据的收集、存储和展示方面,整体系统运行状况良好。目前G云及相关服务、业务的监控统计全部基于此体系,更多的业务接入需要做的是针对业务或需求进行数据分析脚本的开发,此部分框架、逻辑和流程都已经很完备,接需进行即可。

截取部分节点运行状况图看看当前运行情况:

数据接收服务端单个节点当前接收到近1万个上报的数据请求,系统正常无压力。

数据分析和处理节点开多个进程同时处理8个分区的数据

一部分云主机统计数据在kafka中分布情况:

Elasticsearch部分索引分布图,其中第二个索引两周产生1亿条记录,查询响应效率在0.1秒内

Elasticsearch三个节点资源占用情况

今天的主题到这里就结束了,纯属我们实践过程的小总结,希望能带给大家一些解决问题的思路和方法。如有不正确的地方欢迎指正。

Q&A

1、请问你们这套系统和小米公司的监控比,各有哪些优缺点?

答:小米的监控系统有点类似于zabbix可以说是一套比较整的监控平台,我们的系统其实更接近于统计系统,和业务系统能更紧密的绑到一起。

2、es这3个节点的服务器配置是什么样的?

答:跑在一台虚拟机中,8核16G,给es服务分配了最大10G内存

3、跑Kafka 和 elastic search 的是物理机还是容器,大概的性能配置什么样。

答:kfk, es都是跑在虚拟机中,8核16G,分配给es的内存在6-10G之间,硬盘空间稍有不同。

4、你们的系统也开源吗?

答:没有开源,我们做的其实就是整合,主要的服务是开源的,我们写了些代码整合起来。你自己做的话花比较少的时候也能实现。

5、kafka 配置是什么?  副本与分区数是如何分配?   删除旧数据是使用什么规则.  kafka 写入es

答:kfk 的操作系统8核16G,分给kfk的在4-8G内存。副本是3份,只是在不同的节点,数据保留周期不一样,两台保留1年,一台保留2年。

6、Elasticsearch在传统的数据库中  文本是怎么被搜索的?

答:这个是搜索引擎,全文搜索是基本功。

7、elk怎么做到查询过滤?

答:es 有一套自己的query dsl,建议查下资料看看,这套接口非常强大。这是官方文档https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html

8、请问下你们的日志量有多大?存储多久?才三个节点,内存都是接近10G,查询比较久的日志不会发生es主机的内存用光从而导致es崩溃吗?这个是如何优化的?

答:日志量非常大,我们准备了16T空间用来存储,数据存储是在kfk中的,kfk以是文本方式存储日志文件,有自己的索引格式。

es查询数据其实是走索引,对内存的要求倒没有像influxdb那么高。我们在测试过程中发现使用非常大量的并发写数据时内存小会有影响,但10G内存在我们当前阶段还算够用。等不够的时候增加内存也只需要关掉一个节点,增加内存开起来就行。


文章标签: Kafka 消息 分布式


关注微信公众号“架构说”,加入Q群微群,让架构师带你飞︿( ̄︶ ̄)︿。


原文链接: 阅读原文
免责申明: 架构说任何转载的文章都会明确标注原文链接。如有侵权,请与本站联系。
转载说明: 架构说原创文章转载时请务必注明文章作者、链接和来源。