前端性能监控最佳实践原创

就不好意思啊，这个我们前两期呃，在直播过程当中发现呢，之前的泡面质量有点儿问题，所以呢，这次我们选了一个新的通道，希望可以提升一下我们泡面质量，但是呢，可能呃，我们下午室内的时候没有没在在测试环境当中是没有问题，但是晚上到标准环境的时候呢，还是多多少少出了一些差错，这个先跟大家说，不好意思，耽误大家的时间了，那我做一下自我介绍啊，我是石琪，呃之前大家应该也参与过这个腾讯云一体化监控解决方案的其他课程，前面呢由我同事小朋友来有课，所以呢，这个我我们这次呢是相当于是个系列的第三节课，那我们这次的重点呢，是做这个前端性能监控的这样一个产品的介绍啊，介介绍一下最佳实验啊，我是我我叫石奇，然后是腾讯云的监控的建构师，今天呢，我也请到了这个我们的产品嘉宾啊李震，呃，他呢会呃在实阶段啊，会在实时的时候补充一些部们腾讯内部对于I产品的一个实用情况。

好，那耽误时间比较多了，那我其他的就不多说，我们从这开始，那这次呢，我们主要是有五个方面想跟大家一起探讨，第一个呢是说我们做这个，我们要做前端后这个产品吧，那我们对前前后的理解，第二个呢，说一下我们方案，第三个呢，说一下我们方的优势，第四个呢讲呃，讲一下我们客户的案例，还有一个我们全相当于是我们监控里边的增量服务啊，再给大家回顾一下这的产品。那第一个呢，其实是我们说对于监控一个理解，那说到这个理解，其实我先就做一个事情，可能都是这样，我们先想一下这个做这事情是不是有什么必要性，那其实呢，我们觉得前端监控其实是一个容易被进估的重要环节啊，为什么呢？因为可能大家经在都知道，哎后端这个有计划呀，哎各各种各样的这个比如K8S啊，各种各样的框架就起来了，那其实在后端有很多的微服务，大家呢，可能把这个重心啊放在这个后端上，这些微服务的调用啊，这个托福的梳理啊，那有当然这个后端的确很重要的，那我们也想问一下儿，前端是不是不重要，那如果要是说前端它的重要性体现在哪些方面，我们这放相关问题，比如说咱们这个平台，这个综合性的平台，那某一个地区访问平台，放咱们平台的时候，发现有些信息没有下载出来，这个在这种情况下，我们如何的主动去发现这个问题，而不是等客户，不是被动的等客户告诉我们啊，我们这块，我们这个我这我这个机器出问题了。

赢不了了。啊，这个时候呢，反馈人多了，可能消发越好，可能区域多的问题，那那第二个呢，比如说用户访问你平台这个点击按钮没有反应，那尤其是呃，这个可能比较急的人啊，想要进入下一个环节，下一个环节，但是这安全顶了没有反应，那这个在这种情况下，我们现在人员怎么去发现有些人他真的是非常着急，真的是因为平台的功能阻止了他的一些行为啊，这个对给他的这个体验，他的非常非常受到影响啊，这个体验非常不好。那第三个呢，就是说，呃，当后台我们看到有一有数据已经请求到数据了，那找回呢，是找回了错误信息，这个我们也知道了，一个找回的是错误信息，那我们也知道这个反馈错误信息影响了哪些客户呢？那这个影响客户肯定是在这个前端用户，呃，他们登录的时候啊，我们对他的一有一这样的影响范围，那这些我们怎么知道，那其实。

如果我们答不出来这三个问题，其实我们就知道我们的平台还是需要做一些更好的观测性，那我们不能漏掉这个重要的环节，就是前面监控。同样的，呃，前面这三个问题是从从质量角度来说，那从性能方面呢，我们也有这种统计数据啊，这统计。

其他的分发商有商工商出了点问题，再给我们很钟时间，应该先说一下价格用了没有。可以不喝豆腐吗？请继续。好，那我们这个前端监控的这个目的，我们也讲刚才说的一句话，我们再展开出来，那其实是呢，我们对于问题不障的个及时发现，那同时呢，我们希望借助前端监控帮助我们去把这个性能不断的做优化，诶那就希望它作为我们的一个性能优化的智能功能。

呃，大家还是稍的很强的。我这个声音好像还确确实实出了点问题。这次可以让大家比较清晰的看到电脑的画面了，但是声音呢，可能这个这个方面我们还需要再加加强一下啊。好，那第三个呢，其实说呃，我们平台不只是说要几个问题故障，不不只是呃需要做一些性能的优化，其实我们也希望对于用户访问的时候给更友好的界面，那比如说我们有一些交互设计师，比如说我们有一些这个啊，我们说说说是这个logo分析，其实为了是我们做一个数据平台的优化，那这个前端监控这个产品呢，其实是可以作为这个前端优化的数据来源，这。

环各个环节优化的一个数据来源。那好，那如果要是说我们啊，知道这个相端健货的重要意义了，我们也知道我们呃想要做这个什么样儿的产品了，那那我们想下一步儿项目是，哎，我们如果要做的话，可能遇到你些挑战，这个挑战我们是不是已经想明白了，我们这块儿呢，总结了三遍，比如说呢，在机场监测啊，因为我们前端嘛，前端的用户环境是非常复杂的啊，比如说不同。的设备，不同的导络，不同的浏览器，通过电脑啊，甚至不同的运营商里，哎，他们这个差异化非常非常的多，那这样差异化导差异化比较多，会导致呢，我们这个有什么问题出现是非常困难的，不可能是说找到一个完全一样的这产这个用户在我去做一次访问，那所以呢，在这个前场监测，在异常监测方面呢，这个是在。从环境下，复杂环境下，我们就要进不断的挑战，第二个呢，在性能体验方面，那其实是说我们。

