兴盛优选前端面试「监控怎么放大其中一个」

今天给大家普及一下兴盛优选前端面试「监控怎么放大其中一个」相关知识，最近很多在问兴盛优选前端面试「监控怎么放大其中一个」，希望能帮助到您。

1.产品简介

棱镜(Prism)是体验技术部前端效能团队自研的前端监控系统，整个系统自上到下都是由效能团队自主研发，为公司提供针对前端产品的性能、品质的评估以及错误报警和自定义埋点的服务，目前已经接入公司 100 多个项目。

2.背景

之前在网上看到过二组这样有趣的数据，国外做了一项关于网页延迟对收益的影响的实验。

用户忍耐度

诚然，任何互联网公司开始着手使用甚至自研前端监控系统，无外乎都是体量越来越大，不能简单用肉眼以及主观判断去定位线上发生的一系列问题，反之，需要大量的数据去定位和论证错误的原因以及运营决策的考究。自社区电商被人关注之后，大厂纷纷入局，我司一直保持一往无前的趋势。无论是开发还是产品、运营对数据的要求也是日益提高。

一般来说，一开始一个产品的设计和开发，多多少少带有"个人"的主观意向，而每个人的想法都是不一样，然而当公司达到一定体量时，产品的迭代和上线就不能仅仅带有个人的"偏见"去完成。任何无数据支持的决策，都难以让人安心，因为人是带有偏见的，但是数据永远不会骗人。公司的核心产品迭代，每一个重要决策都是建立在完善的 AB Testing 与小流量机制。与此同时，对于开发者而言，前端的线上问题很难定位，因为它发生于用户的一系列操作之后。错误的原因可能源于机型、网络环境、接口请求、复杂的操作行为等等，棱镜正是致力于解决上述问题而产生的一个产品。

3.探索过程

3.1 难题

对于纯前端的前端监控系统的开发，对于前端工程师来说并不是什么难事，但是要承接整个系统的全链路开发，其中包括前端 Sdk 数据采集、数据清洗、数据聚合与计算、前端可视化等等一系列开发链路，并非一件简单的事情。所以，棱镜的研发过程并不是一蹴而成的，起初我们遇到许多令人头疼的难题，例如:

多端 SDK 的开发以及数据格式统一

跨技术领域的探索与学习

高并发、高吞吐量的数据处理

机器和集群的稳定维护和容灾措施

......

可能对于许多专精于大数据处理的大佬来说，我们遇到的问题可能是不值一提，但是对于我们从未涉足大数据领域的前端工程师来讲，要学习的东西多于牛毛，资源的协调和统筹对于我们而言也是一种挑战。

3.2 解决措施

3.2.1 数据采集

目前我们采用的是带有一定侵入性的方式采集数据，即前端采集 SDK。采集的数据维度也很丰富，其中Web端包括停留时长、接口错误(请求体、返回体、httpCode)、页面错误等等，App端包括设备信息、网络信息、版本信息、手机系统、接口错误等，Wx端的数据维度就更为丰富，这里就不一一展开了。

大前端效能团队提供了四端的Sdk，分别是小程序SDK、AppSDK、WebSDK，ServiceSDK，基本上涵盖了公司所有端的产品，效能团队安排不同的人持续迭代不同技术栈的前端 SDK。前端接入 SDK 流程也相对简单，这里拿 WebSDK 举例：

前端工程师与后端交流后，将接口出错的逻辑配置上报的方法中，即可上报错误数据，同时性能数据无需配置，WebSDK 会自动采集性能数据。当然，前面二种数据只是棱镜入门级数据。开发者也可以根据自己业务逻辑进行自定义埋点，棱镜也会接收自定义事件的数据。

3.2.2 源数据接收入库

前端收集的数据会按照 SDK 规定的数据格式统一进入我们的接收服务，接收服务是由Nodejs搭建的多节点服务集群，源数据会由 CLB 来控制流量，分别进入不同节点进行处理和脏数据过滤。然后，接收服务会将处理好的源数据随机写入到 Kafka 的不同topic的不同分区中，Kafka 起到了消息队列的作用，扮演着一个数据承接的"中间商"的角色。前段时间，在年前一系列活动的加持下，数据量爆炸式增加，但是接收服务稳定地经受住了考验，服务与接口无宕机的情况。

3.2.3 数据清洗

