运营 2.0 时期:数据聚合和分组

图片 1

运维 2.0 时代

运维 2.0
是指,从技术运维升级为服务运维,向公司提供可依赖的专业服务。运维 2.0
强调服务交付能力,而不是技术能力,需求可依赖、懂业务、服务化的专业运维。

为了了解运维 2.0
时代的监控方式,我们不妨从以前的监控手段说起。首先来了解一下 Zabbix
,通过 Zabbix
能够监视各种网络参数,保证服务器系统的安全运营;并提供灵活的通知机制以让系统管理员快速定位和解决存在的各种问题。但时代在推进,如今
Zabbix 的功能真的就能满足广大开发者们么?

图片 2

如果你是阿里云的用户,或者使用过
Zabbix,你将明显感受到一个痛点:没有办法对数据做聚合,只能挨个查看主机的性能指标,更不用说有管理的功能了。

如上图,Zabbix 只提供单台 Host 的 Disk 使用量。如果 3
台主机,同属于一个组 Mi-Kafka,就没法知道这个组总体 Disk 使用量了。

因此,就算线上系统发生了故障,要在短期内知道,到底是哪个模块的哪个部分出了什么样的问题,所需要的经验和时长都是巨大的。

而 OpenTSDB 和 StatsD 的出现改变了现状。

OpenTSDB
是什么呢,一个开源监控系统,可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的
Metrics 同时进行存储、索引以及服务,从而使得这些数据更容易让人理解。

近年来,短视频与直播业务的爆发,也让CDN行业迎来了新的发展机遇和挑战。这些挑战主要体现在运维上,可分为两方面:一是出现故障时的响应速度,这需要CDN服务商能够以最快的速度发现和处理故障。二是质量的提升,视频类客户的卡顿率往往是评判各家CDN厂商服务质量的首要标准,这要求服务方必须具备过硬的调优能力,因此,快速分析感知细微的质量变化、定位质量变化的原因就至关重要。

运维 2.0 时代

运维 2.0
是指,从技术运维升级为服务运维,向公司提供可依赖的专业服务。运维 2.0
强调服务交付能力,而不是技术能力,需求可依赖、懂业务、服务化的专业运维。

为了了解运维 2.0
时代的监控方式,我们不妨从以前的监控手段说起。首先来了解一下 Zabbix
,通过 Zabbix
能够监视各种网络参数,保证服务器系统的安全运营;并提供灵活的通知机制以让系统管理员快速定位和解决存在的各种问题。但时代在推进,如今
Zabbix 的功能真的就能满足广大开发者们么?

图片 3

如果你是阿里云的用户,或者使用过
Zabbix,你将明显感受到一个痛点:没有办法对数据做聚合,只能挨个查看主机的性能指标,更不用说有管理的功能了。

如上图,Zabbix 只提供单台 Host 的 Disk 使用量。如果 3
台主机,同属于一个组 Mi-Kafka,就没法知道这个组总体 Disk 使用量了。

因此,就算线上系统发生了故障,要在短期内知道,到底是哪个模块的哪个部分出了什么样的问题,所需要的经验和时长都是巨大的。

而 OpenTSDB 和 StatsD 的出现改变了现状。

OpenTSDB
是什么呢,一个开源监控系统,可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的
Metrics 同时进行存储、索引以及服务,从而使得这些数据更容易让人理解。

移动数据时代真的来了,想想你多久没有在电脑上过QQ了?多久没有在门户网站看过新闻了?网上购物是不是用手机浏览越来越多呢?微信、微博已经是手机必备的应用了吧?智能终端和移动应用的发展已经让手机从以往简单的沟通工具变成了生活娱乐信息交互的平台。移动互联越来越深刻的影响和改变着我们的生活,以往路边苦等的出租车被打车软件找来了;零散时间被各种应用占据了;生活中的所见所得被快速的分享了;朋友间的交流越来越依赖微信、米聊、易信了。

集群监控

