腾讯专家分享腾讯做业务监控的心得和经验.docx

腾讯专家分享腾讯做业务监控的心得和经验.docx

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

腾讯专家分享腾讯做业务监控的心得和经验

腾讯专家分享：

腾讯做业务监控的心得和经验

分享主题：

腾讯业务立体化监控体系 1、介绍腾讯业务监控体系的层级

构成；

2、用代表性的监控系统阐述每个监控层次的实现方法；

3、与监控体系配合，业务做了哪些容灾和调度的方案。

分享实录：

首先很荣幸在这里给大家分享腾讯在做业务监控的一些心

得和经验，当然今天所提及的只是腾讯业务运营监控体系

中的小部分，也欢迎大家一起在运营体系建设、精细化运

维等方面共同探讨和学习。

我们用一个 QQ 红包开始今天的分享吧。

表面看是抢红包这么简单的一个功能，其实光抢红包这个

动作，它所关联的监控系统就有好多个！

如图所示，腾讯

的业务从逻辑上可以抽象总结成四个层次：

用户层（PC、

手机、智能硬件等）、接入层、逻辑层和数据层（包括数据

缓存层和持久化层）。

腾讯业务的监控系统是立体化覆盖，总结来说也是由四个

层级组成：

基础设施层

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

与运营商

互联出口、专线（包括城域和广域）、机房（包括各类物理设施

---如机架、制冷、配电、消防、安防等）、网络设备（交换

机、路由器、防火墙等）等。

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

等几个层面。

举例说明：

▎状态监控，包括网络设备的软硬件状态，如设备存活状

态、板卡、电源、风扇状态，设备温度、光功率、OSPF 状

态、生成树状态等；

▎性能监控，包括设备 CPU、设备内存大小、session 数

量、端口流量包量、内存溢出监控、内存使用率等；

▎质量监控，包括设备错包、丢包率，针对网络设备以及

网络链路的探测延时、丢包率监控等；

▎容量监控，包括设备负载使用率、专线带宽使用率、出

口流量分布等；

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

等。

服务器层

服务器是业务部署运行起来的载体（早期服务器就是我们

传统观念上的“物理机+操作系统”，现在已经扩大到虚拟机

或者是容器等范畴）。

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

层面。

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

▎硬盘：

硬盘读写错

误、读写超时、硬盘掉线、硬盘介质错误、[SSD 硬盘]硬盘

温度、硬盘寿命、硬盘坏块率；

▎内存：

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

验；

▎网卡：

网卡速率；

▎电源：

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

▎风扇：

风扇转速；

▎Raid 卡：

Raid 卡电池状态、电池老化、电池和缓存是否

在位、缓存策略。

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

▎CPU：

CPU 整体使用率、CPU 各核使用率、CPU Load 负

载；▎内存：

应用内存、整体内存、Swap 等；▎磁盘 IO：

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

络 IO：

流量、包量、错包、丢包；▎连接：

各种状态的

TCP 连接数等▎进程端口存活；文件句柄数；进程数；内网

探测延时；丢包率等。

业务程序层

容量管理系统：

容量管理系统基于“服务器层”在软件层面的

监控指标，并且配合业务增长、运营活动等因素而建设，

用于客观衡量业务负载高低情况，并结合扩缩容调度，实

现业务的负载和成本间的平衡。

具体原理是根据服务器所在业务层级（接入层、逻辑层还

是数据层）的不同，设置不同的容量参考指标、指标参考

基准、指标计算规则、高低负载判别规则，设置业务模块

（由相同功能的多个服务器构成的业务集群）的扩缩容规

则；由系统计算出服务器、业务模块的负载情况，决策出

是否需要扩容或缩容，触发业务模块的扩缩容操作。

说

明：

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

定义配置。

模块间调用：

在腾讯内部简称“模调”，2006 年开始已经广泛应用于各大

业务，用于实时监测后端服务与服务之间调用的质量，可

以细化到服务模块、接口、命令字甚至代码层面（现在看

来，其实就是目前各个 APM 厂商在大力宣传和推广的代码

