腾讯课堂停课不停学：监控体系演进

衡生 • 2023-01-02 • 云技术社区 • 282 阅读

| 导语疫情来势凶猛，腾讯课堂“停课不停学”专项为千万学子保驾护航。面对一个月内课堂流量的暴涨，监控体系如何在有限的时间内快速发现潜在问题并高效定位，进而保证服务稳定？本文对课堂的监控实践做一个总结，并且对未来监控体系提出一些思考。文章如有错误，欢迎指正~

一、我们遇到的挑战

课堂PCU从5w到600w，接入层QPS从1.4w涨到65w，如何对海量请求进行监控，快速发现并解决问题成了很大的挑战。拆分到具体细节，主要有以下几点：

如何通过监控保障服务质量？
需要监控哪些指标？需要使用哪些监控工具？
需要对哪些指标进行告警？告警具体有哪些方法？
如何保证告警之后处理流程的高效？
除了监控、告警外，还有哪些方法可以用来保证服务的稳定？

二、我们如何来应对

2.1 明确思路：快速监控业务，后续逐步优化

随着极速版、公立校版陆续上线，PCU也迅速上涨到百万量级。各服务已经通过扩容来抗住了剧增的流量，但此时没有太多时间来推动各系统排查隐患进行优化，那么通过监控系统来监测业务稳定，基于错误码维度的业务告警来发现问题，推动各系统针对性地进行处理优化，业务稳定后再将优化监控，覆盖到更多维度的指标，进一步提升服务稳定性。

2.2 监控工具

作为管理基础设施和业务的核心工具，监控是公司各业务必不可少的能力，课堂也是在公司和业界种类繁多的监控系统中选择了适合目前现状的监控工具。

2.2.1 质量看板

作为从Kibana分化出来的Grafana，可以精美地展示数据，灵活地可视化操作，是作为监控开放平台的极佳选择，所以课堂基于Grafana构建的质量看板，对压测、监控、提前发现问题起到了非常大的作用。

不同模块层的领域知识和模型不同，故监控的指标会有所差异，应用层会关注成功率、请求量、失败明细等核心指标，而在线数据会关注连接数、慢查询数、主从同步时间、cpu负载等。

智能反馈中的用户反馈平台，是公司一套成熟的用户反馈统计分析和智能反馈系统，提供了自动的关键词组合统计，支持跨天的快速搜索、属性分布统计和趋势图分析，其中智能反馈报警系统，能够在较低阈值情况下检测出问题，有效控制误报。
人工反馈也是很重要的一种方式，毕竟很多问题场景下不会产生能够进行智能反馈的数据，譬如学校发课排课、老师调整课表等等。
- 志愿者们成立无数的学校专项反馈QQ、微信、企业微信群，临时充当了用户贴心客服的角色，7*24小时在线，能及时将用户的反馈传递到一线人员进行排查定位，不熟悉的操作也会得到耐心地支持和解答。
- 专人实时跟踪微博、B站等外部舆情走向，发现热点迅速反馈并推动处理，快速确定公关方案后及时进行互动运营。

2.3.2 告警

告警和监控息息相关，几乎前面使用的监控都有对应的告警功能，类型大致有Moniter告警、业务告警、基础指标告警、拨测告警、模调告警以及其他告警，而渠道主要有企业微信群机器人、微信、短信、邮件等。

