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

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

《腾讯专家分享腾讯做业务监控的心得和经验Word文件下载.docx》由会员分享，可在线阅读，更多相关《腾讯专家分享腾讯做业务监控的心得和经验Word文件下载.docx（5页珍藏版）》请在冰豆网上搜索。

基础设施层的监控覆盖范围很广，在腾讯包括：

与运营商互联出口、专线（包括城域和广域）、机房（包括各类物理设施---如机架、制冷、配电、消防、安防等）、网络设备（交换机、路由器、防火墙等）等。

基础设施层的监控又分为状态、性能、质量、容量、架构等几个层面。

举例说明：

▎状态监控，包括网络设备的软硬件状态，如设备存活状态、板卡、电源、风扇状态，设备温度、光功率、OSPF状态、生成树状态等；

▎性能监控，包括设备CPU、设备内存大小、session数量、端口流量包量、内存溢出监控、内存使用率等；

▎质量监控，包括设备错包、丢包率，针对网络设备以及网络链路的探测延时、丢包率监控等；

▎容量监控，包括设备负载使用率、专线带宽使用率、出口流量分布等；

▎架构监控，包括路由跳变、缺失、绕行，流量穿越监控等。

服务器层

服务器是业务部署运行起来的载体（早期服务器就是我们传统观念上的“物理机+操作系统”，现在已经扩大到虚拟机或者是容器等范畴）。

服务器层的监控包括硬件层面和软件层面。

硬件层面的监控主要包括如下内容：

▎硬盘：

硬盘读写错误、读写超时、硬盘掉线、硬盘介质错误、[SSD硬盘]硬盘温度、硬盘寿命、硬盘坏块率；

▎内存：

内存缺失、内存配置错误、内存不可用、内存校验；

▎网卡：

网卡速率；

▎电源：

电源电压、电源模块是否失效；

▎风扇：

风扇转速；

▎Raid卡：

Raid卡电池状态、电池老化、电池和缓存是否在位、缓存策略。

软件层面的监控主要包括：

▎CPU：

CPU整体使用率、CPU各核使用率、CPULoad负载；

应用内存、整体内存、Swap等；

▎磁盘IO：

读写速率、IOPS、平均等待延时、平均服务延时等；

▎网络IO：

流量、包量、错包、丢包；

▎连接：

各种状态的TCP连接数等▎进程端口存活；

文件句柄数；

进程数；

内网探测延时；

丢包率等。

业务程序层

容量管理系统：

容量管理系统基于“服务器层”在软件层面的监控指标，并且配合业务增长、运营活动等因素而建设，用于客观衡量业务负载高低情况，并结合扩缩容调度，实现业务的负载和成本间的平衡。

具体原理是根据服务器所在业务层级（接入层、逻辑层还是数据层）的不同，设置不同的容量参考指标、指标参考基准、指标计算规则、高低负载判别规则，设置业务模块（由相同功能的多个服务器构成的业务集群）的扩缩容规则；

由系统计算出服务器、业务模块的负载情况，决策出是否需要扩容或缩容，触发业务模块的扩缩容操作。

说明：

服务器、业务模块的负载计算规则也是由业务可以自定义配置。

模块间调用：

在腾讯内部简称“模调”，2006年开始已经广泛应用于各大业务，用于实时监测后端服务与服务之间调用的质量，可以细化到服务模块、接口、命令字甚至代码层面（现在看来，其实就是目前各个APM厂商在大力宣传和推广的代码级监控产品）。

●1、针对使用标准化组件（在腾讯内部业务，用户层使用的标准组件是wns；

接入层使用的标准组件是Qzhttp、tngix；

逻辑层使用的标准组件是spp+L5；

数据层使用的标准组件是CKV、CDB等）的业务，由标准组件上报模调监控数据；

●2、针对自定义业务Server，提供模调上报的SDK或API，由业务自主上报服务间的每次调用成功与否，每次调用的延时；

●3、模调系统支持业务从用户层-&

gt;

接入层-&

