性能分析体系建设之路,如何从零搭建一个自动

2020-01-15 作者:亚洲城动态   |   浏览(146)

对自动化运维体系的需求,是随着业务的增长、对运维效率和质量的要求不断提高而产生的。

10月22日,运维帮与国内首家云链服务提供商白山云科技有限公司(以下简称“白山”)联合举办“性能为王”主题沙龙,白山联合创始人兼CTO童剑与五八框架组件部负责人郝新斌、京东MySQL运维自动化平台负责人王伟、《大型网站性能监测、分析与优化》作者唐文一同探讨如何建立全面、及时的性能监控与分析体系,持续对应用与网站进行性能优化。

前言: 在很多初创公司和中小型企业里,运维还停留在“刀耕火种”的原始状态,这里所说的“刀”和“火”就是运维人员的远程客户端,例如 SecureCRT 和Windows 远程桌面。

图片 1

在这种工作方式下,服务器的安装、初始化,软件部署、服务发布和监控都是通过手动方式来完成的,需要运维人员登录到服务器上,一台一台去管理和维护。这种非并发的线性工作方式是制约效率的最大障碍。

童剑在加盟白山前曾在新浪工作16年,负责研发的动态应用平台和数据库平台,使新浪率先实现技术平台统一,支撑了微博的爆发式发展;并领导推出国内最早一批公有云——SAE。凭借多年的研发与管理经验,童剑对性能优化分析形成了一套独到见解,在现场他与研发同学分享了如何站在更高的视角去了解性能。

同时,因为手动的操作方式过于依赖运维人员的执行顺序和操作步骤,稍有不慎即可能导致服务器配置不一致,也就是同一组服务器的配置上出现差异。

一、在更高视角建立性能管理运维体系

有时候,这种差异是很难直接检查出来的,例如在一个负载均衡组里面个别服务器的异常就很难发现。

(一)性能管理现状

随着业务的发展,服务器数量越来越多,运维人员开始转向使用脚本和批量管理工具。

目前的性能管理主要存在以下问题:

脚本和批量管理工具与“刀耕火种”的工作方式相比,确实提升了效率和工程质量。

  1. 技术人员关注系统层面的各种性能指标和监控,对客户端性能重视不够;

  2. 业务方与技术方性能标准存在差异,系统做得好不代表用户体验好;

  3. 优先支持产品功能与运营活动,性能问题解决排期靠后;

但这个方式仍然有很多问题。

4. 没有性能指标变化与问题定位的对应关系,指标数据异常,却难以定位具体问题;

第一是脚本的非标准化的问题。

5. 缺乏体系化管理,没有统一的性能指标和运营管理,以及自上而下的协调配合,无法持续进行性能质量改进。

不同运维人员写的脚本在所用的编程语言、编码风格和健壮性方面存在巨大差异,同时这些脚本的版本管理也是一个挑战。

(二)相关的内部角色

第二是脚本的传承问题,人员的离职和工作交接,都会导致脚本无法很好地在运维人员之间传承和再利用,因为下一个运维人员可能无法理解和修改前一个运维人员编写的脚本功能。第三是批量管理工具的选择。

性能问题不仅与技术人员相关,公司内部的其它人员也会对应用性能产生直接或间接的影响。

不同的管理人员选择不同的批量管理工具必然会带来管理混乱的问题,也无法很好地实现在运维人员之间互相备份工作的需求。

  1. 业务总负责人:性能质量目标主要影响者;

  2. 性能质量经理:负责日常的性能质量问题发现和反馈、推进解决;

  3. 运维与客服人员:收集和反馈用户的性能质量问题,性能问题的推动方之一;

因此,对构建自动化运维体系的要求变得越来越迫切。通过自动化运维体系来实现标准化和提高工程效率,是唯一正确的选择。那么如何建设自动化运维体系呢?

4. 产品人员:负责产品的交互功能设计和任务排期,对性能问题的优先级判断将对问题的解决产生直接影响;

本案例研究分为三个大的方面:

5. 技术人员:客户端、后端及其他技术体系的开发实现者,性能质量最重要、直接的影响因素。

第一个是为什么要建设自动化运维体系,就是解决“3W”中的Why和What的问题,即为什么和是什么。第二个是介绍我司各个运维子系统是怎样设计、运行和处理问题的,解决“3W”中的How的问题,也就是怎样去做的。第三个是对我司在自动化运维过程中遇到的一些问题的思考,做一个总结。一、建设自动化运维体系的原因