级监控产品）。

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

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

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

准组件是 CKV、CDB 等）的业务，由标准组件上报模调监

控数据；

●2、针对自定义业务 Server，提供模调上报的 SDK 或

API，由业务自主上报服务间的每次调用成功与否，每次调

用的延时；

●3、模调系统支持业务从用户层->接入层->逻辑层-

>数据层，全路径用唯一的序列号（通常由时间、功能模

块 ID、UIN、随机值等因素构成此值）来对业务请求染色，

方便业务展现出每次请求完整的从前到后的调用链路。

用

户体验

测速系统：

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

PC 类

业务由 js 上报或者客户端程序监控模块上报，移动类业务

通过引入腾讯分析 SDK 上报到监控系统。

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

的作用：

业务架构优化前后，对比用户访问业务的速度对

比，指导和衡量业务架构优化的客观效果。

云拨测：

通过模拟用户访问业务并校验返回数据结果，监测业务是

否可用、访问质量及性能、逻辑功能正确性的监控系统。

当然和云拨测同类的产品或者公司也挺多的，比如基调、

监控宝、博睿等等。

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

因是：

腾讯业务需要监控业务逻辑是否正常，而不仅仅是接入层

（网站类业务是否能访问，访问的速度是否快），业务逻辑的

验证就涉及到登录鉴权、关系数据自动化获取等，外部监

控服务商无法实现这一点。

接下来讲下告警关联和业务容灾的内容有这么多监控系

统，如果没有告警智能关联，我们会怎么样？

简单举一个

例子，如果某个业务在数据层的服务器（假设安装的是 redis）

有硬件故障，前端业务也没有做好足够的容灾切换，那么

该业务的接入层、逻辑层、数据层在用户体验、业务程序

层将产生大量的告警，形成告警风暴。

为了解决该问题，腾讯内部有一个 ROOT 系统，基于业务

架构，结合业务数据流访问关系，通过时间相关性、面积

权重等算法，将监控告警进行分类、关联，发掘出告警的

根源所在。

告警关联的一个基本思路是，越靠近业务后端

（逻辑层处于接入层的后端，数据层处于逻辑层的后端）

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

近于故障根源。

还是刚才所举的例子：

监控系统在关联所

有告警后，发给运维和研发的告警将是分析后的结论：

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

整体流量下降 XX%。

以上的内容简单介绍了目前腾讯业务核心的几个监控系

统，当然还有很多其他系统没有提及到，比如自动化测试

监控、组件特性监控、业务自定义特性监控、业务流量染

色监控、业务全路径日志染色等。

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

监控系统、运维工具不

是万能的。

如果要业务可用性不断靠近 100%，需要业务侧

做很多容灾、调度、柔性的工作。

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

由于篇

幅有限，不能完全列举，我仅分享几个比较有代表性的思

路和方法。

●1、在用户端：

为了应对网络环境复杂的情

况，腾讯移动类业务采用公司统一的业务接入框架维纳斯

【维纳斯（WNS，Wireless Network Service）,又名移动连通服

务，是一个为 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 列表时，需要通过 L5 API 获

得。

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

2.

请教一个问题，我们是一个小公司，服务器 30 多台，再监

控方面有什么要注意的？

感谢！

答：

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

还是？

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

满足你的需求。

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

合 融合。

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

统？

怎么做的告警关联分析？

监控产品使用的哪些？

答：

就是集合所有监控系统的数据和告警，基于对象 及 对象

访问关系，不同监控层次数据关联。

简单举个例子：

业务 A，有接入层、逻辑层、数据层， 这

几个层次的对象访问关系（业务逻辑拓扑）根据“模调”系统

可以得到；这几个层次也各自有基础设施、服务器层面、

业务程序 层面的数据和告警。

最简单的做法：

加入数据层 服务器有硬件故障告警 X，我

们可以怀疑 数据层的 业务程序层的告警 Y 就是X 所引

起的。

以此类推：

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

引起的 。

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

引起的。

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

数据时间窗对齐、对象纬度标

准规范化、递