这个相信有点时断时续啊，可能是好事多磨，好事多磨，然后在这个性能体验方面呢，我我们呢，希望是说，呃，我们不只是说一个界面啊，或者说这个界面的一个流程，我们能能够知道一个性能，其实我们在访问一个页面的时候，我们经历了很多很多的环节，那每一个环节可能都有它的耗时，都都可能会成为我们性能瓶颈，那如果我们要把这个我们性能做的更优的时候，我们肯定要把每一个环节都做到心知肚明，他们把这个数据都给量化出来，那这些这些信息呢，每一个环节的信，这个信息的抓取，那同样是我们对于性能细节方面的遇到的第二个挑战。第三个呢，就是说我们经常做的这个体验分析啊，这个APPUI做的比友好啊，是不是人性化的这个设计，那我们需要一些这个数据性支撑，比如说用户点完这个加入购物车之后，多少人选择了提交，多少人选选择收，选择收藏之后把它放入购物车里再进行个购买，那这些呢，其实综合到一个体验分析，那这个时候我们需要做一些数据量的支撑，那这个数据支撑帮助我们的设计师去不断的啊把前端的呃体验啊做到一个越来越人性化的这个方向，所以呢，这这三个点其实是我们在实践啊，前端监控的这个。

路途当中我们遇到的一些挑战，那我们认定的挑战之后，其实我们就下一步可能就要更落地一些，那落地的时候我们就要想我们从几个方面去做这个事情等方面，在四个方面，哎，性能性度观测，质量观测，多维分析和用户行为分析这四个方面，而恰好我们IM产品来腾讯的这个苹苹货产品把这四个方面所过进去了，我们在这个四个方面进行发力。那具体发力时候我们该怎么做，我们在落地的时候有一些这个时间，比如说在一个外部页面，它在加载过程当中，我们输入一个网址来发布一个页面，我们能够正常的看到这个页面，我们正常的可以进行一个按钮点击就可以看到它加载的GS等等加载的资源，那这个过程我们需要需要详细的去把它落实下来，比如说呃，首先经过这个点单词解析，再经过这个PB连接，这些网络上的四个的加载啊，请求传输到最后的资源加载等等这一系列的流程，我们都要把这梳理出来，那所以呢，这块自的一个啊，针对外部页面容的访问的时候，我们产生的一些环节，那我们在落地的时候就要把这些环节给想清楚，把这些的东西，把这些环节给炼化出来，这样呢才能。

最大化的保证我们对用户体验的一个可量化性和预知性。防止我们的访问量下降，防止我们的用户因为这些原因而导致流失。那我们实践的结果，其实我综合下来，我们前面的各种题的问题啊，我们遇到的挑战，我们在这个前上遇到的一些这个，呃，实践一些思路，那其实我们的实践结果就是我们最终的这样一个产品，哎。

现在现结构啊有啊台这个呢，就是什呢。今天要今天的这个主角，那其实我们今天这个主角呢，其实专目前来说，它专注在这个外网小程这个两端，那然后呢，我们还针对的是性能和质量这两个方面来做一个非常有利的支撑，那比如说针针对性能，我们有一个内外测速啊，接口测速，C0测速等等，质量更类型的错误，没I错误这错误等等，那我们呢，违把这个I产品无侵入式的兼。降降到我们这个前能的这个代码当中，实现一个我们监控室的监控啊，这个是我们基于真实用户的一个性能性能监控平台啊，这个产品把它的大概功能呢，大概过一下啊，因为后面呢，会结合我们平台啊，在用户测的一个实例啊，再这个实践这个使用情况进行一个拆解，那我们大概的功能就会有一个上报，有一些这个啊，就是自定义事件，我们可以把这些信息上报，还有一些错误收集，当然这个错误收集是主动的收集，还我们在SDK当中引入的SDK，其实三行代码就可引入SDK了，那这个时候其他操作都不需要做，不需要做什么操作，这个时候就自动的啊，会做一些错误收集，自动上报到平台端，然后第三个呢，我们可以做这个性能监控。

比如说手机耗时，比如说刚才我们在访问平台的时候，各个环节的耗时啊，以及我们引入了外部贝S，他对于这个性能的一个量化的三个指标，哎第四个呢，比是说我们有一个资源测速，那哪一个资源，每一个资源它耗时是多少，这个呢我们可以量化出来，还有结口测速，因为这个我们前端经常会接合很多的接口，哪一个接口可能会导致是成为我们线控瓶颈，这个时候我们要通过接口测速来进行个变化，那当然了，你任何一个监控环境都用在一个模块儿，把这智能报警，我们会通过这种智能报警的方式，让这种客户产生，让我们用户产生问题的时候，咱们平台会变被动，会主动更及时的发现用户产生的问题。