(三)性能质量运营管理

先来看一下我们为什么要建设一个自动化运维体系。首先来看运维遇到的一些挑战,如下图所示。

1. 性能分析工具建设:完善性能指标体系、完善数据采集、持续提升分析准确度;

运维面对的挑战

2. 问题收集反馈机制:通过员工、客服、社会化媒体收集用户反馈问题,统一跟踪处理;

第一个是游戏的需求。它表现为三个方面:

3. 性能管理运营机制:由专职的质量经理负责整体运营,持续发现问题并推动解决,关键的性能指标分解到各业务责任人;

一是游戏数量多,我司现在运营的游戏多达近百款。二是游戏架构复杂。游戏公司和一般的互联网公司有一个很大的区别,就是游戏的来源可能有很多,比如有国外的、国内的,有大厂商的、小厂商的;每个游戏的架构可能不一样,有的是分区制的,有的是集中制的,各种各样的需求。三是操作系统种类多,这与刚才的情况类似,游戏开发者的背景与编程喜好不一样,会有Windows、Linux等。

4. 制定目标、分工合作:性能需要持续追踪,制定每个阶段的性能提升目标和需要解决的性能问题,分解到相关责任人和团队,大领导推动跟进结果。

第二个是在硬件环境方面,主要表现为服务器数量多、服务器型号多。

(四)关键指标定义

因为公司从建立到现在有十几年的时间了,在这个过程中分批、分期采购的服务器几乎横跨各大OEM厂商的各大产品线,型号多而杂。

建立应用性能管理机制,首先需要根据应用中最重要的用户操作体验定义可量化的性能关键指标及计算方法,关键指标主要可以分为以下几类:

最后是人的因素。我们在建设自动化运维体系过程中,有一个比较重要的考虑点是人的因素。

1. 速度类:衡量应用的请求响应时延、文件下载上传速度、图片和视频加载速度;

如果大家的技术能力都很强,很多时候一个人可以完成所有工作,可能也就不需要自动化运维体系了。

2. 比率类:衡量应用的成功率、错误率、性能在某个档位的百分比;

正是因为每个运维人员的能力不一样,技术水平参差不齐,甚至是运维习惯和工具也不一样,导致我们必须要创建一套规范的自动化运维体系,来提升工作效率。

3. 容量类:衡量资源利用率和服务请求量,比如每秒请求数、带宽、CPU利用率。

二、建设自动化运维体系的目标

以上关键指标均有预警值,当性能低于该预警值时,就需要我们行动起来。同时我们还需要知道不同的产品或者业务类型,其衡量性能和质量的关键指标可能差异很大,例如:视频是首帧加载时长、不卡比、错误率;电商类是列表页加载时长、商品页加载时长、支付响应速度、错误率等。

再看一下建设这套自动化运维体系的目标,也就是说我们的原则是什么?

(五)拓扑关系梳理

笔者将自动化运维体系的建设目标总结为四个词。

分析性能时需要梳理应用与网络的技术架构,其中拓扑关系是最重要的。

第一个是“完备”,这个系统要能涵盖所有的运维需求。第二个是“简洁”,简单好用。如果系统的操作流程、操作界面、设计思想都比较复杂,运维人员的学习成本就会很高,使用的效果是会打折扣的,系统的能力、发挥的效率也会因此打折扣。第三个是“高效”,特别是在批量处理或者执行特定任务时,我们希望系统能够及时给用户反馈。第四个是“安全”,如果一个系统不安全,可能导致很快就被黑客接管了。所以安全也是重要的因素。三、自动化运维体系的结构和运作方式

图片 2

下图所示是我司当前自动化运维体系的几个子系统,我们来看一看它们是怎样联合起来工作的。

(应用拓扑关系)

首先服务器会经由自动化安装系统完成安装,然后会被自动化运维平台接管。自动化运维平台会对自动化安检系统、自动化客户端更新系统和服务器端更新系统提供底层支撑。

以应用普遍的技术体系为例,由于依赖大量的服务单元,底层服务众多,同时API相互调用,所以应用的拓扑关系较为复杂,可以分为以下几部分进行梳理:

自动化数据分析系统和自动化客户端更新系统会有关联关系。自动化数据分析系统会对自动化客户端更新系统的结果给予反馈。