相较于前面二步，数据清洗的方案一直在变化，我们也是处于一种不断在探索和学习的过程。目前我们采用的是Kafka Flink Clickhouse的方案，也是目前探索以来，摸爬滚打出的效果最佳的一种方案。其实一开始，数据清洗这一块并不是由前端团队负责，起初是由后端小伙伴帮忙着做的，采用的也是 Spark 来清洗源数据，后来又重构了一版 Flink(Scala版本)清洗服务，但是由于数据量和业务需求的激增、跨部门之间精力的损耗，一直都是收效甚微。我们一度也是将之前的方案承接过来，对技术方案和代码进行不断的优化，在吸收前辈成功经验和结合当前业务场景，在不断扩充人员资源和技术拓展学习的基础上，棱镜数据清洗这部分，终于收到不错的回报。下面是我们几种探索过的方案的一些对比，对于我们棱镜团队而言，失败也是我们宝贵的一种经历。

ES 之前一直都是我们主用技术栈，数据的查询和指标数据的聚合都使用到了 ES，在前期，使用效果都是有体感的，但是后面，公司体量越来越大，数据量也随之越来越大。查询和聚合效率一直在直线下降，虽然我们之前也对 ES 进行不同方式的探索，比如通过定时脚本进行离线计算等等，但是都只解决了部分问题，随着业务的需求的不断变化，ES 已经难以支撑当时的业务。诚然，ES 是一个功能强大的搜索引擎，它对日志和数据的检索是非常强的，数据计算和聚合并不是它的强项。替换成 Clickhouse 是棱镜发展和扩充的必然趋势。

3.2.4 后端服务&前端可视化&报警服务

"车到山前必有路，船到桥头自然直"。翻越了前面几座大山后，终于来到了我们效能团队专精的部门。棱镜的后端服务使用 Nodejs 来进行开发，目前已经提供 40个指标数据，20 个 openApi，其中包括应用的日活、月活、接口性能、页面性能、自定义数据、页面和接口错误(错误机型、错误版本、网络情况、httpCode......)等等，同时我们会将数据用图形、图表直观的展示在棱镜平台上，并一直保持对数据维度的扩充和交互上的优化，让使用者更加简单地获取到有用的信息。下面是一些棱镜平台上的图表展示：

棱镜平台——小程序健康度

棱镜平台——优选优咪健康度

棱镜平台——青牛系统健康度

网格站3.0机型分布

用户端小程序手机系统分布

自定义事件

用户行为流

报警服务依托于企业微信的机器人，通过在棱镜平台配置机器人的 webhook 地址和自定义报警规则(最大影响用户数、最大错误数、最大报警时间、最小报警时间)。接入棱镜的应用一旦满足报警阀值，企业微信机器人就会发送通知，同时，通过点击通知卡片可以看到错误详情，帮助开发者快速定位线上问题。

机器人配置

企业微信群

哨兵详情页

3.2.5 整体架构&机器与集群的维护

棱镜平台整个开发链路相当比较长，衍生出的服务和机器集群也比较多，如何做好机器、集群、服务的维护，如何做到服务可靠性、可维护性、高可用性也是我们面临过的难题。我们团队参考了行业比较成熟一种监控服务的方案：Alertmanager Promethues Grafana Nodejs 企业微信机器人。在各个服务上安装抓取性能数据的SDK，统一汇总在 Promethues 上，通过官方提供报表脚本，呈现在Grafana的表盘上，例如Kafka的top是否消费延时了、内存是不是不够用了、CPU 是不是被吃满了，我们都可以一目了然。同时，一旦服务宕机了，Promethues就会按照我们预先设置报警阀值，触发我们的报警接口，机器宕机的情况就会发送到我们企业微信群，然后我们的异常重启的脚本也会相应被触发，将服务重启。

目前，我们主要也借助了公司内部产品——度量平台，我们将机器的性能消耗情况和服务运行情况全部在配置在度量平台上，定期会观测机器和服务的运行，争取贯彻研发方针——降本增效。我们则是将精力投入到代码上的优化和数据维度的扩充上。下面是我们监控的一些截图：

度量平台

至此，棱镜的整个开发链路已经完成了，回顾整个研发过程，任何一个部分都是不可替代，正是攻克一个又一个难题，才有了现在这个完整的自研的前端监控平台。这里附上一张棱镜的整体架构图：

棱镜技术架构图

4.棱镜数据能力的输出