啊，我第二个部分呢，是说我们成本的我们的几决方案啊，围绕底下几个模块啊，我们针对性能分析模块，异常分析模块，日志发新模块，以及到最后的大屏模块，每个模块，其实呃，除了写我这边想介绍一下它的功能以外，我们也更能说的是这个功能在客户侧实际是怎么用的，那各位呢，可以参照自己的这个业务使用场景来判断一下这个功能啊，是不是适合您的这个业务场景啊，或者说做了一个怎样的一个适配，可以达到一个预期的人目。那比如说第一个，呃，我们在做一个多环节分析的时候，其实我们这这是这个一个功能，多环节分析是个功能，那我们要做的目的是什么呢？查找图性的瓶颈，这个就是说我们要查在查找瓶颈的这个产品下需要使用的功能啊，比如说还是前调这个例子，从DNS查询到最后的啊，到的内容传输，到最后的资源加载，那每一个环节啊，它别产生了什么样的这样一个耗时，它耗时是多少，它的手机耗时是不是大于500毫秒，是不是大于五百五百毫秒，呃，我们认为啊，首机耗时大于500毫秒，其实这个优化还是非常需要的，那这个呢，就是说针对啊各个环节，我们可以有这样一个量化的这个。

呃，化信息，那其中呢，某一个环节产生问题的时候，我们就可以针对这个环节进行一个着手把它做个fix啊，做一个做一个修复。第二个呢，是说我们这个呃性流量化的一个呃，数字化的一个依据，那我们呃是之前试用过我们IM产品的这个用户，大家都知道我们还产品有一个综合评分会告诉你，比如说当前综合评分是这个90分或者是80分，那这个综合评分其实包含两两方面，一个是质量，一个是性能啊这是两方面，那单单独针对性能这一块儿，谷歌呢，之前都提出过他们认为这个性能变化的一个标准啊，分别是这个LCP啊，还有一个CS，那我们在做这个产品的时候，也把这个他的这个标准引入进来，我们也希望啊，用户可以通过在股票的标准，对自的这个当前的个状态有一更好的认识啊，是不是处于一个啊过作的状态，比如说这个，呃，页面页面手册语音进行个互动的时候，其实就是说页面加载完，我们可以进行交互操作的时候，这个时间是不是理想啊，是不是需要我们改善。

这些呢是我们的标准，我们能建广告更好的成为我们单独去量化性能这数字化的依据。第三个呢，是说我们希望在做一个优化指引的时候，我们就希望把问题抽象出来，问题抽象的就是比前面我举了个例子，一个用户反馈这个问题，两个用户反馈的问题，很多个用户反馈的问题，他们之间是不是存在一个共性，是不是他们用了，因为用了同样的那个，比如说终端型号，比如说同样地区，比如说同样的网络，会导致他们产生这个问题啊。

能够把这些具体啊，具体个例也抽象出来一个片子问题的话，这其实就是说问题抽象，那IM产品呢，其实是在这个不同的网络，不同平台，不同RP之间都会有对应的数据统计，所以当一旦我们产生质量问题的时候，我们通可以通过这些平台，通过这些统计数据来快速的定位到我们把这个问题处理出来的结果。前面更多的是说这在这个性能上面呢，其实在这个异常，现在说说异常的时候，我们可以可能知道到底到底怎么算这个异常呢，其实我们把这个异常也做了一些分类，比如说这个呃前端的异常，包括这种出错呀，呃一点儿呆滞啊，假死或者是直接是崩溃，那这些这些情况呢，都把我们他们异常，针对这个异常，我们更希望把它做到一个可以追溯，可以定位，快速的去帮助我们开发者给解决的。

好，我我回以看一下，我们通过异常占比可以干什么，其实通过异常占比，我们在这个异常占比这块大家可以看到啊，我们统计了比如说这S错误，然会这个同比环比的这样一个数据，确实是说我们希望大家了解啊异常的变化，为什么呢？我因为我们的实际项目当中会看到我用多他们的受限于当时那个带宽，或者当时工作侧重点，他们这个异常呢，可能暂时对于影响不太大的这个异常，他们暂时不会马上解决，但是呢，如果比如比如说今天对比昨天这异常明显发生的变化，那这个时候其他就意识到不只是啊，他们可以控制那些异常在发生，可能有其他的异常，达师这个时候我们就通过这个异常的占比，通过异常占比的变化来判断出我们是不是要及时的去介入，这个就是说我们做这个异常占比变化的这样一个基因，我们希望通过数据数据对对比，数据统计，当然未来的这个aio也是这样一个方向啊，可能是先学习一下我们当前这个数据数据情况。

然后未来呢，当数据发生等风可降的时候，我们及时的借助，这对我们来说就是个预警啊，产生异常变化的时候，就是我们要格外引起注意的时候。同样在质，在质量分析这块啊，在质量检测里块，我们同样会高维分析，其实多维分析我也使用过，我们产品会知道多分去贯穿到我们每一个智能卡当中，那这个多云分析呢，也是同样包含的网络平台P机器浏览器它的版本啊，比如说我们通过一个图就可以看到，当前在我们访问我们平台的时候，哪里它这个人数最多，哪里他这个访问速度最慢啊，在什么什么样的平台下，我们个访问对我们这个平台的这个质量产生了一个影响，这个时候就是我们去位分析的视图的一个概念，包括呃，由于之前我们也发现，呃，如果要是在产生这个GS错误的时候，我在首页当中GS错误可能这个占比比较高，但通过我们看到这个GS错误排行，我们会发现GS错误呢，它其实可能更多更集中一些，也许我们解决解决掉TOP10的这GS错误，我们整个儿平台的监管度会有一个大幅的提升，比我们整个儿的GS错误率，嗯。