如今越来越多的企业开始使用混合云模式,来建设数据中心。私有云和公有云,以及集群系统,让监控工作变得异常复杂。所以,以下几个方面在运维监控中显得尤为重要:

  • 性能指标的采集的轻量化;
  • 性能指标能够集中在一个平台进行管理和可视化;
  • 能够对性能指标进行灵活的组合和计算。

打个简单的比方,一家广告监控平台购买 AWS 的 50 台 EC2
来进行数据的采集,而数据分析则是本地的 10 台服务器来支持。

图片 4

如果还在使用传统运维工具 Zabbix,这时候就会遇到一个问题,AWS
控制台可以看到这 50 台的监控指标。也就意味着,运维工程师需要使用 Zabbix
和 AWS 控制台来同时管理监控数据。

同时关注多集群中多个节点的运行情况,以及需要查看不同中间件的指标来发现问题,或者想要通过
Zabbix 集成短信报警渠道,这些让运维工作变得不堪重负。

而在非常早期的时候,淘宝团队就引入了 OpenTSDB 来辅助他们的运维监控。

随后的几年,云计算和 SaaS 的兴起,国外也出现了多种采用 StatsD 和
OpenTSDB 的开源工具搭建的 SaaS 服务:Boundary、CopperEgg、Datadog 等等。

他们都不约而同地采用了同一种产品逻辑,也是 Cloud
Insight
的产品逻辑————时间序列数据库的逻辑。

  • 任何的性能指标,都作为时间序列数据被采集和处理;
  • 任何的 Host 等归属于性能指标的属性,都作为指标的标签信息。

而在产品逻辑上,则表现为:

图片 5

目前,金山视频云CDN的服务端天级日志量已近千亿条,数据量近百T级别,这些数据是解决运维效率、提升服务质量的关键。近日,在GOPS
2017全球运维大会上海站上,金山云大数据技术总监徐寅斐就如何利用数据进行CDN的智能运维这个话题,分享了金山云的做法和思考。

集群监控

如今越来越多的企业开始使用混合云模式,来建设数据中心。私有云和公有云,以及集群系统,让监控工作变得异常复杂。所以,以下几个方面在运维监控中显得尤为重要:

  • 性能指标的采集的轻量化;
  • 性能指标能够集中在一个平台进行管理和可视化;
  • 能够对性能指标进行灵活的组合和计算。

打个简单的比方,一家广告监控平台购买 AWS 的 50 台 EC2
来进行数据的采集,而数据分析则是本地的 10 台服务器来支持。

图片 6

如果还在使用传统运维工具 Zabbix,这时候就会遇到一个问题,AWS
控制台可以看到这 50 台的监控指标。也就意味着,运维工程师需要使用 Zabbix
和 AWS 控制台来同时管理监控数据。

同时关注多集群中多个节点的运行情况,以及需要查看不同中间件的指标来发现问题,或者想要通过
Zabbix 集成短信报警渠道,这些让运维工作变得不堪重负。

而在非常早期的时候,淘宝团队就引入了 OpenTSDB 来辅助他们的运维监控。

随后的几年,云计算和 SaaS 的兴起,国外也出现了多种采用 StatsD 和
OpenTSDB 的开源工具搭建的 SaaS 服务:Boundary、CopperEgg、Datadog 等等。

他们都不约而同地采用了同一种产品逻辑,也是 Cloud
Insight
的产品逻辑————时间序列数据库的逻辑。

  • 任何的性能指标,都作为时间序列数据被采集和处理;
  • 任何的 Host 等归属于性能指标的属性,都作为指标的标签信息。

而在产品逻辑上,则表现为:

图片 7

alt

移动数据的大发展为终端用户带来巨大便利的同时也给运营商带来了巨大的压力。移动数据业务的爆炸式增长并未带来业务收入的飞速增长,反倒让网络不堪重负,热点区域出现拥塞,用户体验明显下降;大量的信令交互占用了有限的资源,信令风暴为网络带来了巨大的风险;用户的投诉越来越多的与具体业务相关,没有有效的解决办法;OTT的应用对于短信和语音的替代,动摇了运营商收入的基础。