1. 网络物理连接关系,例如网络中3层的路由信息、交换机间的连接信息、服务器的上联信息,两个服务器之间通讯分别经过了哪些网络节点,这些信息都要清楚;

自动化运维体系结构图

  1. 应用依赖的底层服务,例如:数据库、CACHE、存储等;

下面我们来看一下每个子系统是如何设计和工作的。

3. 应用API间的调用关系,业务的不同功能模块之间还需要彼此调用,所以API之间的调用关系也很重要。

3.1、自动化安装系统

这些拓扑信息和调用关系的记录,如果主要依靠人工更新很容易导致错误,或者更新不够及时。现在新的的趋势是自动化采集和更新,自动采集交换机中的信息和应用调用各种服务的日志,通过大数据分析、机器学习的技术,动态更新所有拓扑关系,白山已经在这些方面进行了尝试,并取得了不错成果。

说到自动化安装,大家可能并不陌生,我们刚才说到挑战是“两多两少”,型号多、操作系统多,但是人少,可用时间也比较少。

(六)五个维度全覆盖

如下图所示,整个流程采用通用的框架,首先由PXE启动,选择需要安装的操作系统类型(安装Windows或者Linux),然后根据Windows系统自动识别出需要安装的驱动。服务器交付用户之前,会进行基本的安全设置,例如防火墙设置以及关闭Windows共享,这在一定程度上提高了安全性,也减少了需要人工做的一些操作。

从数据采集到监测角度多纬度覆盖,利于更加快速精准的定位性能问题,主要采集以下五个维度的数据:

自动化安装流程图

1. 网络层:主要采集丢包率、出口带宽、上联端口带宽、负载均衡等数据,通常的采集力度是3-5min,我们建议做到30s以内,这样才能捕获到瞬时的网络异常抖动;

3.2、自动化运维平台

  1. 系统层,包括:负载、磁盘IO、内存、CPU、网卡PPS、带宽;

  2. 服务软件层,包括:Apache、Nginx、MySQL、Redis、Kafka等;

当服务器由自动化安装系统安装完成以后,就会被自动化运维平台接管。自动化运维平台是运维人员的作业平台,它主要解决的问题就是因服务器、操作系统异构而且数量特别多而带来的管理问题。操作系统是五花八门的,我们在设计系统过程中考虑了以下几个因素:

4. 应用与API层,包括:请求数、错误率、平均时延,以及日同比、周月环比的数据;

把整个系统的用户界面设计成基于浏览器的架构。运维工程师无论何时何地都可以登录管理系统进行运维操作,这样的话就比较方便。由Octopod服务器对被操作的机器发布指令。

  1. 客户端,包括:响应时长、下载性能、错误率、上网信息。

统一管理异构服务器。大家以前可能对Windows深恶痛绝,其实Windows也可以管得很好。我们使用开源的SSH方式管理Windows,这样就可以对系统进行批量的补丁更新,还可以做批量的密码管理和操作。

(七)客户端数据采集

充分利用现有协议和工具。这个平台的特点是所有的系统使用SSH管理,而不是自己开发一些Agent,这也体现了自动化运维的观点。

客户端的数据采集十分重要,客户端的性能表现,除受端上自身因素影响外,还与服务器端API性能直接相关。这就要求我们精细规划客户端数据采集体系,一方面用来区分客户端的实现逻辑造成的性能问题,另一方面能更好地评估服务器端的性能,为整体性能优化提供精准信息。

很多时候我们没必要重新造轮子,即使自己造出一套客户端的方法,大部分时候也并没有在生产环境里得到严格的验证。

1. 资源请求:客户端数据采集中的重要部分,需全量或者抽样记录客户端向服务器端发起的各种请求信息和返回状态,包括API请求、图片请求、视频请求等;

而SSH协议本身已经存在很多年了,而且已经在我司使用了很多年,该出的问题已经出了,相对于造轮子,使用SSH更加稳定,更经得起考验,使用起来更方便。

2. 异常错误:采集客户端运行产生的异常错误信息,以及服务器端返回的各种错误信息;

3.3、自动化安检系统

3. 联网信息:采集客户端的上网连接信息,比如WIFI/4G/3G/2G等,以及用户的基本信息。

下一个系统是自动化安检系统。由于我们的子系统比较多,业务也比较多,怎样设计一套系统去保障它们的安全呢?这里主要是两个系统:自动化安检平台和服务器端。