得到一个非常大的一个下降，这就是我们做这个G错误排行的这样一个目的。做一个具体的案例分析啊，比如说我们之前会发现，哎，我们的有有我们有用户去访问或问URL的时候啊产生了报错，哎，然后我进一步发现，哎，这个不只是一个个例，那这个呢，是在一个区域性的，是是某一个区域访论我们同一URL的时候产生了问题，那我们就要讨论，我们就要想啊，这个URL在这个区域当中有什么样的特殊性，那其实是这个URL可能在这个区域的运营商之间有很大的关系，那联系运营商，我们知道这个这个URL在运营商做了屏蔽，这样才会导致我们这一个，呃，这个区域访问这URL统一都受到个问题，受到限制，那如果要是说没有这个IM会怎么样，也许可能是说一个用户过来，我们去不停的这第八个，第二个用户过来，我们也发现这第八到了问题都都没有，甚至问题在我本地面去做复现，那通过IM能够方非常方便的知到我们把这个问题抽象出来，这不是一个个例，这不是我个用户的问。

这是一个区域性的问题，这样就帮助我们快速的去做一个定位。那前面讲的这个呃性能啊治疗，那第三个呢，其实是说我们这个页面日志查询的，其实我们要解决一个什么问题呢？解决对重现的一个依赖啊，比如说我们呃，如果出现这个日志才不够全全面的话，那用户产生什么问题，那我们最多说的情华设影是最多说了一句话是什么，呃，我们要排查一下本并没有重现，那你您您在那边我们能再再访问一次，那再访问一次，我截取下更多的信息，把这个信息获取到，那我进行一个第八，那其实我们希望把这个呃问题问题重现的这个依赖给打消掉，这样我们就有日志查询，那就是查询，我们就可以把这个我们所谓的断了线的风筝，就是问题变成了，变成了因为没有出现问题，这个问题变成了一个断线的风筝，我们希望把这个断了线的风筝，那我重新放到自己手里快速还原儿啊，通过日志快速还原。我们是把现场。

这这也是举个一个例子，因为我们平台啊，这个SDK当中会有一个字段，可以大家可以注入自己的这样一个在平台的用用UID或者UUID，那通过这个在个平台上UID，我们可以快速的知道这个用户在平台上都产生了哪些信息，那通过这个信息我们就可以还原整个他的那个事发，事发现场，他具体都做了什么样的操作代码，一个操作的时候包括什么错误，这个错误是这么引起的，同样我们也支持了S网，可以把这上传进上传。上传之后来最快的把这个问题这做做做一个定位。这这里呢，也也是一个案例啊，在IM，通过imm产品，我们把这个用户日志和开发者之间做一个更紧密的相连，那之前有用户说我这个对频繁使用有问题，那我们看一下为什么有问题，看一下他的，比如说他的来源啊，他的他的这个地域信息，它的网络信息，可的设备信息，那我们可以看到，哎，在这个图里有一个反方，那他的平台的版本比较低，那如果这个。

我们现在也定位了是因为啊版本比较低，所以才导致我们出现问题，那后边解决方案也很简单了，要不然我们对旧版本进行兼容，要不然就是啊，我们可以跟客户去去说这个版本可以升级，升级之后防控平台就就产生一个正常可以做一个正常的矛盾。同样啊，页面我们分析，那除了我们最基础的一些P配呀，UV呀，这些信息，我们也可以把一些关键的指标，一些量化用户的这个信息做好这个做好这个汇集，然后呢为为这个产品优化，使方向进行用户体验这块我们具体的看一下。

那比如说针对一个VPAPP，我做一个什么分析，那咱们平台在每天在什么阶段，嗯，这个访问量比较高，访问量比较低，一个星期的什么时候访向量比较高，访问比较低，甚至我们可以按照月的维度啊来进行一个数据统计，按照地域的维度啊，按照我们这个网络的维度，这些呢都是我说我们平台对用户，用户使用使用情况，这样你做做一个很好的这个量化，同样啊，我如果要是有单独的平台运维，可能非常需要这样的数据啊，比如说我们需要在这个我们客户需要插入广告，植入广告的时候，那我们想问一个问题，我们这个广告在哪一个页面当告嵌入最合适，那我可以看到，哎，我们平台当中有一个top top页面访告的一个排序，那这个排序其实是指引的我们不同的广告放在什么样的页面上，可以可能会产生什么样的价值，这样一个有有据可依的啊，这样一个运营活动。

那API监控这个我们做过前端开发的都是吧，我们前端啊，对于后端这个API监控，API的这个调用实在太多了，一个手序可能是几百上千个，那这个时候在API我们同样分成两个，一个是API集成，一个是API的性能这块举一个具体的例子啊，比如说我们之前在个一个一个项目上，我们看到陕来这个。API的调用成功率都一直是比较不错的，这个状态突然某一个时段开始下降，而且呢，没有没有及时的进行一个修复，这个时候如果要是在连锁到我们的报警功，其实我们可以收到报警信息了，我们就知道在这个当前的情况下，我们的API到之后率已经非常低了，已经已经在产生波动，那么就及的介入，这样呢，就不需要用户告诉我们，哎，我我们这边比如说小程序，小程序白屏了，不需要用户告诉我们，小程序白屏了，我们自然而然就感知到，这样我们可以及时的去修复，来最大化的减少我们我们这个平我们我们平台这个问题APIAPI调用问题给用户带来的一种损害啊，对对他带来了不好的影响，所以呢，这个是说我们对于API监控异常啊，这样一个一个案例。