逻辑层-&

数据层，全路径用唯一的序列号（通常由时间、功能模块ID、UIN、随机值等因素构成此值）来对业务请求染色，方便业务展现出每次请求完整的从前到后的调用链路。

用户体验

测速系统：

收集用户真实访问业务的速度、性能、成功率数据。

PC类业务由js上报或者客户端程序监控模块上报，移动类业务通过引入腾讯分析SDK上报到监控系统。

测速系统的价值不仅仅在于实时监控，还有一个很有价值的作用：

业务架构优化前后，对比用户访问业务的速度对比，指导和衡量业务架构优化的客观效果。

云拨测：

通过模拟用户访问业务并校验返回数据结果，监测业务是否可用、访问质量及性能、逻辑功能正确性的监控系统。

当然和云拨测同类的产品或者公司也挺多的，比如基调、监控宝、博睿等等。

我们自己要建立云拨测其中的一个原因是：

腾讯业务需要监控业务逻辑是否正常，而不仅仅是接入层（网站类业务是否能访问，访问的速度是否快），业务逻辑的验证就涉及到登录鉴权、关系数据自动化获取等，外部监控服务商无法实现这一点。

接下来讲下告警关联和业务容灾的内容有这么多监控系统，如果没有告警智能关联，我们会怎么样？

简单举一个例子，如果某个业务在数据层的服务器（假设安装的是redis）有硬件故障，前端业务也没有做好足够的容灾切换，那么该业务的接入层、逻辑层、数据层在用户体验、业务程序层将产生大量的告警，形成告警风暴。

为了解决该问题，腾讯内部有一个ROOT系统，基于业务架构，结合业务数据流访问关系，通过时间相关性、面积权重等算法，将监控告警进行分类、关联，发掘出告警的根源所在。

告警关联的一个基本思路是，越靠近业务后端（逻辑层处于接入层的后端，数据层处于逻辑层的后端）的告警越趋近于故障根源；

越靠近基础设施层的告警越趋近于故障根源。

还是刚才所举的例子：

监控系统在关联所有告警后，发给运维和研发的告警将是分析后的结论：

redis所在服务器硬件故障，导致业务请求量下降xx%，业务整体流量下降XX%。

以上的内容简单介绍了目前腾讯业务核心的几个监控系统，当然还有很多其他系统没有提及到，比如自动化测试监控、组件特性监控、业务自定义特性监控、业务流量染色监控、业务全路径日志染色等。

业务容灾调度柔性我们始终认为：

监控系统、运维工具不是万能的。

如果要业务可用性不断靠近100%，需要业务侧做很多容灾、调度、柔性的工作。

腾讯业务在容灾、调度、柔性上做了哪些工作呢？

由于篇幅有限，不能完全列举，我仅分享几个比较有代表性的思路和方法。

●1、在用户端：

为了应对网络环境复杂的情况，腾讯移动类业务采用公司统一的业务接入框架维纳斯【维纳斯（WNS，WirelessNetworkService）,又名移动连通服务，是一个为APP提供高连通、高可靠、强安全的网络连接通道的服务；

它利用QQ、微信海量接入数据来持续优化调度算法，并集成了用户就近接入、腾讯直通车、加密通道透传功能等等，提供了手机端SDK（IOS/Android），业务不必关心网络细节，即可安全与业务后台简单可靠的通讯】。

目前，WNS服务已经通过腾讯云完全开放，大家可以去使用。

●2、业务接入层：

业务接入层大多数是无状态设计（或者是有规则的分号段接入），在运营部署规划的过程中，根据业务规模大小，选择不同程度的容灾，通常有跨交换机、跨机架、跨机房、跨地域容灾。

业务全量接入TGW（腾讯云网关）实现负载均衡，避免单个服务器、交换机、机房出现故障时，业务完全瘫痪。

●3、业务逻辑层：

