钉钉前端团队如何打造亿级流量的监控系统？

　　钉钉前端团队如何打造亿级流量的监控系统？

　　前言

　　这篇文章是从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前端的技术专栏。有知乎列和掘金列。我们一直在招聘人才。欢迎与我联系。