采集以上信息时要求各端规定统一的状态返回码,以免造成重叠,导致统一日志分析时复杂度增加。

先来看自动化安检平台。游戏公司和一般的互联网公司有一个区别,就是前者需要给玩家发送很多的客户端(特别是有的客户端比较大),或者补丁文件,去更新、下载和安装。

(八)服务端数据采集

如果这些文件里面出现病毒和木马,将是一件很糟糕的事情,甚至会对业务和公司的声誉造成恶劣影响。当这些文件被发到玩家电脑上之前,必须经过病毒检测系统检测,确保它没有被注入相应的病毒代码。

1. WWW日志:标准化日志,内部尽量能统一日志格式规范,也预留出扩展字段位供不同业务自定义使用;

再来看服务器端,主要是通过安全扫描架构来保障安全。

2. 应用日志:应用处理请求过程中重要的外部服务调用记录,性能相关的环节处理时间记录等;

安全并不是一蹴而就,一劳永逸的。如果不对系统持续地检查、检测、探测,那么你的一些误操作会导致系统暴露在互联网上,或者是暴露在恶意攻击者的眼皮之下。

3. 基础服务日志:如消息服务处理日志,数据库查询日志、慢日志,缓存的异常请求日志等;

通过一种主动、自发的安全扫描架构对所有服务器进行安全扫描,就能在很大程度上规避这样的问题。

  1. 错误日志:全部服务的错误日志、应用程序的错误日志。

举一个例子,去年我们遇到过一个情况,某款交换机ACL达到一定的数量的时候,就完全失效了。

采集日志时,需要注意:

如果没有相关的配套机制去检查和检测,那么你的服务器、你认为保护得很好的端口或者是敏感的IP可能已经暴露。所以,通过这种主动的探测可以减少很多系统的或者是人为的安全问题。

(1)格式统一标准化;

3.4、自动化客户端更新系统

(2)记录用户ID和请求ID;

游戏是有周期性的,特别是在游戏发布当天或者有版本更新的时候,这时候玩家活跃度很高,下载行为也是比较多的,但是平时的更新和下载带宽可能并不大,这也是游戏很显著的特点。

(3)记录IP地址(客户端、服务端)。

这个特点对于我们构建这样一个分发系统提出了很大的挑战。

(九)分析计算平台

第一个挑战就是在高峰时游戏产生的带宽可能达到数百GB。

图片 3

第二是很多小运营商或者中小规模的运营商会有一些缓存机制,这个缓存机制如果处理得不好,会对业务造成影响,也就是非法缓存的问题。

(分析计算平台)

第三是关于DNS调度的问题。

如上图,最底下一层是数据采集部分,数据采集相对麻烦,上报体系包括主动抓取、服务器上报等方式;当服务器和数据规模较大时,一个中心的存储节点压力将逐渐加大,此时我们建议采用分层级的数据收集体系。从下往上数的第二层是数据聚合与数据清洗;存储层常规的技术有:时序数据库、ES数据库、HBase、HDFS;计算层也都是比较常规的技术;最上面一层是和性能分析有关的功能,如实时监控预警的系统、自助搜索查询、可视化报表、运营管理工具(作为事件追踪平台)、数据API平台(将产生的数据供其它运维工具调用,用以查询问题、分析状态)。

DNS调度本身是基于玩家本身的Local DNS的机制解析的,会有调度不准确的问题。

二、实战案例参考

第四是DNS污染,或者是DNS TTL的机制导致调度不那么灵敏和准确。针对这些问题,我们有下面两套系统来解决。

(一)图片性能体系

第一套是Autopatch系统,它解决的是大文件更新的下载问题,再就是多家CDN厂商流量调度。其操作流程也比较简单,由运维人员上传文件、安检,然后同步到CDN,由CDN分发到相关边缘节点,最后解压文件。

图片 4

刚才说到游戏的周期性特点,就是平时带宽不是很大,但是在某个节点的时候,或者是重大活动的时候,带宽比较大。

(移动端图片性能体系数据采集指标)

如果自己构建一套CDN系统,可能不是很划算,所以我们引入国内多家比较大型的CDN厂商调度资源。我们通过302的方法调度,而不是把域名给其中一家或几家。

很多应用都有图片下载与显示功能,这对于用户体验影响十分重要,图片加载缓慢主要影响因素包括:源站存储、CDN、客户端加载渲染机制,因此图片的性能监控也主要包括这3方面。

