ImageVerifierCode 换一换
格式:DOCX , 页数:10 ,大小:21.04KB ,
资源ID:16003795      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/16003795.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(腾讯专家分享腾讯做业务监控的心得和经验Word文件下载.docx)为本站会员(b****5)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

腾讯专家分享腾讯做业务监控的心得和经验Word文件下载.docx

1、状态、生成树状态等;性能监控,包括设备CPU、设备内存大小、session数量、端口流量包量、内存溢出监控、内存使用率等;质量监控,包括设备错包、丢包率,针对网络设备以及网络链路的探测延时、丢包率监控等;容量监控,包括设备负载使用率、专线带宽使用率、出口流量分布等;架构监控,包括路由跳变、缺失、绕行,流量穿越监控等。服务器层服务器是业务部署运行起来的载体(早期服务器就是我们传统观念上的“物理机+操作系统”,现在已经扩大到虚拟机或者是容器等范畴)。服务器层的监控包括硬件层面和软件层面。硬件层面的监控主要包括如下内容:硬盘:硬盘读写错误、读写超时、硬盘掉线、硬盘介质错误、SSD硬盘硬盘温度、硬盘寿

2、命、硬盘坏块率;内存:内存缺失、内存配置错误、内存不可用、内存校验;网卡:网卡速率;电源:电源电压、电源模块是否失效;风扇:风扇转速;Raid卡:Raid卡电池状态、电池老化、电池和缓存是否在位、缓存策略。软件层面的监控主要包括:CPU:CPU整体使用率、CPU各核使用率、CPULoad负载;应用内存、整体内存、Swap等;磁盘IO:读写速率、IOPS、平均等待延时、平均服务延时等;网络流量、包量、错包、丢包;连接:各种状态的TCP连接数等进程端口存活;文件句柄数;进程数;内网探测延时;丢包率等。业务程序层容量管理系统:容量管理系统基于“服务器层”在软件层面的监控指标,并且配合业务增长、运营活

3、动等因素而建设,用于客观衡量业务负载高低情况,并结合扩缩容调度,实现业务的负载和成本间的平衡。具体原理是根据服务器所在业务层级(接入层、逻辑层还是数据层)的不同,设置不同的容量参考指标、指标参考基准、指标计算规则、高低负载判别规则,设置业务模块(由相同功能的多个服务器构成的业务集群)的扩缩容规则;由系统计算出服务器、业务模块的负载情况,决策出是否需要扩容或缩容,触发业务模块的扩缩容操作。说明:服务器、业务模块的负载计算规则也是由业务可以自定义配置。模块间调用:在腾讯内部简称“模调”,2006年开始已经广泛应用于各大业务,用于实时监测后端服务与服务之间调用的质量,可以细化到服务模块、接口、命令字

4、甚至代码层面(现在看来,其实就是目前各个APM厂商在大力宣传和推广的代码级监控产品)。1、针对使用标准化组件(在腾讯内部业务,用户层使用的标准组件是wns;接入层使用的标准组件是Qzhttp、tngix;逻辑层使用的标准组件是spp+L5;数据层使用的标准组件是CKV、CDB等)的业务,由标准组件上报模调监控数据;2、针对自定义业务Server,提供模调上报的SDK或API,由业务自主上报服务间的每次调用成功与否,每次调用的延时;3、模调系统支持业务从用户层->接入层-&逻辑层-&数据层,全路径用唯一的序列号(通常由时间、功能模块ID、UIN、随机值等因素构成此值)来对业务请求染色,方便

5、业务展现出每次请求完整的从前到后的调用链路。用户体验测速系统:收集用户真实访问业务的速度、性能、成功率数据。PC类业务由js上报或者客户端程序监控模块上报,移动类业务通过引入腾讯分析上报到监控系统。测速系统的价值不仅仅在于实时监控,还有一个很有价值的作用:业务架构优化前后,对比用户访问业务的速度对比,指导和衡量业务架构优化的客观效果。云拨测:通过模拟用户访问业务并校验返回数据结果,监测业务是否可用、访问质量及性能、逻辑功能正确性的监控系统。当然和云拨测同类的产品或者公司也挺多的,比如基调、监控宝、博睿等等。我们自己要建立云拨测其中的一个原因是:腾讯业务需要监控业务逻辑是否正常,而不仅仅是接入层

6、(网站类业务是否能访问,访问的速度是否快),业务逻辑的验证就涉及到登录鉴权、关系数据自动化获取等,外部监控服务商无法实现这一点。接下来讲下告警关联和业务容灾的内容有这么多监控系统,如果没有告警智能关联,我们会怎么样?简单举一个例子,如果某个业务在数据层的服务器(假设安装的是redis)有硬件故障,前端业务也没有做好足够的容灾切换,那么该业务的接入层、逻辑层、数据层在用户体验、业务程序层将产生大量的告警,形成告警风暴。为了解决该问题,腾讯内部有一个ROOT系统,基于业务架构,结合业务数据流访问关系,通过时间相关性、面积权重等算法,将监控告警进行分类、关联,发掘出告警的根源所在。告警关联的一个基本

