一.背景

实时监控大屏，作为大数据领域的经典应用，已经普遍存在在各大互联网公司的应用案例中，像淘宝双11的实时销量大屏、滴滴的用户地域分布等场景，那么在好未来的业务体系中，也有很多核心场景是需要通过实时大屏来进行统一监控的，此文主要介绍「未来云-业务监控」中提供的实时监控大屏解决方案；

二.关键点

整个实时大屏的建设分为技术上和产品两部分，下面列举一些项目中的关键点和难点：

1.技术上

• 海量日志的秒级实时指标计算
• 日志流量潮汐性较大时的计算保障
• 不同类型指标的存储选型

2.产品上

• 哪些业务需要实时大屏
• 哪些指标需要展示在大屏上
• 怎么去定义一个实时大屏的价值

三.技术架构

1.架构详解

• 来源层：来源层主要包括所有和目标业务相关联的核心日志信息，业务数据等，主要包括：
  • 客户端日志：用户埋点信息、行为操作、网络请求、崩溃异常等；
  • 链路日志：请求调用链路中涉及的关键步骤日志，包括DCDN、源站、服务端Trace等；
  • 业务日志：业务事件的关键日志信息，映射到关键业务行为的痕迹；
  • 业务数据：结构化的数据库中的多维度业务基础信息，例如用户、课程、订单等
• 传输层: 传输层主要依托于未来云-日志中心的采集通道，将来源层的各源数据进行统一采集分发，需要在日志中心平台上进行统一采集注册，满足采集投递的元数据规范；
• 处理层：处理层主要基于分布式实时计算引擎来进行数据处理，目前任务主要分布在Flink集群和Spark集群 :
  • Flink：流处理引擎，流式处理时延低，支持SQL，目前有on K8s 和 on Yarn 两种部署模式。
  • Spark: 批处理引擎，微批处理，对时延要求相对不高,支持 SQL，目前 on Yarn部署。
• 存储层：存储层主要支实时OLAP场景下，流量潮汐性较大的场景，经过选型，我们基于以下两类组件建设：
  • ClickHouse：面向列的DBMS，分布式架构，高效的实时数据更新，支持SQL，丰富的函数，但是不支持update和事务，场景选型时需要关注,目前代理选用chproxy，避免多分片表节点数据分布不均、读写分离、提升高可用性；
  • Redis：内存数据库，性能表现优秀，操作原子性，在秒级、毫秒级场景下可以快速支持数据读写，不支持SQL，数据建模成本略高，目前基于Twemproxy代理实现集群方案，主要作为缓存和体量较大的暴力实时数据指标请求；
• 展示层：后端服务和存储层做逻辑交互，将数据拼装，和前端进行数据交互展示，和前端交互协议主要有：
  • Http ：客户端发起，分钟级及以上的数据刷新频率，适用请求量及请求频率不高的场景；
  • Websocket：服务端推送，秒级及秒级以内的刷新频率，例如秒级销量、秒级在线人数、秒级告警推送等；

2.经验分享

• 潮汐性较大的场景下实时计算稳定性保障

  目前我们可触达的业务模式，大多数是潮汐性较大的，以网校为例，直播在线的每天的高峰主要集中在白天固定的时间段内，在没有课程的时候，日志的峰值和高峰时候相差很大，而由于各个端、服务模块频繁的版本迭代，我们对日志体量的预估无法单纯的和业务数据线性关联，这个时候可以从以下几个方向去提升计算任务的稳定性：

  1. 压测

     ​ 实时计算场景的压测和业务压测有一定的区别，在流式数据计算下，数据实时QPS，单条数据的大小，关键字段的种类，都会对计算任务的稳定造成影响，单纯的模拟规范日志发压，可能并不能真实的压出计算任务的瓶颈和问题，所以我们在压测的时候，会选用线上高峰时段的真实日志，结合任务场景，制造出合理场景下多种数据倾斜的案例去进行压测，除了在低峰期压测，我们也会在可控容量范围内，在业务高峰时候，以最小单位计算资源去进行测试高峰时期的任务表现，是否可以和压测的结果相匹配。

  2. 任务调度

     ​ 在业务流量较小的时候，我们的很多实时任务是健康的，当业务日志高峰到来的时候，往往会形成峰值交叉的情况，这个时候计算任务不能只关注逻辑，也要关注物理部署环境，我们要保证任务的网络开销最小，和上下游做好沟通，保障数据流在合理的物理机房内闭环，尽量不做过长的网络传输行为，一旦出现跨机房拉取行为，机房间的专线带宽是交叉使用的，很有可能会生成连带问题，产生更大的事故。

  3. 资源伸缩

     ​ 在压测充分以及任务部署合理的情况下，也总会有超过"预估"峰值的场景，对于这种场景，我们可以利用计算引擎层的能力来帮助解决，基于spark on Yarn的动态资源机制，我们可以实现在自身队列资源内，任务自行做资源扩充，我们也在测试基于flink on k8s 的native模式来实现动态的资源伸缩。在上述基础上，我们依然会保留一定的资源buffer给资源高峰去做冗余，不会完全依靠资源伸缩去抗住高峰，前面必要的资源扩容是不可少的。