因为直接使用CNAME的话很难按比例调度,特别是带宽大的时候,一家CDN厂商解决不了,或者是一家发生局部故障,需要快速切除。

图片 5

而通过集中的调度系统就可以实现按比例调度的功能。用户发过来的所有请求,首先要在我们这边进行调度,但是本身并不产生直接下载带宽,而是通过相关算法,按比例和区域调度给第三方的CDN厂商,然后玩家实际是由第三方CDN厂商节点去下载客户端的。

(基于采集数据生成的分析报表)

第二套是Dorado系统。刚刚讲到小运营商或者某些运营商的非法缓存机制会对业务造成影响,那么对于某些关键的文件,如果缓存的是一个旧版本,可能会造成很大的问题。比如我们的区服列表,如果我们服务器端增加了新的区服,在客户端没有显现出来,就导致玩家没有办法进入到新的区服去玩。

上图上半部分是错误率指标,我们可以分别找到移动客户端、CDN、源站的错误率,通过这三个部分我们可以清晰地看到具体是哪个因素导致的性能波动,据此进行问题定位。

针对这些问题,我们设计了内部代号为Dorado的系统,因为这些文件本身是比较小的,而且数量也不是特别多,但是需要用HTTPS加密,通过加密规避小运营商的缓存问题。

下半部分是平均下载时间,与错误率类似,我们可以看到三个部分中各自的平均下载时间,该报表目前只展示了部分内容,我们同时还监控了各个CDN在不同运营商、不同地区的数据,可以每天把性能较差的地区调度给其它CDN观察性能变化,将性能的运营管理变成持续迭代的提升过程。

所以我们对于这些关键文件,全部有自有节点,在节点上支持HTTPS加密方法,规避小运营商缓存带来的一些问题。

图片 6

3.5、自动化服务器端更新系统

(客户端分类错误统计)

我们采用的服务器端更新模式也是一种比较传统的类似于CDN的方式,是由目标服务器通过缓存节点到中央节点下载,由缓存节点缓存控制,这样可以减少网间传输的数据量以及提高效率。

分析错误的主要目的是为了更好的发现产品和技术上的问题,为此我们进行了更加细致的分析。如上文所提到的,我们对标准错误码进行约定,并按照错误码进行细分,同样,错误码也按照源站和CDN进一步区分出来。

我们在设计这套系统的时候,也想过用P2P去做。大家想P2P是很炫,又节省带宽,但是用于生产环境中大文件分发的时候会有几个问题。

(二)视频性能体系

一是安全控制的问题,很难让这些服务器之间又能传数据又能进行安全端口的保护。

视频与图片类似,主要分析源站存储、CDN、客户端三方因素,CDN与源站性能主要指标是下载性能与错误率,客户端还需要分析首帧加载时长、卡播比、播放成功率等因素。很多视频需要通过API获取视频文件,所以API的性能、响应速度、失败率、成功率也要进行采集与监测;除此之外还需第三方监测工具,从多个维度进行采集与分析。

二是在P2P里做流量控制或者流量限定也是一个挑战。所以最终我们采用了一个看起来比较简单的架构。

图片 7

3.6、自动化数据分析系统

(首播加载与播放成功率)

说到客户端更新,其实更新的效果如何,玩家到底有没有安装成功或者进入游戏,很多时候我们也很茫然,只能看日志。

除播放与下载外,视频的上传情况也关乎用户体验。

但是日志里面的很多信息是不完善和不完整的。下载客户端的时候,如果看HTTP的日志的话,里面是206的代码,很难计算出玩家到底完整下载了多少客户端,甚至他有没有下载下来,校验结果是否正确,也很难知道。所以我们最终设计了一个自动化数据分析系统,目标就是分析从用户开始下载到他登录游戏,数据到底是怎样转化的。

图片 8

最理想的一种情况是用户下载客户端以后,就进入了游戏,但这是一个理想情况。

(视频小文件上传)

很多时候,比如因为网络不好,导致用户最终没有下载成功,或者是因为账号的一些问题,用户最终没有登录到游戏里面去。

对于视频小文件的上传,我们主要监测上传的速度和上传的完成率两个指标。

所以,展现出来的数据就是一个漏斗状。我们的目标就是让最终登录的用户数接近于起初下载客户端的用户数。

图片 9