Cloud Insight

运维 2.0 时代有一款有趣的监控产品——Cloud
Insight,它支持多种操作系统、云主机、数据库和中间件的监控,通过标签,对基础设施进行有效地管理,让您轻松应对复杂的基础设施架构。来帮助所有的
IT
公司,减少在系统监控上的人力和时间成本投入,让运维工作变得更加高效、简单。

视角决定高度,在此基础之上,Cloud
Insight
还能够对数据指标进行聚合、分组、过滤、管理、计算;并提供团队协作功能,共同管理数据和报警事件。所以,Cloud
Insight
也是一个数据管理平台,帮助企业内部加强沟通和协作,填补部门间、人员间、技能间的沟通鸿沟。

Cloud Insight 通过 3
个步骤深入操作系统、数据库、中间件,以及未来通过 Developer API
对接进来的所有 Metric 进行处理:

  • Cloud Insight Agent
    采集并处理 Metric;
  • 在平台服务仪表盘和自定义仪表盘中,提供 Metric
    聚合、分组、统计运算、基本数学运算等操作;
  • 针对操作的结果,提供曲线图、柱状图等多样化的展现形式。

图片 8

Cloud Insight

运维 2.0 时代有一款有趣的监控产品——Cloud
Insight,它支持多种操作系统、云主机、数据库和中间件的监控,通过标签,对基础设施进行有效地管理,让您轻松应对复杂的基础设施架构。来帮助所有的
IT
公司,减少在系统监控上的人力和时间成本投入,让运维工作变得更加高效、简单。

视角决定高度,在此基础之上,Cloud
Insight
还能够对数据指标进行聚合、分组、过滤、管理、计算;并提供团队协作功能,共同管理数据和报警事件。所以,Cloud
Insight
也是一个数据管理平台,帮助企业内部加强沟通和协作,填补部门间、人员间、技能间的沟通鸿沟。

Cloud
Insight
通过 3 个步骤深入操作系统、数据库、中间件,以及未来通过 Developer API
对接进来的所有 Metric 进行处理:

  • Cloud
    Insight
    Agent 采集并处理 Metric;
  • 在平台服务仪表盘和自定义仪表盘中,提供 Metric
    聚合、分组、统计运算、基本数学运算等操作;
  • 针对操作的结果,提供曲线图、柱状图等多样化的展现形式。

面临巨大的网络压力,运营商该如何有效的保证用户使用感受的同时又能为自己带来丰厚的收入呢?应从基础网络、用户感知和数据挖掘三个方面来入手。

Cloud Insight 的神奇功能

  • 自定义仪表盘
  • 数据聚合

遥想 2015 年 8 月 17 日,Cloud
Insight 还在梳理功能原型,畅想
Cloud Insight
存在的意义,而一转眼,我们已经实现了很有意思的功能:

  1. 自定义仪表盘

图片 9

Cloud Insight
已经可以自定义仪表盘了,除了在数据展现上清晰直观,它还拥有一个炫酷的本事:随意拖拽。

图片 10

  1. 使用标签来实现数据聚合&分组

在 Beta v 0.2.1 中,我们实现了数据的聚合和分组。沿袭了 OpenTSDB
的查询方式:用一种类 SQL 的方式来查询指标。

具体操作可以访问 Cloud Insight
文档中心 • Metric 查询。

Cloud Insight 还支持类似 SQL 的
group_by 查询语法。这个在查看多个磁盘分区的容量Docker 中不同
Container 的性能消耗
时都是非常有用的。

例子举例,如果我们想要看每个 host 的 CPU 空闲率:

avg: system.cpu.idle {} by {host}  

此时,第一个 {FromTag} 缺省代表从所有 Metrics
中查询数据。如图所示,得到以下图表:

图片 11