• 不同指标的存储选型

  实时大屏会存在多种维度，多种时效的指标数据，针对不同的指标，也要有合理的存储选型：

  1. 秒级指标：ClickHouse和Redis都有足够的写入性能去支持秒级的指标，比如像秒级qps、reqTime、错误率等，但是在读取的时候，我们会进行场景区分，如果涉及到页面大量获取数据，频繁简单请求，没有复杂的统计或者维度关联的，我们会选用Redis，例如猫头鹰监控，如果是需要进行链路关联查询，复杂算法，同环比分析等操作的，我们会选择基于ClickHouse完成，这样可以利用SQL，和其自身丰富的函数支持业务需求。
  2. 分钟级+指标：分钟或者分钟以上的指标，写入频率和读取频率也不高，大多数这类指标是为了分析，我们会统一选择ClickHouse来存储，如果数据源在mysql的话，对于业务峰值写入不高的，我们直接读取业务从库获取指标，对于峰值mysql压力较高的，我们会通过实时binlog采集来进行增量计算，写入ClickHouse来进行读取。

产品思考

在大屏的产品建设上，我们也收获了很多的思考和经验，围绕第二节提到的关键点来介绍：

• 哪些业务需要实时大屏

  实时大屏有两个最重要的特点：

  ​ 首先是实时，所看到的数据都是跟随时间变化，期望用户通过大屏关注到的是最新的情况，信息和问题，所以对时效性非常敏感的业务是适合建设实时监控大屏的，比如直播课堂，在直播课期间，用户的全部体验，都集中在1-2个小时内，而这个时候，就需要快速准确的去发现问题去做出判断和操作。再比如课程续报，续报活动会有时间窗口，时间窗口开启时，会形成短暂的请求高峰，对系统形成较大的压力，出现问题直接影响用户真实的购课体验，会有流失用户的风险，那么对续报过程及质量的实时监控就是必要的。

  ​ 第二个特点是高度业务抽象和产品化，实时大屏的定位不是用来分析问题和找到问题原因的，而是快速捕捉问题和获取实时最新信息的，那么对于复杂核心的业务，所涉及到的模块，调用、业务耦合非常多，涉及到的伙伴角色也有很多的时候，那么大屏的价值就得以体现，它会快速的提升大规模作战时的协同性和工作效率，大家只需盯住自己的核心指标的异动，简洁清爽。
  基于以上的特点总结，那么满足这两个特点的业务即需要建设实时监控大屏来满足监控的需求了。

• 哪些指标需要展示在大屏上

  如果明确了一个业务需要实时监控大屏，那么我们如何去判断哪些指标应该在被摘出来，出现在大屏上呢，基于实际经验，我们有以下几个标准：

  ​ 首先是业务指标，快速了解其业务架构，从用户触达端，到服务层、组件层、资源层构建清晰的核心链路，对其进行模块拆解，把整个目标业务拆解为几个核心单元，对于业务单元，我们需要展示此业务的北极星指标，比如订单量、在线人数、消息数等，而对于技术架构单元，需要展示此单元的压力、水位线、实时质量，比如接口QPS、系统容量、SLA指标等，这样就可以把业务指标和技术指标直观的通过时间去做关联，辅助分析问题。

  ​ 其次是客诉指标，在核心的业务链路外，要考虑用户的反馈情况，比如客诉平台、用户求助平台等指标的变化，实时监控各类问题用户反馈人数的增长情况，也可以直观了解当前用户体验及质量，辅助判断问题。

  ​ 最后就是告警，对于大屏的告警设计，在告警范围上，我们控制在大屏展示的指标范围内，让用户所见即所得，需要告警的指标按照阈值划分为预警和告警，在大屏上用橙色、红色来进行区分，告警触发时，展示指标变色，同时告警模块中弹出告警留存，对于在同一时间打开大屏的所有用户，都会收到同样的告警推送，持续累加，刷新之后页面不再留存，转为后台存储。