我们来看一下系统的架构。首先由玩家这边的下载器或者是安装客户端,游戏客户端里面集成一些SDK,对于任何一个关键点,比如“下载”按钮或者“终止”按钮的数据都上报,当然这里面不会涉及敏感信息。上报以后会有Tomcat集群,集群处理以后会将数据写入MongoDB。

(视频大文件分片上传)

看一下这个游戏在引导过程中有什么问题,左边的这一列它分为三个文件,有一个是3MB,有两个是2G多的文件,其实大家可以想像一下。很多时候玩家看到小的文件就把小的文件直接下载安装了,但是实际上并不完整。这一点也告诉我们,其实很多时候在运营或者是业务方面,在引导方面也是要比较合理才能去规避掉一些问题。

对于视频大文件我们采用分片上传机制,分片合并后计算总体速度与完成率;视频上传后进行转码,对于转码监测比较重要的指标是每秒转码的SIZE、队列数、平均排队时间、排队时间超过1h的任务数,当队列等待时间过长时则需要我们进行扩容。

3.7、自动化数据备份系统

(三)API性能监测

我们第一个版本的备份系统,它的设计和实现是比较简单的:不同的机房会有一台FTP服务器,本机房的数据写入FTP服务器,然后写入磁带,但是这样就导致磁带是分散的,没有集中存放的地方;另外,基于FTP的上传会有带宽甚至有延迟的要求。

目前的互联网应用,多数拥有2个或以上平台的客户端,包括:IOS、Android、PC Web版本,这些客户端通常使用同一组API服务,因此API服务性能管理十分重要。

后来我们设计了一个集中的备份系统。它主要解决了以下两个问题。第一是简化配置。我们所有机房的全部配置,用一个负载均衡器的IP就可以了,当客户端需要上传文件时,通过负载均衡器获取实际上传的地址,然后上传文件,由左边第二个框里面的服务器进行接收,并且根据MD5值进行校验,如果校验没有问题,就转到Hadoop的HDFS集群里面去。目前这个集群有数十PB的规模,每天上传量有几个TB。

1. 核心功能API界定:从业务角度出发,根据核心功能或主要交互体验找出相应API,并重点监测;

第二是提高传输效率和成功率。大家会想一个问题,在中国,网络环境十分复杂,运营商之间存在隔阂甚至是壁垒,导致网络不稳定,丢包和延迟的问题是怎样解决的呢?如果基于TCP传输大文件,理论上存在单个连接上带宽延时积的限制。

  1. 重要API QPS和时延:实时统计和监控重要API每秒请求数和时延分布,并将其区分成不同时间区间,例如500ms以内、500ms-1s,1s-2s;

  2. 重要API 错误数:实时统计和监控重要API的错误数;

这里我们创新的是,客户端的上传采用UDP协议,UDP本身没有任何控制,说白了就是客户端可以任意、使劲地发文件。最终会由服务器端检查你收到了哪些文件片段,然后通知客户端补传一些没上传的片段就可以了。基于这种方式能规避很多因为网络抖动或网络延迟比较大而导致的问题。当然,在客户端做流量控制也是可以的。在遇到问题的时候多想想,或许能找到不走寻常路的解决方案。

4. 底层服务的监控:API依赖的数据库、缓存、消息服务也要进行上述的指标监测。

3.8、自动化监控报警系统

图片 10

再看一下游戏的自动化监控报警系统(如下图所示)。游戏的架构中有游戏客户端、服务器端、网络链路,所以必须要有比较完整的体系进行全方位、立体式的监控,才能保证在业务发生问题之前进行预警,或者在发生问题时报警。

(信息流QPS与时延)

对于机房链路,有IDC(Internet Data Center)的网络质量监控;在服务器、网络设备和硬件方面,我们会做服务器的健康检查、性能监控,以及网络设备和流量监控;

如上图所示,我们在监测中使用不同色带表示不同的性能区间:蓝色表示500ms以内的请求数,我们希望这部分所占比例越多越好。在业务高峰时段,随着请求量增加, 我们可以清楚的看到性能趋势变化;同时以虚线形式展示上个监测周期的数据,方便对比业务量变化和性能趋势。

在系统程序方面,我们会收集和分析系统日志;在游戏服务器端应用方面,有服务器端的程序监控;在客户端方面,我们会收集植入的SDK做下载更新后的效果,以及收集崩溃的数据。

图片 11