4.1 与A/B实验(Picasso)相辅相成

Picasso 是我们大前端效能团队另一个重要产品，即全流程自动A/B实验平台。其中这个平台的数据能力全部依附于棱镜平台的输出，同时，棱镜平台的数据维度和数据扩展能力也因为 Picasso 的存在大放异彩。正如我开头所说的，任务人都是带有自己的"偏见"和强烈的主观色彩的，唯独数据是不会骗人的。公司的核心产品迭代，每一个重要决策都是建立在完善的 AB Testing 与小流量机制上的，自 Picasso 项目成立以来，效能团队调动组内各个部分的人力资源，在数月之内，完成了数据采集端、服务端、数据端、前端UI的快速迭代。目前 Picasso 已经承接了 C端用户小程序数个关于重大营销活动的A/B实验，反响热烈。后续也是有计划接入App端、H5端的A/B实验。值得一说的是，在年前 C端各种营销活动的加持下，数据量爆炸式激增，棱镜平台稳定地协助 Picasso支撑了A/B实验。下面是最近几次A/B实验部分实验报告。

Picasso——实验报告1

Picasso——实验报告2

4.2 跨部门数据合作

4.2.1 仿真平台的数据合作

棱镜平台提供对外的数据输出能力，通过openApi的方式将数据输送给业务方。

仿真平台是物流平台测试线自研的一个从线上线下采集流量并录制，快速生成流量回放脚本并回放（回归验证）的平台，主要用于单接口自动化，流量回放，目前已在物流平台线推广使用。其中，部分数据是依托于棱镜的数据接口实现的。棱镜将业务线上产品中的接口调用情况进行聚合计算和分析，提供接口入参、返回体、Header、错误响应码等接口数据维度给到测试人员，测试的小伙伴将棱镜提供的数据运用在他们的业务中，促进整条业务线上产品的有效迭代和优化。下面测试同学提供的一些截图：

度量平台

4.2.2 自定义数据推广与运用

现在已有20 个产品接入自定义事件，其中推广力度和业务方使用粒度最广就是优选优咪的运营和仓库的一些App，在优选优咪的全国推广中，优咪的运营同学基本上将对比棱镜的数据作为工作的日常，数据维度需求也一直处于不断更新和迭代。同时，仓库的Web应用和一些分拣App也会通过接入棱镜的埋点，产品通过棱镜的数据来衡量员工的实际操作的侧重点和一些操作方式的对比，用于后续的产品迭代和优化的依据，下图是一些数据截图：

网格站埋点数据

优咪干饭人埋点数据

5.未来规划

目前棱镜前端监控平台其实在推广面已经覆盖了前端90%的项目，大家也已经形成了产品应该接入棱镜的一种意识。在这种现状下，对于我们棱镜团队而言，更是一种责任和挑战。我们现在提供的功能和数据维度其实已经很多，但是还是存在很多细节上和交互上的不足，这些也是我们急需要去解决和提升的地方。正所谓"天下难事，必作于易 天下大事 必作于细"。市面上其实也很多成熟的监控平台，像神策、Bugly、友盟、Sentry等等，棱镜在开发的过程中，一直在研究和学习优秀的同行产品，慢慢在拉进距离。

同时，我们效能团队一直也是忌讳闭门造车的行为，棱镜一直将跨部门、跨平台合作作为努力的方向，服务对象不仅仅局限在大前端部门。同时，我们也是一直尝试使用兄弟部门的优秀产品。例如：2021下半年我们将棱镜线上全链路后端服务全部依托于琉璃塔打包发布，简化了我们的发版流程，极大提升了我们的开发效率；uat全部服务迁移到星斗云，减少了我们的维护成本。在之后的规划中，我们计划将棱镜数据这一端的服务托管在公司的数仓平台，我们则是投入更多精力用来优化交互，深入对数据维度的研发和考究。毕竟，闻道有先后，术业有专攻，如是而已。

棱镜作为前端监控平台，身上肩负着对接入产品洞察服务性能的责任和规避风险的义务。同时，一味地追求数据的广度是不可以取的，应该加强对数据深度挖掘。应该结合公司业务场景，站在开发者的角度、站在产品的角度、站在仓库员工的角度，多方位去思考和衡量产品的有效迭代，为开发者提效。最后借用屈原的一句名言来结束此次的分享。"路漫漫其修远兮，吾将上下而求索"，与君共勉。