作者丨罗伟：2008 年加入腾讯，长期从事腾讯 SNG 业务的运营支撑、监控系统的建设，曾主导建设 Qzone、 手机 Qzone、手机 QQ 等业务监控系统及监控平台的建立和运营，目前负责黑石产品架构工作。
导语：本文介绍了腾讯业务监控体系的层级构成，用代表性的监控系统阐述每个监控层次的实现方法，以及与监控体系配合，业务做了哪些容灾和调度的方案。从而和大家分享腾讯最完整的关于做监控系统的思考。
首先很荣幸在这里给大家分享腾讯在做业务监控的一些心得和经验，当然今天所提及的只是腾讯业务运营监控体系中的小部分，也欢迎大家一起在运营体系建设、精细化运维等方面共同探讨和学习。
我们用一个 QQ 红包开始今天的分享吧。
表面看是抢红包这么简单的一个功能，其实光抢红包这个动作，它所关联的监控系统就有好多个！
如图所示，腾讯的业务从逻辑上可以抽象总结成四个层次：用户层（ PC、手机、智能硬件等）、接入层、逻辑层和数据层（包括数据缓存层和持久化层）。腾讯业务的监控系统是立体化覆盖，总结来说也是由四个层级组成：
基础设施层的监控覆盖范围很广，在腾讯包括：与运营商互联出口、专线(包括城域和广域)、机房(包括各类物理设施---如机架、制冷、配电、消防、安防等)、网络设备（交换机、路由器、防火墙等）等。
基础设施层的监控又分为状态、性能、质量、容量、架构等几个层面。举例说明:
状态监控包括网络设备的软硬件状态（如设备存活状态、板卡、电源、风扇状态，设备温度、光功率、OSPF 状态、生成树状态等）； 性能监控包括设备 CPU、设备内存大小、session 数量、端口流量包量、内存溢出监控、内存使用率等； 质量监控包括设备错包、丢包率，针对网络设备以及网络链路的探测延时、丢包率监控等； 容量监控包括设备负载使用率、专线带宽使用率、出口流量分布等； 架构监控包括路由跳变、缺失、绕行，流量穿越监控等。
服务器是业务部署运行起来的载体（早期服务器就是我们传统观念上的“物理机+操作系统”，现在已经扩大到虚拟机或者是容器等范畴）。服务器层的监控包括硬件层面和软件层面。
硬件层面的监控主要包括如下内容:
软件层面的监控主要包括：CPU （ CPU 整体使用率、CPU 各核使用率、CPU Load 负载）、内存（应用内存、整体内存、Swap 等）、磁盘 IO （读写速率、IOPS、平均等待延时、平均服务延时等）、网络 IO （流量、包量、错包、丢包）、连接（各种状态的 TCP 连接数等）、进程端口存活、文件句柄数、进程数、内网探测延时、丢包率等。
业务程序层的监控手段是最为丰富和立体化的，这里只是介绍几个核心和典型的系统。
容量管理系统基于“服务器层”在软件层面的监控指标，并且配合业务增长、运营活动等因素而建设，用于客观衡量业务负载高低情况，并结合扩缩容调度，实现业务的负载和成本间的平衡。
具体原理是根据服务器所在业务层级（接入层、逻辑层还是数据层）的不同，设置不同的容量参考指标、指标参考基准、指标计算规则、高低负载判别规则，设置业务模块（由相同功能的多个服务器构成的业务集群）的扩缩容规则；由系统计算出服务器、业务模块的负载情况，决策出是否需要扩容或缩容，触发业务模块的扩缩容操作。
说明：服务器、业务模块的负载计算规则也是由业务可以自定义配置。
在腾讯内部简称“模调”，2006 年开始已经广泛应用于各大业务，用于实时监测后端服务与服务之间调用的质量，可以细化到服务模块、接口、命令字甚至代码层面（现在看来，其实就是各个 APM 厂商在大力宣传和推广的产品）。
针对使用标准化组件（在腾讯内部业务，用户层使用的标准组件是 wns ；接入层使用的标准组件是 Qzhttp、tngix ；逻辑层使用的标准组件是 spp+L5 ；数据层使用的标准组件是 CKV、CDB 等）的业务，由标准组件上报模调监控数据；
针对自定义业务 Server，提供模调上报的 SDK 或 API，由业务自主上报服务间的每次调用成功与否，每次调用的延时；
模调系统支持业务从用户层->接入层->逻辑层->数据层，全路径用唯一的序列号(通常由时间、功能模块 ID、UIN、随机值等因素构成此值)来对业务请求染色，方便业务展现出每次请求完整的从前到后的调用链路。
收集用户真实访问业务的速度、性能、成功率数据。PC 类业务由 js 上报或者客户端程序监控模块上报，移动类业务通过引入腾讯分析 SDK 上报到监控系统。测速系统的价值不仅仅在于实时监控，还有一个比较有意义的作用是：业务架构优化前后，对比用户访问业务的速度，指导和衡量业务架构优化的客观效果。
通过模拟用户访问业务并校验返回数据结果，监测业务是否可用、访问质量及性能、逻辑功能正确性的监控系统。当然和云拨测同类的产品或者公司也挺多的，比如基调、监控宝、博睿等等。我们自己要建立云拨测其中的一个原因是：腾讯业务需要监控业务逻辑是否正常，而不仅仅是接入层(网站类业务是否能访问，访问的速度是否快)，业务逻辑的验证就涉及到鉴权、关系数据的自动化获取等，外部监控服务商无法实现这一点。
以上的内容简单介绍了目前腾讯业务核心的几个监控系统，当然还有很多其他系统没有提及到，比如自动化测试监控、组件特性监控、业务染色等。接下来讲下告警关联和业务容灾的内容。
有这么多监控系统，如果没有告警智能关联，我们会怎么样？简单举一个例子，如果某个业务在数据层的服务器(假设安装的是 redis)有硬件故障，前端业务也没有做好足够的容灾切换，那么该业务的接入层、逻辑层、数据层在用户体验、业务程序层将产生大量的告警，形成告警风暴。为了解决该问题，腾讯内部有一个 ROOT 系统，基于业务架构，结合业务数据流访问关系，通过时间相关性、面积权重等算法，将监控告警进行分类、关联，发掘出告警的根源所在。
我们始终认为： 监控系统、运维工具不是万能的。如果要业务可用性不断靠近 100%，需要业务侧做很多容灾、调度、柔性的工作。
腾讯业务在容灾、调度、柔性上做了哪些工作呢？由于篇幅有限，不能完全列举，我仅分享几个比较有代表性的思路和方法。
1、在用户端，为了应对网络环境复杂的情况，腾讯移动类业务采用公司统一的业务接入框架维纳斯。
[维纳斯(WNS，Wireless Network Service),又名移动连通服务，是一个为 APP 提供高连通、高可靠、强安全的网络连接通道的服务；它利用 QQ、微信海量接入数据来持续优化调度算法，并集成了用户就近接入、腾讯直通车、加密通道透传功能等等，提供了手机端 SDK （ IOS/Android ），业务不必关心网络细节，即可安全与业务后台简单可靠的通讯] 。
2、业务接入层：业务接入层大多数是无状态设计（或者是有规则的分号段接入），在运营部署规划的过程中，根据业务规模大小，选择不同程度的容灾，通常有跨交换机、跨机架、跨机房、跨地域容灾。
业务全量接入 TGW （腾讯云网关）实现负载均衡，避免单个服务器、交换机、机房出现故障时，业务完全瘫痪。
3、业务逻辑层：业务间的逻辑调用都是通过 L5 组件（名字服务+负载均衡）访问，L5 组件基于服务器初始配置信息，通过自适应算法，以两个关键指标请求成功率和请求延时为依据，周期性计算出每个被调服务器的权重，再使用高效的配额算法分配各个主调服务的访问路由，主调服务器上的业务进程通过 API 来取得这些路由，调用结束时通过 API 来反馈路由的好与坏。
4、网络调度：主要有同城跨运营商调度和同运营商跨城调度。假设上海电信出口有故障，我们将通过 GSLB 域名解析指向调度到同城其他运营商的接入集群，实现容灾；
腾讯有几个核心的 IDC 节点，多个节点之间有专线互联，所以我们也可以将上海电信接入的这部分用户牵引到北京电信或者深圳电信进行接入，实现业务的容灾---这就是同运营商跨城调度。调度的过程，业务完全无感知。
5、柔性：分基础设施层面的柔性和业务逻辑功能上的柔性。柔性是容灾、调度切换等手段的补充。
基础设施层面的柔性，举一个例子：当运营商网络、专线网络拥塞的时候，我们可以根据业务的服务等级不同启动不同等级的流量控制。
业务功能上的柔性, 也举一个简单易懂的例子：某个业务如果提供了文字、语音、视频、互动等功能，当网络高负载或者业务整体高负载时，可以通过柔性开关控制关闭掉某些高消耗资源的功能和服务。
监控体系是业务运营体系中非常重要的一个环节，但业务可用性的提高是需要基础设施支撑团队、业务运维团队、业务研发团队一起通力合作，才能做到更好。篇幅和时间有限，我的分享结束了，感谢各位。
欢迎关注 [腾讯织云] 公众号，获取最新技术资讯。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.