作为运维人员,我们考虑问题或者设计架构的时候,视角不能仅局限于一个技术方面,或者选用多炫酷、多么牛的技术,要想想技术在业务方面的架构,或者能否通过业务指标监控我们的运维能力与运维系统。

(错误数实时监测)

在游戏里,有一个很重要的指标就是在线人数,通过监控在线人数这个业务指标,就可以知道系统是否工作正常,是不是有漏报、误报的情况,因为很多时候任何一个环节出了问题,最终都会体现在业务上,在产生价值的数据上。

错误数也需要进行实时监测,例如:将移动端、PC端的错误数和API端的错误数同时进行比较,可以较为清晰的观察端上的错误和服务器端的错误,当相关性较弱时可能是由于某个版本更新等原因导致的客户端波动,便于进行问题定位。

所以我们有一套监控在线人数的系统,每个游戏上线之前会接入这个系统,把在线的人数实时汇集到系统里面。如果发生异常的抖动,系统中都会有所显示,也就可以知道是否发生了问题。

总之,一个好的应用与产品,需要我们持续不断的进行性能监测与分析,这种持续要求我们站在更高的视角进行性能分析体系建设。

以上讲的是一个框架,下面我们看一下细节,怎样做服务器的监控。首先由运维工程师在监控策略平台配置监控策略,监控策略平台会将这些数据格式化成相关格式,然后推送给自动化运维平台。

                                                                           白山云科技

自动化运维平台会判断是这些数据是外部来的,还是远程检测到的;是网络模拟的,还是本地的监控得到的。

                                                        国内首家云链服务提供商

比如流量、本地进程的监控、本地日志的监控,会分别推给远程探测服务器,或者游戏服务器本身,然后由它们上报数据。数据上报以后,根据运维工程师配置的阈值,会触发相关的报警,然后通知运维工程师进行相关处理。因为虽然游戏多种多样,操作系统五花八门,但是总有一些大家可以公用的东西,比如监控的模板或者监控的策略,我们对服务器的东西也进行了整合汇总。

                                                          微信ID:baishancloud

大家可以看到我们里面有很丰富的插件,运维人员只要选择相关的插件,配一下阈值和周期,就可以节省时间和学习成本,提高配置策略的效率。当配置策略完成以后,直接绑定到想要监控的服务器上就可以了。

图片 12

总结 我们从2000年初到现在一直在做自动化运维体系,对过去进行总结,我觉得有3个方面可以供大家参考。

长按二维码关注

第一是循序渐进的原则,特别是中小公司或者初创公司,很多时候并不需要一个“高大上”的系统。聚焦当前的问题,把当前的问题处理好,后面的问题也就迎刃而解。如果一开始设计的系统很庞大、功能特别丰富,会导致一些无法控制的局面。比如这个系统可能最后做不下去了,或者因为耦合性太强,开发控制不了了,或者项目因为经费问题搁浅了。

但是如果一开始的目标是解决一些特定的问题,有针对性,那么推进起来也会比较简单。

在我司的自动化运维体系建设过程中,我们首先构建的是一个基础的服务器批量操作平台,先把一部分需要重复执行的工作搬到平台上来,再依据运维的需求丰富这个操作平台的功能和提升效率,最后把周边的系统打通,相互对接,形成完整的自动化运维体系。

第二是考虑可扩展性。设计系统的时候,功能或者设计方面可能不用考虑那么多,但是要考虑当服务器数量发生比较大的扩张时,系统是否还能支撑,比如数量级从十到百,或者上千了,这个系统是否还是可用的。

第三是以实用为目的。这在我们系统中也是有体现的。

很多情况下,市面上可能已经有比较成熟的协议和工具,拿来评估看看它们在生产环境里面是否可用,如果能用就直接用,没必要自己再去做一套。

自己做的这一套工具,很多方面没有经过验证,可能会带来安全问题。

基于成熟的协议和框架去做,可以提升效率,保证稳定性和安全性。在“自动化运维平台”一节可以看到,我们并没有自己从头开始研发一套Agent植入到被管理的服务器上,而是用了开源的SSH协议和成熟的OpenSSH软件。

这体现了优先考虑开源方案加一部分二次开发而不是重复造轮子的思想。

来源:_941cfba00102xznb.html

本文由yzc216亚洲城发布于亚洲城动态,转载请注明出处:性能分析体系建设之路,如何从零搭建一个自动

关键词: 亚洲城官网 yzc216亚洲城