那API呢，其实那我们在性能方面也一样会有这样的一个涉图top涉图，比如说哪些API当前请球数量最多，哪些API的性能，当前的接口速度最慢啊，以及是说我们有哪些API的4R啊这样的错误信息，那其实我们，呃按照之前也说了，可能我们不只是在前端DS，我们在后面API的问题也会有，也会有这样一个情况发生，就是会发现比如说一个有第三方的健全就经常会出现问题，那他呢，经常会。关乎到我们这个API前绪异常本里面，那我们就要对他做好一个做做更好的一个监控，比如说因为他这个经常出问题，我们就要想一个办法，如果他返回的值约定一返回值，而如果这个返回值他确实没有确确实失败的时候，我们给用户有更好的一个页面体验，这个呢就是说我们对API异常监控的这样一个应用啊，除了拿能够操作的操作适度以外，还哪些经常报错，我们也同样是希望比。

API当中要会分析这块，我们讲一下之前的这个错误监控，和这监控一样，我们可以看到API监控，比如说在哪些区域，它的这个调用时场啊，它的反应性能有多少啊，帮助我们更好的更全面的去了解数据。还有静态资源优化啊，尤其是这种这些呢，尤其是对我们这个做音视频平台的这些用户和来去作用，因为做音视频平台的这些用户们，它往往会提升第三方的资源啊，甚至它有一些很多的图片，很多的动画效果，甚至是一些这个呃，广告资源啊，甚至一些一些活动资源需要临时的加载进来，那会不会因为一些条的没有协调，导致资源易失败，这个时候就强的依赖于我们阿平台一旦啊在这个资源，资源由一个一旦在这个资源引入的时候啊，在资源加载的时候产生。

后我们也可以产生及时的报警，这样呢啊，这个我们比如说这个开头这个我们就可以及时的发现啊，不断的去优化啊，去优化这个加载加载异常加载时长啊，加载性能问题，这个是在资源优化中那个。同样资源优化方面，我们也有这一套是图，比如说哪些资源被加载的次数最多，哪些资源被加载啊。错误错误数最多，这些呢，我们都会有一个。明确的是服务，其实这个点通过我我在在PPT上展示的这些页面，大家也可以看到啊，我。呃，在这个用户U化方面，就是观注说咱们平台使用这方面我做了很大的功夫，我们希望能够最直观的让各个省呢啊知道当前的个状态啊，不需要可能我们自己再做一些复杂的二次处理，因为一旦做一些二次处理的话，我们的这个及时性是很难去做一个保证的。

这也是个多维分析啊，也是在经大学。现在资源优化的方面，我们也希望啊，通过不同的这个多多维角度来判断一下我们相关资源的一个情况。还有一个自义上报这个呢，其实是，呃，之前我解到啊，我们很多平台，我们很多用户都已经使用了这平台，但是呢，他们在这个自定义上报这一块呢，他第一有些人可能就发现这个功能，第二个呢，可能用了这个功能呢，还不是很。还不确定它好用，还我还不是确定怎么怎么样才能用的最好，嗯，所以呢，这块文章就把它弄出来了，那其实呃，我因为我们有一些业务数据在，他不属于性目数据，可能也不属于这个质量问题，那这个时候呢，我就需要我们去做一些自定义上报，所以I药人才呢，为了支持这个场景，我们就把这个包。

说白了，在这个自定义上报的时候呢，我们就可以直接到自己的这个呃，一般的内容，我们事件名称，事件的内容，然后事件的内容呢，我们可以通过这查询当中，你看我们些详细的信息，那自定义这块呢，除了自定义，自定义的信息上报也包含三个部分，有一个自定义的日志啊，自义的事件这本书了，另外呢，也有S定义的测速啊，定义的测速呢，也支持几种方式，比如说在这个呃方法或者说我关注点前面或者是后面去加一些这个啊，我S这个时候，我们会自动就信息收集到了啊这块呢，在额外打开一点就是我们，我发现呢，自用户在使用我们的时候，也经常会遇到这些问题，就是他处自定义上报文的这种内容，它是属于呃，我们比如后续到一些信息之后，用户想做一些二次处理，二次处理之后再做一次上报，那这个呢，我们我们有也有这样一个接口啊，通过调用我们这个比方开方法，我们就可以实现在错误或者相关信息上报到啊。

上平台之前我们去做一些二次处理，处理完之后把这信息上报啊，甚至有些有些信息咱们这个没有必要上报，那在比方你看接口也是同样可以去把它个呃停掉的，这个呢，就是说我们呃IM也会把这个大家自定义信息呃。教育不断的方向发展啊。好，这个是自定相报的这样这样一个功能啊，这个其实更多的是弥补一些。呃，之前呢，对于担心文化在质量当中没有涵盖的方面啊。同样，这还有一个复化查询，这个复化查询也是我心最出功。那这个这个功能呢，大家可以做一个大概的解释啊，比如说呢啊，我们把这个。前面有自定义事件，我们要有这个自定义事件名称，那我们可以把这个自定义事件，比如说如果们这个自定义，呃，事件一，我们我们说点点击到一个按钮，然后因为是的二，我可以可以说点击一个按钮，按钮二，那这块呢，我可以做一个公式啊公式比如就是A1除以一二，这样我们知道了什么呢？我们知到有哪些用户把只是点击了按钮一啊，没有点一按钮二，那这个呢，其实更多的是希望我们我们也希望保存着对于业务分析的这样一个功作。