在实际的测试环境中,由于我们有 6
台测试主机,所以会得到如下的曲线。并且,当鼠标悬停至曲线时,下方的悬停窗口会分别显示
6 台主机的 system.cpu.idle。

图片 12

金山云大数据技术总监徐寅斐发表演讲

Cloud Insight 的神奇功能

  • 自定义仪表盘
  • 数据聚合

遥想 2015 年 8 月 17 日,Cloud
Insight
还在梳理功能原型,畅想 Cloud
Insight
存在的意义,而一转眼,我们已经实现了很有意思的功能:

  1. 自定义仪表盘

图片 13

ALT 信息

Cloud
Insight
已经可以自定义仪表盘了,除了在数据展现上清晰直观,它还拥有一个炫酷的本事:随意拖拽。

图片 14

  1. 使用标签来实现数据聚合&分组

在 Beta v 0.2.1 中,我们实现了数据的聚合和分组。沿袭了 OpenTSDB
的查询方式:用一种类 SQL 的方式来查询指标。

具体操作可以访问 Cloud
Insight
文档中心 • Metric 查询。

Cloud
Insight
还支持类似 SQL 的 group_by
查询语法。这个在查看多个磁盘分区的容量Docker 中不同 Container
的性能消耗
时都是非常有用的。

例子举例,如果我们想要看每个 host 的 CPU 空闲率:

avg: system.cpu.idle {} by {host}  

此时,第一个 {FromTag} 缺省代表从所有 Metrics
中查询数据。如图所示,得到以下图表:

图片 15

在实际的测试环境中,由于我们有 6
台测试主机,所以会得到如下的曲线。并且,当鼠标悬停至曲线时,下方的悬停窗口会分别显示
6 台主机的 system.cpu.idle。

图片 16

基础——网络性能的优化

灵活查询,聚合&分组并存

除开单纯的聚合和分组,Cloud
Insight
还支持聚合和分组的复合查询。如:

avg: system.cpu.idle {} by {owner}  

图片 17

此时,虽然有 3 个 host,但是分组是以 owner 来进行的。所以,A 与 B
会聚合为一条曲线,而 C 和 A&B 的关系则是分组的关系。

图片 18

当然,Cloud Insight
的功能在未来,还远远不止这些,高效运维的时代才刚刚开启。

利用数据构建运维和服务质量支撑体系

灵活查询,聚合&分组并存

除开单纯的聚合和分组,Cloud
Insight
还支持聚合和分组的复合查询。如:

avg: system.cpu.idle {} by {owner}  

图片 19

此时,虽然有 3 个 host,但是分组是以 owner 来进行的。所以,A 与 B
会聚合为一条曲线,而 C 和 A&B 的关系则是分组的关系。

图片 20

当然,Cloud
Insight
的功能在未来,还远远不止这些,高效运维的时代才刚刚开启。

运营商最核心的资产就是手中的移动网络,如何充分利用手中的移动网络为用户提供随时随地的服务是运营商收入的重要保障,是运营商的信心之所在。

工欲善其事,必先利其器。数据是解决运维效率、运维自动化甚至智能化的核心,而要想充分利用已有的数据资产,数据平台的支撑就显得至关重要。为了满足目前和未来的需求,首先需要对现有的数据和使用方式进行分类:

针对现有的网络需要进行不断的优化和调整,以保证业务的有效进行。例如业务的变化和用户分布的变化进行网络资源的调整,对因为环境的变化造成的覆盖问题进行网络的优化。

现有数据可以分为四类。包括基础监控数据、探测数据、服务端日志、客户端日志,这四类数据在接入难度、数据量级上各不相同,数据平台需要统筹考虑所有数据的接入、传输、计算和存储。