• 怎么去定义一个实时大屏的价值

  如何去衡量一个实时大屏的价值，经过了一些业务实践落地之后，我们总结出了几个衡量指标：

  ​ 首先，是在关键时间内的活跃在线人数，比如直播高峰、续报高峰等场景，有没有用户关注，涉及到几类用户角色关注，也能直接衡量实时大屏的价值；

  ​ 其次，是能否直接或间接的帮助用户发现问题，如果出现了事故或者问题，而大屏上相关没有任何的展示和体现，那无疑这个产品是失败的，大屏应该包住该场景的"风吹草动"，替用户去盯住细节，帮助实时告警或预警，能持续的帮助用户实时发现有效问题的大屏，无疑是有价值的。

业务案例

1.网校直播课堂

网校的大班直播课堂，无疑是网校非常核心的业务场景之一，所涉及到的模块，调用也比较复杂，我们从20年寒假开始，开始网校直播课堂监控大屏的建设。

• 监控模块拆分，如下图所示

如上图，直播课堂的三驾马车，主要是直播、消息和互动，用户进入直播间拉取直播流之后，就会进行消息和互动的频繁交互场景，这三个核心单元深度影响用户在课中的体验，任何一个环境出现问题，都会导致用户体验降低，甚至是终止上课行为。链路是为了监控整个直播课堂的基础架构，从客户端请求到服务端的调用环节，通过健康地图良好的可观测性，可以快速洞察那一个模块出现问题，上下游的连带依赖影响是什么。业务模块主要是为了辅助分析观察整体确实，出勤和预估出勤可以评估当日整体上课趋势，客诉则可以直接反馈直播课堂的真实体验问题。

• 监控指标列举，主要是围绕各模块业务北极星指标和稳定性相关指标

  模块

  指标

  直播

  直播在线人数、直播场次Top排行、卡顿率、卡顿人数占比、各地域直播质量

  消息

  聊天在线人数、消息条数、到达率、消息延迟、各端聊天人数、掉线率

  互动

  临场互动热度、互动题各步骤成功率、互动题各端成功率、互动人数客户端版本分布

  链路

  业务健康地图（QPS/成功率）、接口QPS排行

  业务

  预估出勤人数、购课应到人数、客诉反馈人数

  在确定了各模块后，我们围绕各模块的场景，技术架构，和业务团队进行深度沟通合作，针对进行多维度拆解，成立多个监控专项，明确了业务北极星指标和稳定性指标。

• 大屏效果 (核心数据已脱敏)

  

2.培优续报业务

• 模块指标拆分，如下图所示
  

  如上图所示，培优续报业务，是在全国各分校进行，每个分校按照制定的续报计划在指定时间进行续报，当人数较多的分校的续报计划时间重合，就会形成续报高峰，对系统产生压力，在业务指标上，我们会展示出全国各分校当日的直播计划，让用户可以清晰看到当日哪些分校会参与续报，在续报前，会有活动直播，我们也会观测各分校参与直播的人数和直播卡顿情况，续报时，我们会基于健康地图，实时观察整体续报系统的实时压力和实时质量，当日的SLA曲线，实时接口QPS Top和RT Top，业务上会展示实时支付峰值，成功率，续报参与人次用于从业务视角看到趋势和质量。

• 大屏效果 (核心数据已脱敏)

  

未来规划

​ 目前，我们为学而思网校、学而思培优、学而思1v1等事业部的多个业务线提供了实时监控大屏的服务，并形成了围绕直播课堂、交易续报等多个核心场景的解决方案模板，可以快速支持很多业务线的大屏监控服务，在后面的工作我们会致力于两个方向：

• 提供更完备的自助化能力，把已经成熟的业务监控方案，通用出来，让用户可以自助配置大屏，通过简单的配置和拖拽实现一张大屏的组装。
• 拓展更多的业务场景，生成更多的场景解决方案，期望可以通过更多的业务实战来积累经验，生成更多的场景解决方案，赋能给相似的业务，节省成本，提高效率。

未来云-业务监控致力于提供全链路的监控解决方案，欢迎数据实时计算方向、OLAP方向，数据产品方向的老师加入我们一起通过数据为好未来业务赋能！