Moniter告警有单机和视图两个维度，可根据不同的业务需求从累计、平均值、最大或最小值等不同视角进行设置，触发阈值后进行告警。
业务告警主要对全链路日志进行分析，基于错误码、处理时间进行判断，可在页面设置对“应用、命令字、错误码”三元组进行屏蔽或调高阈值等操作，也可针对命令字个性化设置超时时间。从各数据源进行拉取在质量看板集中展示，然后告警服务根据配置规则识别满足告警条件的请求进行告警。
基础指标告警是定时脚本扫描机器指标，可以按模块屏蔽阈值，后续也会支持按时间屏蔽、设置阈值等新功能，从而更好地管理告警。不同服务层的基础指标告警会有不同的实现，因领域模型的不同关注的维度也会有所差异。服务层的基础指标告警可以分为计算、存储、网络三个方面，而在线数据层则主要关注主机负载、连接数、慢查询、主备同步等维度。下面简述服务层的三个方面。
- 计算：基于织云提供的Metis智能运维功能配置阈值，包括平均负载、最大负载等，织云会自动扫描所有模块下的机器，超过阈值就会告警。
- 存储：定时脚本从CMDB接口根据模块拉取全量IP列表，然后用Monitor的API查询指定的指标（属性），超过配置的阈值就触发告警，譬如磁盘data盘使用率超过阈值机器。
- 网络：采用和存储一样的方案，包括流量掉零机器（疑似已挂）、监听队列溢出、spp_worker防雪崩丢弃请求、Kilim服务过载等指标。
拨测告警一般有定时机制来触发，通过定时回放接入层的历史请求，校验接入层链路是否通畅，非200状态码就告警出来。因曾出现过网关层异常但业务层正常的场景，故增加拨测机制来保证全链路的通畅。
模调告警主要用于逻辑层和存储层这些后台服务的质量监控告警，应该是目前后台服务质量监控最丰富、最可靠的方式，也是开发、运维必须关注和跟进的，但新增的拨测机制因其只关注网络畅通，不关注业务成功率特性的本质，导致模调告警的可信度降低，甚至会刻意忽略，故需要模调告警提供屏蔽指定用户ID的功能对拨测用户进行屏蔽。
个性化告警主要是指与具体领域知识强耦合的个性化告警，譬如极速版的课程池告警、在线数据层的慢查询超时SQL自动Kill告警等。
- 课程池告警：作为疫情期间的爆款，课堂极速版的用户增长是惊人的，但也需要对课程池使用量进行实时监控，故通过定时脚本实时同步最新的数据。
- 慢查询Kill告警：容易导致负载和连接数彪高，从而引发更严重的问题，数据层会对Kill掉超过一定阈值的SQL，同时将SQL语句、时间、请求IP等记录到特定表中，定时脚本会扫描这张表进行告警。

课堂综合采用了上述的监控和告警方式，各服务层根据领域模型上的差异，选择了适合自己的方案。

告警实践中，也会遇到一些问题，需要针对性地解决。

告警太多导致敏感度降低：重要的告警可以挂在专人身上，把其他不重要的告警都屏蔽或清除，这样能实时关注到异常情况并处理。
在告警群里同步处理显得混乱且容易遗漏告警：诸如业务告警、基础指标告警等经常出现的告警指标，可以基于群进行隔离，譬如分为接收、处理两个群。
系统稳定后长时间没有告警无法确定告警系统是否正常：告警系统每日推送告警日报，可以包括监控模块数、成功率等信息。

2.3.3 值班

为保证系统稳定，课堂各业务域每日都有专人定期巡检和现网值守，及时响应各类问题。

定期巡检
- 零点过用例：零点有测试同学回归功能用例，关键路径的问题需要连夜排查并修复，短期无法修复的需要制定并执行完备的降级方案。
- 开课前巡检：早7点测试同学回归测试案例、产品同学验证产品流程，若发现问题就要找人处理，关键路径的问题需要加急紧急处理。
- 每小时巡检：每小时会进行巡检并反馈结果，业务侧会查看质量看板中核心指标以及核心模块监控表中核心Moniter视图，数据侧会查看相关模块负载、业务数据情况，运维侧会定期巡检值班全视图。
现网值守
值班同学7:30开始现场值班，各域都有专人值班，其中课堂逻辑包括产品、业务前后端、PC客户端、移动端、数据、音视频前后端、基础服务、测试等域，同时也包括PAAS、IAAS层相关域同学，譬如webrtc、快直播、互动直播、云通信、CDB、Redis、WNS、STGW等域。
值班同学还需要关注业务、基础指标的告警群，出现告警时先自己排查定位，业务告警需分析下游系统、可能原因等，无法明确的问题推动相关同学进行处理，最终得出明确的解决方案，譬如发布优化、调高阈值、屏蔽告警、继续观察等，记录告警汇总文档，每日汇总同步并持续跟进，便于后续定位和每周汇总。

业务告警基本处理流程

基于业务、基础指标告警的值班使得告警数量呈明显的收敛趋势，提升了服务质量，而每周的告警汇总统计可以说明近一周的系统稳定性。