7、思路是,越靠近业务后端(逻辑层处于接入层的后端,数据层处于逻辑层的后端)的告警越趋近于故障根源;越靠近基础设施层的告警越趋近于故障根源。还是刚才所举的例子:监控系统在关联所有告警后,发给运维和研发的告警将是分析后的结论:redis所在服务器硬件故障,导致业务请求量下降xx%,业务整体流量下降XX%。以上的内容简单介绍了目前腾讯业务核心的几个监控系统,当然还有很多其他系统没有提及到,比如自动化测试监控、组件特性监控、业务自定义特性监控、业务流量染色监控、业务全路径日志染色等。业务容灾调度柔性我们始终认为:监控系统、运维工具不是万能的。如果要业务可用性不断靠近100%,需要业务侧做很多容灾、调度、

8、柔性的工作。腾讯业务在容灾、调度、柔性上做了哪些工作呢?由于篇幅有限,不能完全列举,我仅分享几个比较有代表性的思路和方法。1、在用户端:为了应对网络环境复杂的情况,腾讯移动类业务采用公司统一的业务接入框架维纳斯【维纳斯(WNS,WirelessNetworkService),又名移动连通服务,是一个为APP提供高连通、高可靠、强安全的网络连接通道的服务;它利用QQ、微信海量接入数据来持续优化调度算法,并集成了用户就近接入、腾讯直通车、加密通道透传功能等等,提供了手机端SDK(IOS/Android),业务不必关心网络细节,即可安全与业务后台简单可靠的通讯】。目前,WNS服务已经通过腾讯云完全开

9、放,大家可以去使用。2、业务接入层:业务接入层大多数是无状态设计(或者是有规则的分号段接入),在运营部署规划的过程中,根据业务规模大小,选择不同程度的容灾,通常有跨交换机、跨机架、跨机房、跨地域容灾。业务全量接入TGW(腾讯云网关)实现负载均衡,避免单个服务器、交换机、机房出现故障时,业务完全瘫痪。3、业务逻辑层:业务间的逻辑调用都是通过L5组件(名字服务+负载均衡)访问,L5组件基于服务器初始配置信息,通过自适应算法,以两个关键指标请求成功率和请求延时为依据,周期性计算出每个被调服务器的权重,再使用高效的配额算法分配各个主调服务的访问路由,主调服务器上的业务进程通过API来取得这些路由,调用

10、结束时通过来反馈路由的好与坏。4、网络调度:主要有同城跨运营商调度和同运营商跨城调度。假设上海电信出口有故障,我们将通过GSLB域名解析指向调度到同城其他运营商的接入集群,实现容灾。腾讯有几个核心的IDC节点,多个节点之间有专线互联,所以我们也可以将上海电信接入的这部分用户牵引到北京电信或者深圳电信进行接入,实现业务的容灾-这就是同运营商跨城调度。调度的过程,业务完全无感知。5、柔性:分基础设施层面的柔性和业务逻辑功能上的柔性。柔性是容灾、调度切换等手段的补充。基础设施层面的柔性,举一个例子:当运营商网络、专线网络拥塞的时候,我们可以根据业务的服务等级不同启动不通等级的流量控制。业务功能上的柔

11、性也举一个简单易懂的例子:某个业务如果提供了文字、语音、视频、互动等功能,当网络高负载或者业务整体高负载时,可以通过柔性开关控制关闭调某些高消耗资源的功能和服务。 总结:监控体系是业务运营体系中非常重要的一个环节,但业务可用性的提高是需要基础设施支撑团队、业务运维团队、业务研发团队一起去通力合作,才能做到更好的。问答实录:1.L5具体是干啥的?没有明白。答:其实就是我们内部业务逻辑的名字服务+负载均衡组件。服务A调用服务B,通过组件调用,我们称为主调方,A在获得服务B的IPort列表时,需要通过获得。调用的成功率和延时是由系统自反馈和实时更新的。2.请教一个问题,我们是一个小公司,服务器30多

12、台,再监控方面有什么要注意的?感谢!看你具体要做到什么程度,你是用云还是托管,还是?如果你只需要覆盖服务器层面,有很多开源监控满足你的需求。当然规模扩大了,需要考虑,数据如何整合融合。3.我想请教一个问题腾讯内部系统是什么样的一个系统?怎么做的告警关联分析?监控产品使用的哪些?就是集合所有监控系统的数据和告警,基于对象及对象访问关系,不同监控层次数据关联。简单举个例子:业务A,有接入层、逻辑层、数据层,这几个层次的对象访问关系(业务逻辑拓扑)根据“模调”系统可以得到;这几个层次也各自有基础设施、服务器层面、业务程序层面的数据和告警。最简单的做法:加入数据层服务器有硬件故障告警X,我们可以怀疑数据层的业务程序层的告警Y就是 X所引起的。以此类推:逻辑层的告警我们可以怀疑是某些故障告警引起的。接入层的告警我们可以怀疑是逻辑层的引起的。当然具体实现过程中涉及:数据时间窗对齐、对象纬度标准规范化、递

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1