业务间的逻辑调用都是通过L5组件（名字服务+负载均衡）访问，L5组件基于服务器初始配置信息，通过自适应算法，以两个关键指标请求成功率和请求延时为依据，周期性计算出每个被调服务器的权重，再使用高效的配额算法分配各个主调服务的访问路由，主调服务器上的业务进程通过API来取得这些路由，调用结束时通过API来反馈路由的好与坏。

●4、网络调度：

主要有同城跨运营商调度和同运营商跨城调度。

假设上海电信出口有故障，我们将通过GSLB域名解析指向调度到同城其他运营商的接入集群，实现容灾。

腾讯有几个核心的IDC节点，多个节点之间有专线互联，所以我们也可以将上海电信接入的这部分用户牵引到北京电信或者深圳电信进行接入，实现业务的容灾---这就是同运营商跨城调度。

调度的过程，业务完全无感知。

●5、柔性：

分基础设施层面的柔性和业务逻辑功能上的柔性。

柔性是容灾、调度切换等手段的补充。

基础设施层面的柔性，举一个例子：

当运营商网络、专线网络拥塞的时候，我们可以根据业务的服务等级不同启动不通等级的流量控制。

业务功能上的柔性也举一个简单易懂的例子：

某个业务如果提供了文字、语音、视频、互动等功能，当网络高负载或者业务整体高负载时，可以通过柔性开关控制关闭调某些高消耗资源的功能和服务。

总结：

监控体系是业务运营体系中非常重要的一个环节，但业务可用性的提高是需要基础设施支撑团队、业务运维团队、业务研发团队一起去通力合作，才能做到更好的。

问答实录：

1.L5具体是干啥的？

没有明白。

答：

L5其实就是我们内部业务逻辑的名字服务+负载均衡组件。

服务A调用服务B，通过L5组件调用，我们称A为主调方，A在获得服务B的IPort列表时，需要通过L5API获得。

调用的成功率和延时是由系统自反馈和实时更新的。

2.请教一个问题，我们是一个小公司，服务器30多台，再监控方面有什么要注意的？

感谢！

看你具体要做到什么程度，你是用云还是IDC托管，还是？

如果你只需要覆盖服务器层面，有很多开源监控满足你的需求。

当然规模扩大了，需要考虑，数据如何整合融合。

3.我想请教一个问题腾讯内部ROOT系统是什么样的一个系统？

怎么做的告警关联分析？

监控产品使用的哪些？

就是集合所有监控系统的数据和告警，基于对象及对象访问关系，不同监控层次数据关联。

简单举个例子：

业务A，有接入层、逻辑层、数据层，这几个层次的对象访问关系（业务逻辑拓扑）根据“模调”系统可以得到；

这几个层次也各自有基础设施、服务器层面、业务程序层面的数据和告警。

最简单的做法：

加入数据层服务器有硬件故障告警X，我们可以怀疑数据层的业务程序层的告警Y就是X所引起的。

以此类推：

逻辑层的告警我们可以怀疑是数据层的某些故障告警引起的。

接入层的告警我们可以怀疑是逻辑层的某些故障告警引起的。

当然具体实现过程中涉及：

数据时间窗对齐、对象纬度标准规范化、递归成环的一些具体难点。

4.在海量业务监控上，这么多的监控平台，腾讯是如何合理管理监控系统权限，是统一管理，还是分部门对监控平台管理？

监控系统一个通用的平台，但业务模块是按照部门或者团队的，所以自己团队，只能看到自己所相关的业务。

5.当运营商网络、专线网络拥塞的时候，我们可以根据业务的服务等级不同启动不通等级的流量控制，这是过程由监控自动触发完成任务的，还是需要人工参与相关流量控制的策略调配?

人工参与和系统设置自动生效两种都有，所有业务都是经过人工实施一段时间，稳定后变成系统自动生效的。

特别是CBN专线流量控制上，我们也还是比较谨慎的。

6.ROOT系统是腾讯自主研发，还是基于产品二次开发的？

自主研发的，呵呵。

告警智能关联，而且涉及业务逻辑模型抽象，目前没有成熟的产品或服务。