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

原创

衡生

修改于 2020-05-14 16:30:07

3.3K1

修改于 2020-05-14 16:30:07

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

一、我们遇到的挑战

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

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

二、我们如何来应对

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

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

2.2 监控工具

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

2.2.1 质量看板

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

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

2.2.2 全链路日志

全链路是在线教育部开发的日志收集系统，在机器上收集并解析日志，并将日志汇总后由基于Kibana构建的全链路日志进行展示和查询。除Nginx接入层外，其他服务都采用以下流程上报日志，考虑到流量剧增后日志量过大导致ES查询速度慢的情况，所以按一定比例抽样保存到ES中，提供给全链路日志系统查询。

2.2.3 Moniter

作为实时监控与统计告警管理系统，Monitor提供了CPU，内存，硬盘，网卡已以及业务自定义的监控功能，可以方便的管理告警属性以及查看统计视图。基于Moniter汇总的核心模块监控表和值班全视图能够全面的掌握机器运行状况。

2.2.4 网管系统

网管系统主要针对计算、网络、存储等机器指标进行监控和告警。通过部署在腾讯各台服务器上的Agent监控程序实现数据采集和上报，可以监控并上报服务器自身的各种性能数据，包括CPU使用率、内存使用量、网卡流量等，还提供了API用于接收业务代码发起的上报数据，从而实现用户自定义上报功能。

2.2.5 云监控

云监控包括站点、服务、主机、日志及自定义的监控，覆盖了业务应用、缓存、数据库等几乎所有云上场景。目前课堂业务层主要使用哈勃来查看服务成功率，在线数据层主要使用云监控查看云上TDSQL、Redis各项指标，其中CDB监控可以作为业务开发和CDB运维人员的数据库辅助监控工具，通过监控视图中的各项指标掌控CDB的情况，快速判断故障点，提出解决方案。常用的关注指标有连接数、内存使用率、CPU使用率、主备同步、慢查询数等，结合质量看板的数据层监控，能全面掌握数据层运行状态。

2.3 反馈、告警、值班三管齐下

2.3.1 反馈

反馈主要分为智能、人工两种反馈方式，前者主要是指用户反馈平台ifeedback，通过机器人反馈到指定企业微信群，后者是指在外部拉的各种微信群、QQ群，重要的问题也会有专项的企业微信群。

智能反馈中的用户反馈平台，是公司一套成熟的用户反馈统计分析和智能反馈系统，提供了自动的关键词组合统计，支持跨天的快速搜索、属性分布统计和趋势图分析，其中智能反馈报警系统，能够在较低阈值情况下检测出问题，有效控制误报。
人工反馈也是很重要的一种方式，毕竟很多问题场景下不会产生能够进行智能反馈的数据，譬如学校发课排课、老师调整课表等等。
- 志愿者们成立无数的学校专项反馈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等域。值班同学还需要关注业务、基础指标的告警群，出现告警时先自己排查定位，业务告警需分析下游系统、可能原因等，无法明确的问题推动相关同学进行处理，最终得出明确的解决方案，譬如发布优化、调高阈值、屏蔽告警、继续观察等，记录告警汇总文档，每日汇总同步并持续跟进，便于后续定位和每周汇总。
业务告警基本处理流程

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

SRE（网站可靠性工程）是目前比较流行的网站可靠性理论，课堂基于目前监控体系逐步摸索出SRE稳定性保障的最佳实践，因为超出了本文的论述范畴，不再赘述。

三、我们未来的规划

3.1 工具优化

质量全景看板目前没有统一和标准的监控反映整站质量状况，且存在系统繁多、告警单一、链路串不通、学习成本高等诸多问题。理想的服务治理平台应该是可以查看全景，能在变更提供参考，及时通过企业微信群告警，迅速定位具体端和链路，新人能快速上手，且能明确展示各模块的质量短板。
云监控目前课堂仅使用少量云监控的功能，后续可以增加云监控的使用，譬如基础监控Barad（包括主机、服务监控）、自定义监控、日志监控、云拨测等，根据不同角色需求进行选择。
监控OTeam 目前公司成立了一些监控相关OTeam，譬如智研监控、TRACE、prometheusPlus监控平台、服务器硬件监控等，后续可以根据业务特点选择性地使用。

3.2 效果优化

跟进自动化目前业务和基础指标告警都需要每日值班人来推动和记录，需优化为告警时自动提单，在企业微信群群里自动@负责人，严重时短信、电话通知，每天发送告警总结，每周发送告警统计汇总邮件，这样能释放人力，提高效率，提高准确度。
分析自动化目前监控和告警都需要运维或开发来分析，但完善的监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户进行某种操作，这样才能进一步释放人力，提升系统稳定性，譬如Netflix仅个位数的SRE就支持了190个国家、数亿用户、数万微服务实例业务规模的监控和运维。
数据可视化作为监控的刚需，数据可视化有了基本的功能支持，但需要实现更高级的数据可视化，更好地展示业务效果，提供更直观的业务参考，具体效果可以参考新冠疫情、抖音直播间的展示展示效果。
可视化效果1

可视化效果2

3.3 架构优化

故障模拟和混沌工程考虑到监控告警和故障处理都是事后的响应与被动的应对，通过引入故障模拟、混沌工程，故障模拟以某种预想的方式破坏系统，而混沌工程采用探索式的研究实验，都可以发现生产环境中的各种风险和脆弱环节，不断提高系统弹性，其中就涉及到监控告警体系的定制化改造。
可观测性建设监控和告警告诉我们系统的哪些部分是有问题的，可观测性告诉我们那些部分为什么不工作了。通过寻找系统的一些比较饱满的信号量，便于我们对系统有充分的了解，传统的运维有告警、概况，但当出现未知问题时就需要研发人员去剖析更深层次的错误信息排错，此时就会涉及到排错、剖析、依赖分析等环节。可观测性需要打通健康检查、指标、日志和链路追踪之间的关联，提供成本低的追踪埋点，构造友好的浏览查询体验、保证数据读写的高可靠，完善Log日志、Metric指标和Tracing追踪之间的易用性和有效性。
可观测性的三根支柱