啊，比如说我们做一些公共运营，做一些公共行为分析的时候，该怎么样通过这个部门。么做啊，这个节点，比如说AR，我们就可以用添加形成我们最后最终的公式，这个公式我们也可以，我们也是一种可视化的方式来进行对接的，可以感兴趣了吗？呃，或者说我么进行度上报这块呢，额外的要去接些额外的行大项功能付款20，这个大家之前如果了解的话，也可以在了解一下。还有这个呃，北华大学的一个国航大板，国航看板，这个也是呢，我们呃最近在IM平台上新增的，那么在这个数据总览里的，在数据览的页面儿里面会有这样儿一个单独的一个箭头，点开这个箭头儿，我们一个数据览屏统就出来了，那这个呢，就当做我那个呃互网的看板，呃很多呃，我们很多客户在这个重要的一些活动引擎会有一些互航。

说我们之前也有参加那个双11的过航呀，广藏会的护航呀，啊这些我护航的这个这个啊过的时候我们要看你的数据，我们在这里直接的反映。大家直接把这个头发。啊，坚持完一半。在不。啊，那第三个部分呢，说一下我们方的一个优势啊，方案的优势啊，这边比如说第一个我们是都可拿来支持，我们支持大端啊，我们支持小程序，包括这个微信上QQ，我们来支持一些框架等等，那这个时候我们把这个SDK啊嵌入进去之后，这个数据就会自动的上传到我这个。

腾讯云呢啊，其实呃，如果之前用过用我们肯定可能大家也也了解，可能包含了部分，还有过我们这个监控的部分，还有一些我们日志CRRS啊，C日志现在是通过跟crs进行打通啊，进行进行个存储，那后来呢，我们可以在这个混和可以行间的常直观的看到我们这个产品一个。这个制体日志行启，还有第二个呢，就是我们操作这个操作的这个结构成本非常低的啊，其实两三方代码就可以解决我们绝大多数问题，那最基础的客户呢，就是通过三个代码引用SDK，引入完SDK之后，这个SDK就会自动的去监控啊，一些错误信息，一些这用的信息啊，一些这个信息，那这些信息都可以直接到我们这里啊。呃，控制在我们控制台上可能也是就直接的看到过，当然了，如果我们想做一些自定义测速啊，自定义的事件啊，也可以在后面进行展开啊，同样我们也有这个API，如果有一些这个数据，我们想做一些二次的这个利用啊，比如说首页上我们我们要想要看一下这个API的成功率，我们展示的首页什么影想到这个数据，也可以给我，我们这个I平台的API open API啊，通过这个open API这个获取数据啊，这也是非常方便的。

然后第三个呢，其实是我在这整个呃介绍PPT过程中啊，也也说过了啊，其实我们在努力方向呢，也是说我们一方面希望我们分析的这个信息更加全面，第二个呢，就是说我们界面做的更加友好，就是这个界面规程友好，除了是说这个美观以外，其实我们更我们更希望的是说我们提炼去提炼好啊，大家所需要的这些信息，大家不需要再做更多的这个操作就可以。就可以把这个呃，我们的数据可以直观的呈现出来，换句话说，如果有一天的话，咱们打开这个I1平台，呃，我们在首页上我们的。

我们的测大完显示的数据，就是大家第一上来就要看到这些数据，那这个呢，其实是说我们不止做到100就啊，那我们希望希望说的是一个更更加统一化的，更加的满足我们，呃，这个日常的需要的这样一个界面啊，这个呢，其实说我们平台的三个优势。还每个智能报警功能啊，在这个智能报警的前面也说了，我们通过智能报警功能，我们引入在通过智能报警功能，我们可以变被动为主动，不需要用户，直到用户给我们反馈多的一些信息，用览异常的时候，我们才进行一个介入，我们才进行bug，因为那样太慢了，那如果产生有这个有这种智能管理种模块，我们可以更早的去介入到这个城市当中啊，一旦指标发生变化，发生抖动，我们就可以介入，看一下是不是对管些用户产生的影响，这样。

用户体验，还对维护整体用户的体验会有很大的提升。第四部分呢，注重设计下个案例，这个图大家可以看一下，这个呢是说我们呃做了一个我们之前在某一次合过程当中，其实做的这样一个，呃全国性的一个项目，它全国有各种各种各样的一个平台，每一个平台呢，它会有自己的一个判断，比如说是不是异常，是不是一是不是正常，那这一些呢，会取决于我们I平台给平台的分数，他会自己再做一次这个呃定自己再做一次这个定义，然后呃这个这个这个数据拉取是从们这个I平台直接用的。我们API啊进行挖取了，这块也写了，其实就是全国的健康款项目啊，目前全国的健康款项目绝大多数都已经使用爱平台在做保驾护航了啊，这个大家可以了解到我。还有呢，这个是一个直播平台，这个直播平台呢，他使用我们还有他的原因呢，就是说前面前面说了，他的第三方资源特别多，他经常做一些前端上面改动啊，引入一些活动啊，引些活动页面啊，啊加入方的广告呀，这些信息都没有，那这个时候啊，通过爱他要做的是什么事呢？他会拿错误啊对到二点公斯错误，这个异常做一些监控，他同样的做一些这个后端API告警，这些呢，就是说在我们直播平台当中，它额外商业静常资源的加载，在这个静态资资源加载产生问题，产生异常的时候啊，它的成功率，它的加载时长，它也是额外关注。

