钉钉前端团队如何打造亿级流量的监控系统?
优采云 发布时间: 2021-05-16 00:30钉钉前端团队如何打造亿级流量的监控系统?
前言
这篇文章是从2020年4月25日开始,前端会谈第五次“前端监控”特别分享嘉宾-鼎鼎前端团队监控负责人,slashhuang的分享记录“鼎鼎前端如何设计前端实时分析和报警系统”。
开始输入文字
大家好,我是丁顶的蜡烛象,今天的主题是“丁顶前端团队如何构建1亿流量的监控系统”。
简介
首先,让我给您一个个人介绍。我于2013年毕业,并于2017年加入鼎鼎。加入鼎鼎时,我是P6。然后,通过前端监视,一些模块化代码包,效率和其他工具,我成功地获得了一些晋升机会。
关于鼎鼎的前端
自从2014年底成立以来,鼎鼎发展非常迅速,鼎鼎的前端监控也在不断发展。我们有数亿用户和数千万企业用户。前端产品包括Android,iOS,桌面,小程序,H5等,并且前端应用程序的发布还涵盖了完整版本和灰度版本。
十亿流量的挑战
对于这样一个十亿级别的平台,除了前端监视系统外,我相信许多小伙伴也有身体的感觉。为了确保整个DingTalk前端的稳定性,需要一些技术操作方法,包括某些人的条件。 。现在我们总共有100多个前端开发成员,我们的技术模块包括IM,地址簿,直播,教育,文档,硬件等,它们具有非常B-end的属性。
成就
让我首先谈谈我们的结果:100%涵盖了我们今天所有的h5和小型程序,并支持100多名前端人员的监视需求。前端监控的日志数量已达数百亿,被监控的市场数量超过100个。它可以实现一分钟感知在线问题和一分钟模糊问题的定位。在人力投资方面,它始终由两个负责人负责。在大多数情况下,我是负责整体监控情况的唯一负责人。因此,在人力投资方面,我们的成本相对较低。
上图中的两个趋势图是我们监视的主要产品结构。一个是我们的监视趋势图,另一个是我们用于承载各种业务的业务文件夹。同时,我们有一个生产环境的统一小程序,H5监控市场。
发展之路
接下来,我将讨论DingTalk的前端监视,我们如何开发系统并取得良好的结果。
考虑到很多朋友没有从事前端监视,我将首先讨论一些基本知识,以开发如何设计前端监视系统。
让我们看一下上面的代码,const创建一个对象,然后选择foot.a.b = c。您可以看到这是一段非常经典的NPE代码,这是一个空点异常,很容易出现在前端代码中。将在此处引发错误:**未捕获的TypeError:无法设置未定义的属性'b'**。
对于这样的错误,我们的前端监视系统如何在用户端发生此错误后捕获该错误,并在一分钟内找到它?让我们看一下传统方法是如何完成的:
我在这里的演示是使用image标签创建一个image标签并将其src设置为指向相应的日志服务器以发送相应的日志。
我们使用window.onerror捕获错误采集中的全局错误。然后,通过创建图像标签将捕获的错误发送到上图右侧的前端监视服务器。
上面的代码只是一个伪代码演示,我写的比较简单。
对于基于日志分析的传统监视系统,您必须首先知道日志的来源,因此,当每个日志位于前端时,我们都有一个应用程序ID 采集。让我尝试一下。将其命名为spmId,使用spmId标识日志源,然后将此日志存储到相应的监视服务器,从而完成一个非常简单的前后链接。
从日志出现采集,然后到闭环存储,这非常简单。实际上,在看到“ Weizhishu”之后,看到了这样一个简单的实现,然后丰富了日志类型,采集和存储功能更加强大,基本上,您可以构建一个相对简单的前端监视系统。
通常来说,一个简单的前端监视和分析系统需要包括以下三个维度:
在监视平台中,我们需要做一些日志存储,将监视日志提供给可视化平台服务器,并通过提供一些API服务来绘制上图。例如,第一个是接口成功率。
我认为在技术选择方面,对于许多只有一点节点或服务器端基础的前端学生来说,基本上可以制作一个简单的演示。但是,在看似功能齐全的系统中,前端监视是否存在任何问题?它可以满足具有数十亿流量的平台DingTalk的监视需求吗?
上图的左侧显示了开发人员访问前端监视的过程,包括开发阶段,测试阶段和在线阶段。在实施前端监视期间,我们要求所有开发人员在迭代启动该应用程序后至少30分钟内积极观察监视市场,并观察三个指标:
js errorperformanceapi成功率
对于我们目前由100多名前端同学组成的团队,人工成本是30分钟的100倍。同时,对于企业级产品DingTalk,我们对在线稳定性有很高的要求。在线故障的容忍度极低,因此需要对在线应用程序进行日常检查,因此人工成本很高。
从开发人员的经验来看,当开发人员检查监视时:首先,他将转到可视化分析平台以查看是否有任何错误日志。这里有一个非常重要的意义,就是我们的监视和分析平台看到的日志是“前端页面”的日志吗?
不一定。为什么?因为对于用户来说,这不只是打开前端页面,在此前端页面后面还有容器Web视图,应用程序容器,运算符等。
例如,我们的其中一个页面可以在微信,头条和丁顶的容器中打开。因此,您的采集日志源不仅是前端页面,而且还是容器Web视图。同时,我们将面对许多运营商。例如,我们经常在首页上看到一个广告,然后我们还有一些手机制造商,例如vivo,华为等,也将相关脚本插入到我们的页面中。因此,来自监视分析平台采集的日志不仅是前端日志,而且其采集的范围实际上是与前端页面相对应的用户终端日志。
通常,我们会遇到以下三种类型的干扰日志:
例如,以上是我们的在线应用之一,而js错误率可能是0. 08%。对于像丁丁这样的卷,此错误率会影响已经非常大的用户数量。
让我们看看相应的错误实际上是什么?脚本错误,未定义WeixinJSBridge,未定义toutiaoJSBridge,20 vivoNewsDetailPage,这些内容基本上可以从错误消息中判断出来,与业务错误无关。
因此,我们可以得出第一个结论,即前端监视所产生的某些错误与业务无关。这可能与许多人的看法相反。
让我们再看一个问题。左图是我们桌面的释放曲线。 DingTalk是中国乃至全球为数不多的桌面级平台之一。 DingTalk桌面基本上是一个星期或两个星期的迭代。由于桌面的前端代码采用脱机软件包的形式,因此更新和修复代码都很困难,并且对前端稳定性的要求很高。
对于我们今天的桌面终端,已经有100多个在线版本。许多版本报告的日志使用相同的应用程序ID。我们如何进行分层监控和在线流量监控?如何对不均匀性进行分层监控,以免被低流量释放监控所淹没?
这些问题在DingTalk业务场景中经常遇到。我们的监视粒度需要适应前端版本,并且受监视的日志需要支持更多维度。例如,以这两个变量为单位监视应用程序和发行版本。
让我们看看另一种情况。鼎鼎有数百个前端应用程序。每个应用程序都会报警一次,这非常夸张。基本上,每天在警报组中有500多个日志。屏幕刷新现象非常严重,并且有很多错误。这是一条长尾错误。也就是说,尽管它具有警报,但不需要进行修改等等。出现长尾错误的原因是,尽管我已解决问题,但用户可能无法完全访问最新版本。
因此,结论3是我们的监控操作的人工成本非常高。前端监视的要求不仅要报告警报,还需要您的警报既直观又实时,并支持一些短期关闭和错误。过滤等。
在阅读了上述三种情况后,让我们看一下如何设计可服务3亿卷的监视系统。
首先,我们首先定义监视设计的目标,并确定企业级前端监视需要完成的工作:一分钟感知,五分钟定位和十分钟恢复。我们将此监视系统称为2. 0系统。
对于前端监控2. 0,我们在1. 0的基础上定义了以下功能级别。
第一个是保持与实际业务的距离,降低人工成本,并使业务各方以较低的成本进行干预。同时,对于警报系统,需要快速警报和准警报,并且支持自定义警报。我们在内部设置了基线,即前端监视精度必须达到90%以上,每个人的人工成本必须减少20分钟,并且警报和市场必须能够支持自定义配置。
上图是整体监视组件的布置方案。左侧是图例。蓝色部分代表1. 0的监视部分,深绿色部分代表2. 0的新监视部分。
自定义采集
第一个在日志采集端,除了采集常规业务数据和监控数据外,它还支持自定义采集。
智能分析
分析智能增加了自定义分析的能力。
实时警报
在实时警报方面,已添加了在线1分钟警报和5分钟本地化要求。
最关键的技术实现
同样,蓝色部分是原创1. 0的系统,深绿色部分是我们的新系统。我们会发现在日志采集和日志使用者方面,我们添加了一个名为“日志双重写入”的模块。
一个日志由两个系统消耗,一个系统用于实时警报,另一个系统用于分析:
许多学生认为日志双写实际上是对非常大的系统的浪费。一个日志由两个系统消耗。实际上,DingTalk前端监视使用的是阿里非常成熟的日志使用系统和基础架构。通过日志分配快速消耗了两个通道,使分钟计算系统在整个监控系统中的布置处于前端,满足了1分钟报警的要求,这是我们在这一领域的核心技术思想。
上图中紫色虚线下方是我们的用户角度。用户触摸了两部分。第一部分是前端监视SDK,我们有H5和applet SDK,第二部分是平台,包括分析平台和警报平台。
真实案例
让我们看一个真实的案例。用户遇到了两个js错误。这两个js错误是前端的经典NPE错误。
第一次发生在iPad +百度浏览器上。第二个发生在Android +标题网页视图中。结果,我们会发现客户报告了两种错误:
实际错误:未被捕获的TypeError:无法设置未定义的属性'b'。主机注入了很多干扰信息,例如百度浏览器将注入未定义的MyAppHrefLink。
也许很多学生没有观察到它。我们仔细检查了一下。百度浏览器会注入未定义的MyAppHrefLink。标题还将注入一些标题jsBridge。
日志到达服务器后,我们首先清理日志以过滤出主机的所有干扰日志,以确保我们的警报系统是消费者实际业务的日志错误。这是*敏*感*词*区域中的第一个模块:日志清理
接下来,我们将对日志进行分组,将应用程序A的日志spmId = A和应用程序B进行分组,并对应用程序ID A和B的日志进行分组。对过滤后的日志进行实时计算。
在此步骤之后,日志流将被传输到警报索引项以进行实时计算。警报规则引擎将向与Map Reduce相对应的机器发出相关指令,以进行一些处理。
例如,JS错误失败率= JS错误日志数除以PV数。当日志的计算结果大于6%时,将发出“叮叮”组警报;当故障率大于15%时,将发出SMS警报。
叮叮前端监控2. 0
监控日志
通过对api成功率,js错误失败率,pv数据等各种指标应用相同的过程,我们可以构建一个在分钟计算系统中满足1分钟感知的监控系统。
警报系统架构
关于警报系统,上图是我们阿里巴巴研发部门的非常经典的监视系统。有兴趣的学生可以在infoQ上搜索sunfire,以查看有关该体系结构的更详细的介绍。我在这里不会做太多事情。
总体日志结构摘要
基本上,这就是我今天要分享的内容。从1. 0演变为2. 0的过程中,DingTalk前端监控是我们的思维方式和着陆方式。在这里,我会给您一个简短的摘要:
最关键的技术思想是预先安排日志警报组件。我们的实现是将日志双重写入分析系统和警报系统。在警报平台中,支持警报规则引擎,因此可以自定义警报,并对警报进行分级。对于前端,我们不仅是前端页面,我们还面临着用户终端。结束语
好的,这就是我今天要分享的内容。 DingTalk的前端监控如何以1亿规模,100多个前端和600多个前端页面来增强DingTalk的在线稳定性。
以下是DingTalk前端的技术专栏。有知乎列和掘金列。我们一直在招聘人才。欢迎与我联系。