现有网络在爆炸式的数据面前已经不堪重负,因此LTE的建设正在加速,以保证用户的使用需要。对于LTE网络首先需要做好LTE的规划优化以及维护工作,打好网络基础。在LTE新建阶段应该以基础性的优化为主,同时基于对2G/3G业务流量的分析做好LTE容量增长的预测,为网络滚动发展提供依据;终端用户对于数据业务的需求是随时随地的,针对如地铁、商业区、校园、高铁以及航班等特殊场景还需要有针对性的特殊解决方案来满足。

图片 21

在做好LTE网络优化工作的同时,需要考虑到2G/3G/4G长期共存的状况,依据不同业务不同终端对网络的需求,在不同的网络中,合理分配用户和资源达到2G/3G/4G网络的协同发展。

CDN数据分类及特点

进阶——用户感知的管理

运维对数据的使用,可以分为四个阶段:数据支撑、分析支撑、决策支撑和预测支撑,每个阶段对数据平台有着不同的需求:数据支撑要求平台能够满足对上述四类数据的计算和存储需求,确保运维人员能够及时获取准确的数据指标。分析支撑要求平台能够及时响应各类即席查询的需求,包括对原始日志的全链路分析,对于业务指标的多维分析等。决策支撑和预测支撑则要求平台具备数据的强大后处理能力,包括对已存储数据的建模、挖掘能力。

数据业务时代,用户体验是服务的核心,稳定优异的网络配合良好的用户体验能为运营商带来业务的大发展,如何评价和监控用户体验确实是一道难题。移动互联网的用户体验是端到端的一个过程,涉及到终端、网络和应用的方方面面,是用户在使用各种业务时的一种综合的感受。针对用户感知的评价和监控,首先需要建立用户感知的评价体系,将用户感知转化为应用层、业务层和网络层中各项可量化、可测量的指标。

图片 22

在评价体系建立后,可以通过对VIP用户的监控及时发现用户使用中遇到的问题并进行解决,保障VIP用户的使用体验。同时定期的对所有用户进行评价,找出网络中感知差的VAP(Very
Annoying/Angry
Person)用户,针对这些用户所遇到的问题通过话单回溯及海量数据关联分析快速而准确定位用户体验降低的真正原因,主动解决网络业务问题,从而缩短解决问题的时间、提升VAP用户满意度、降低投诉量,实现最小化用户流失。

数据运维四个阶段

建立了针对用户感知评价监控体系,同样也需要针对具体应用业务做质量评估和监控。通过对主流OTT应用业务的质量评估和监控,定期输出监控报表并对业务质量问题进行根因分析定位并提出解决办法,为网络优化提供支撑,从而保障全网用户的业务体验,预防发生大面积用户投诉。

金山视频云大数据平台架构建设实践

未来——大数据的挖掘

先说大数据平台。基于以上数据需求,金山视频云大数据平台在实践中,通过不断演进,最终形成了目前以Hadoop和Spark生态产品为基础的架构。平台的数据传输采用的是Kafka,作为现今最主流的传输中间件,它出色的吞吐能力为第一层数据缓冲提供了保障。数据计算全部采用Spark,技术栈的精简能够保证开发效率和平台稳定性,而且Spark可提供足够丰富的数据挖掘和机器学习库保证数据的后处理。

针对数据业务的大发展,从网络、用户以及业务层面都进行了具体的工作,运营商就做好了大数据的准备了吗?

在数据的前处理上,金山云采用的是实时流+离线流修补的经典架构,实时流在一定精度的前提下,保证了数据的及时性,离线流保证了数据的最终完整性。此外,平台还引入了边缘计算,作用是在充分利用CDN节点分布式天然优势的同时,可大大降低中心数据平台的压力,提升了平台的整体稳定性。

好像是,可是收入却没有随着业务量的增加而增加,一些业务还因为OTT的应用而出现了收入的减少,这该怎么办呢?让我们先看看终端安装APP时的提示,“手机号码注册、位置信息上报、通信录共享、统一账号接入……”,这些背后隐藏着什么呢?

图片 23