那么一旦这个超出了他可以承受的这个范围，就要及时的产生这个IIM报警信息。这是我们这个合作客户啊，当然我们合作的客户也不止这些，目前在这个整个呃呃，小程序和外端啊，都有非常广泛的个客户。那后面呢，我们这个呃，全链路监控其实是更多的啊去啊。回顾一下我们整边腾讯些功能这样一些这个产品啊，前端的这个构造产品啊，今天重点讲到这个IM产品，后面呢，还会有同事去介绍一下这个APM产品啊，姆搜的服务，还有移动云云技术监控啊，这对我们这云产点的这个。

在脸上水破啊这些的这个监控。啊这块啊给大家还还要让大家额外注意的是，目前我们正在举办这个前端性的优化大赛，而且在火烧报名当中啊，目前也是在报名起阶段，大家如果要是感兴趣的话，把可以扫描屏幕二维码，直接进行一个啊报名啊。包后的讲解这一块给到大家，大家可以扫这个二维码进行这个活动报啊。好，今天大概讲的内容就是这些比较快的，我们给大家去做了一下这个IM产品，他的一个，呃，历史啊，他他的一个他的一个我们设计的初衷，然后用户对功能上来说是怎么去使用的，大家如果有问题呢，可以线上提，也可以扫扫成现在这个二维码进入到我们。

这个群里有，有了问题大家做解答。能回回答的过来吗？如果还有时间的话，我们尽量尽量尽量给大家解决大家的问题，如果如果要是时间比较久的话，尝试起来一部分，后面有些问题可以统一收集，再统一回复。

好，我看一下大家的问题哈。从哪里开始？好好PPT资，PPT资源的话，我们这边后续处理一下啊，然后可以配一个公开版下。然后我先把这个问题拿出来。明白我明白，然后前端性能监控支持哪些指标，能达到多细的监控，这是一个挺大的问题啊，很大的问题，其实我们可以大概的看一眼这个，呃。给大家来看一下我们的这个I网平台哈，这块有大家大家认识的我们这个平台，呃，首先上面还给有我们这个充电区，本大赛时有一个报影通知我们那个报名。

然后回答您一下这个问题，就是您说支持哪些指标啊，其实我们在这个屏目当中也可以看到一些，比如说总览当中，我们没个手柄耗使它的PVUV啊的错误率，然后API的成功次数将能怎源加载这些这些信息，那后面呢，这些比如说页面性能具体呢有哪些指标，因为每我们监监控的性能指标实在是太多太多了，所以恐怕我们给您把这个指标都说一遍的话，教师也过去了，那我建议您呢，还是可以申请一下这个账号啊，我们呃可以去试用一下iOS产品，目前呢，I产品每天还有50万的这个呃，免费额度大家都可以。尝试一下。呃，好，那这个问题我先就回答到这里，然后后边如果我我这个如果要是还需要再我补充的话，我们可以在群里进行一个讨论啊，或者我们单独联系都可以。

问下，前端监控有对采集的日志做结构化处理吗？另外前端产生的数据如何？这个您指的是我们平台内部的一个统一格式化吗？那其实肯定是有的，呃，然后我们也会对它做结构化的处理呀，这是肯定的，因为我们要按照呃，比如说呃，有有这种带时序的，有有这种这个带分类的，其实我们都会把这个呃数据统一在我们就是SDK，就是您引引入我们SDK之后，在后台进行一个统计。啊。可以认为这这个分类，然后再做一个呃管状化处理，然后再进入到我们存储池当中，然后存储池我们也做了优化，这样呢可以帮助大家实现什么呢？帮大家帮大家家要做一些数据统计的时候，比如说平均数啊，比如说PP95，比如说P99啊，我们可以非常快速的把这个信息，把这些数据给计算出来，把回到前端，那我们这个在存储方面也单独是下了功夫呢啊。

呃，Get和POS的请求，呃，比如说呃，所我先呃说一下这个问题，这个问题是说get POS请求有统一的数据格式吗？比如说东西这份格式，这个呃，其实并不是啊，就是说您用什么样的格式并不重要，您在请求的时候，我们SDK会拦截一下浏览器，那这个呃，这个您的这个请求，不管只要是对后端的的请求，其实我们都是可以拦截到的啊，只要我们拦截到了，其实您用哪种方式请求？都是可以去，都是可以去识别出来的。所以这个问题回答完了。呃，下一个问题，当自定义信息写入日志里，怎么与后端的请求对比？当自定义信息写入到日志里，怎么与后边的请求做对比？我没太明白这个问题是什么意思。

当自定义信息写入到日志里，您指的是后端什么样的请求中呢？对比了。是不是可以在这个企业微信微信群里回答啊，我我同事应该是之前啊，就是同事就是T大嫂在那个微信群里，应该是给咱们这边儿做了这个回答啊。腾讯安慰M平台有免费提供。是。SDK的安全安全问题保障方式，诶这个问题问题啊，这个问题问题啊，重点说一下这个问题，呃，这个问题是说SDK的安全问题保障方式是什么，这个我理解是不是因为11月1号儿开始实行的这个个保法大家也知道了啊，对于这个信息会有一定的这个要求，呃，当然IM产品也一定会是一个遵纪守法的好产品，所以呢，那我们在默认的时候，其实对于IM产品的影响享受一下影响，就是我们之前在做这个问题定位的时候，比如说在做一个一些这个志查询的时候，我们可以看到这个用户请求的信息，用户请求的信息的一些参数，比如说我请求的信息可能会带上我的ID，那有的平台呢，可能不只带上ID，甚至是带上我的这个身份信息啊，带上我的一些个人信息吧，算是个人信息，那这个时候呢，存在为了保护一个人信息，我们是默认的话，这个参数就不带了啊。

在后台呢，我们通过一个API，呃，API detail API detail这个参数，可以把这个这个再给打开，如果打开的话呢，那我们在控制台看到前端的这个请求是带着参数的，但是默认是不难的，这个也算是我们对于各玩法的这样一个适应。

我司正在考虑阿里云的和腾讯云的，不知道优劣势是怎么样？哎，这是个很好的问题，嗯，这个这个问题首先挺尖锐，呃，然后但是我觉得这个是很好的问题，首先我建议你比较一下这个呃成本啊呃，成本这个也是我们的一个一个最大的优势，然后第二个呢，其实是说我建议您也比较一下我们的接入方式，包括各种各样的走位分析，主要成本，主要成是个可效化，那其实在同在产品，在产品方面呢，呃，那。咱们可以对比一下接入方式啊，我我觉得我们I目前的三个代码简接入方式就已经是非常的简简单化了，然后呢，后面的这个各个环节的这个这个分析，当然您说的这个产品其实我们也了解过，但是目前来看呢，呃，我们我们在多于分析方面，我们认为还是有一定的这个，呃，更更加丰富一些，有一定的这个优势。然后后边呢，呃，当然有一些也详细的这个对比信息啊，这个我们也也有个总结，呃，如果可以的话呢，你们这儿可以加一下我们这个信息，我们单独去把这个东西再展开去说啊。

怎么申请试用，申请腾讯云账号直接呃。直接在控制台。满得的追求。私信。呃，进入到控制控制台里搜，我用的是控制台点cloud，你也可以直接用cloud点，然后搜前端监控进来之后直接就可以使用，就可以每天50万的额度啊，大酬宾带你们使用。你好，老师。前端GS探针的稳定性如何保证？怎样保证不影响客户层面客户页面？这个其实是说，呃，您指的是不应用服务页面，还是说这一般我有有产生两个问题啊，让我想起来我经常客户问我的一个问题，第一个问题就是说你说我们SDK对我们服务器相当有影响，那其实大家知道也是SDK是在客户端去执行的，对于服务器的情况，对至于服务器这端基本是没有影响的啊。

呃，然后您说的这个是影响页面，其实在页面方面呢，我们没有做什么我们自主化的东西，更多的是我们依赖，比如说呃，对于一个请求的拦截，我们也是一步处理的，不会影响到您处理您自己逻辑的时效，然后对于一些一些分析，我们也是调用的浏览器的接口啊。呃，比如说您做前端开发也知道谷歌不是也有个DV兔子嘛啊，对的，自己的开发工具，调试工具，对吧？我们调用他的接口跟咱们自己的程序业务的硬件没有别的联系，所以这个不用太担心。哦，前端的哦，好感谢，这应该是之前的那个同学，他把这个问题又详细的又详细的描述一下，谢谢啊，前端的自定义信息写入到日志里，那么如何将前端的日志与后端的日志。

如何将前端的日志，后端的日志配对吗？呃，配对，我其实这个我大概理解一下您的意思啊，就是说目前今天我们说的是这个前端前后产品是IM产品，下一次应该是我们同事里边介绍的是后端监控产品，是APM产品，那如果您说的这个前端监控和后端监控的这个配对，也就是说打开，也就是打通啊，我一个串一个请求，我可以看到他在前端上都经过什么样的事情，然后在后端当中有怎样调动关系，然后把这个串起来，这个呢是我们两个产品正在打通的这一个，目前处在一个正正在打通的一个环节，我们正在做，我们正在把前的。和后端进行一个统计化，达到刚才所的目的，一个请求过来，我们把前端和后端统一处理啊。

问问大家还有什么其他问题？二维码在讨论屏幕里，欢迎大家。尽情骚扰。好呃，希望大家问过问题的，或者是这个有还有问题的都可以加一下这个群里啊，然后在后面我们在群里做更欢快更愉悦的交流啊，这个气氛更更好一点啊。然后到到时候我在群里说句话，大家有什么问题可以私信找我哈，我们可以加个咱们加个好友的。

看看大家还有什么问题，看看大概各位大佬还有什么，有没有什么指点。感感谢大家对我们这个直播的支持，今天还是出了一些问题啊，是我们今天以为安直播是我们这边的一些问题，然后感谢大家在屏幕前听咱们的呃，实习老师的这样子的一个分享，那让真的是我们在鹅场打磨了两年，真的是在内部最受欢迎的一个前端项目，所以大家如果有任何对让感兴趣的，或者是还有一些什么样的咨询，或是希望呃优化咱们自己的业务的前端监控这一块的质量啊，或者是体验啊，都欢迎进我们的群，我们所有的这个，包括咱们的主播，再加上我们的这个，呃让务的这个负责人都会在群里面帮助大家解答问题的，呃，今天就谢谢大家了，然后我们整个一体化监控系列直播还会有两期，在下周三。

还有下下周三，下周三就是会讲全链路的监控，就整个APM这一块的一个最佳时间，那呃，最后一个会是一个普罗米修斯托管的托管服务的最佳事件，那我们是有验证普罗米修斯是可以为用户节省大概65%的一个成本的，相比之间，所以呃，期待大家下一次直播和我们在一起能够讨论，谢谢，感谢大家，拜拜。