对,数据就是财富。一个个带着关键信息的bit,在运营商管道中流窜,稍纵即逝。运营商不能再视而不见管道中蕴藏着大量的宝藏。这些宝藏等待去挖掘,等待去探视那巨大商业秘密,等待着迅速改变电信运营商“只做数据的搬运工”的尴尬局面。

金山视频云大数据平台架构

运营商可以通过经由自己网络的基础信息、位置信息、行为信息和社交信息等方方面面,从单个用户的行为习惯到群体用户的使用习惯等方面深入的挖掘和分析,为自己的网络建设、扩容规划、套餐的制定、市场投入、终端引入等多方面提供参考,同时也可以为城市的规划,商家的精确营销提供参考和依据。通过对这些数据的深入挖掘和整理,既增加了收入,又能降低网络建设和市场拓展的投入,整体提升运营商的盈利能力。现在是运营商下定决心进行相关数据挖掘工作的时候了。

对于一个数据平台来说,最复杂的是数据存储,不同的数据查询和获取需求决定了最终的存储选型:对于查询灵活性要求极大,数据量适中的数据,金山云使用ElasticSearch
+
Kibana提供灵活的数据存储与查询服务。对于查询模式相对固定、数据写入量巨大的数据,Druid是一个不错的选择。

目前各大公司已经启动数据价值挖掘的研究。其中,在通信行业,数据相关关系分析只是数据价值激活的冰山一角,更多的数据整合和混合动态相关关系建模才是运营商现在的工作重点,将现在运营商分散分布在BOSS系统、CRM(Customer
Ralationship
Management)系统、终端信息库、信令监测系统、OSS系统中的信息进行有效的整合和挖掘将是近一阶段最重要的方向。

CDN的全量原始日志,则会经过ETL后以列存储的方式存储在HDFS上,可以通过SQL、代码片段等多种方式对数据进行查询分析。此外,整个数据平台使用金山云自研的大数据产品KMR,它对金山云其他IaaS服务的天然支持提供了很多便利,如分布式对象存储KS3,可以作为平台存储空间的扩充,重要的数据以及长期不用的冷数据,都会定期自动备份到KS3中持久存储。

图片 24

金山视频云大数据平台采用多种技术

大数据平台的运维实践

基于这个大数据平台,金山云开发了多套系统提升运维效率。第一个是报警系统,大数据平台承载了CDN所有业务报警数据的清洗、计算和决策生成,Spark对流式计算的支持保证了数据产生到报警整个过程能够在1分钟内完成,保证及时发现问题,系统本身良好的水平扩展能力,也能够满足视频云运维不断变化的业务需求。

CDN业务报警的特点是种类多、维度多、报警阈值因地区运营商而异。报警规则和报警阈值的管理工作很复杂,为此,金山云的报警平台中有一套专门用于阈值评估的离线分析系统,针对所有指标的历史数据、人为配置以及运维对报警的反馈信息,综合评估出不同区域运营商的合理阈值,极大地降低了报警管理的难度。

第二个系统是CDN服务质量的“观象台”——鹰眼平台,它提供了50+业务指标、5+维度的服务质量数据的查询能力,可满足日常运维和调优工作中80%以上的数据获取需求,并可场景化呈现故障处理、网络链路质量、大客户服务质量维护等多种常见运维工作。

鹰眼的数据需求繁杂,既提供全局服务质量信息,也需要满足不同域名、区域运营商、链路以及缓存状态的细粒度查询,甚至需要对这些维度进行任意组合。为了满足这样的查询需求,鹰眼的服务质量数据使用ElasticSearch作为底层存储,在中等规模数据的写入和聚合查询方面的速度都很理想,文档化的存储方式也能满足数据快速迭代更新的需求。同时,鹰眼数据的部分聚合被下放到节点上进行,这样可以降低平台的计算负载。

基于大数据平台和产生的数据,金山云CDN已能在包括调度、故障处理、质量调优在内的很多场景中实现自动化。除了大数据,接下来金山云还会在机器学习和人工智能领域进行运维智能化的探索。

相关文章