前端监控系统设计简介

监控的分类

按照常见的部署架构可以将监控分为以下几类：

• 前端应用监控
• 后端服务监控
• 底层运维监控

每一层的监控的侧重点都有所差异，本篇文章把范围限定在“前端应用监控(不含node，node实际上可以归为‘后端服务监控’)”。

前端监控系统定义

前端应用程序监视是一个相对较新的术语，用于描述开发人员，工程师和产品所有者用来跟踪，维护和修复Web应用程序，本机应用程序和网站的工具。前端应用程序监视与更典型的应用程序性能监视工具（或APM）不同，因为它们专注于最终用户看到的内容，而不是托管应用程序或网站的服务器可以检索的事件。 from Front-End Application Monitoring

监控的一般过程与各环节的技术选型

为什么监视对前端很重要？

如果你不能衡量它，那么你就不能管理它。If you can’t measure it, you can’t manage it. ——德鲁克

前端一般是用户使用的第一道坎，任何前端的问题都可能导致业务的不可开展，进而影响公司收入、客户满意度等等。产品需要了解用户体验、开发人员需要了解服务的性能状况和可用性状况。

监控系统的三个关键点

日志(Logging)

关键特征：离散事件

日志是有一定格式的离散事件信息集合，用于记录事件发生的原始记录、重现应用内部的状态转化。例如：接口请求日志（DNS解析事件、响应时间、成功与否等）、主动上报的用户行为日志。

日志是监控的基础，如果没有日志也不存在监控。典型的日志解决方案是ELK Stack。阿里云上对应产品SLS。

度量(Metrics)

关键特征：数据可聚合

度量，也常被称作指标，是一段时间内组成单一逻辑尺度、计数器或者柱状图的原子，度量的典型特征就是由可聚合的数据组成。例如：可以将传入的HTTP请求的数量建模为一个计数器，通过简单的加法就可以汇总其更新。

追踪(Tracing)

关键特征：请求圈选

“追踪(Tracing)”是监控的一个重要组成部分，在如今的分布式微服务体系结构中变得越来越重要。全链路的应用监控中，“追踪”用于请求圈选并展示用户使用服务的整个过程的堆栈信息。如今一个服务基本是微服务的形式进行调用、部署则是分布式的，“追踪”的实现需要通过traceId才能将全链路的日志串起来。例如：

• 前端进行接口请求时，加上在请求header上requestId；
• 接着后端服务A接收到到请求记录当前requestId，开始处理请求；
• 后端服务A调用依赖服务B，服务B记录requestId并处理……

从示例可以看到，通过requestId可以将一个请求的所有调用链路串起来，方便问题排查。

开源的Tracing系统代表有zipkin，openTracing，jaeger。

监控什么？

错误监控

• 全局js报错(包含catch捕获)
  • 单个错误上报
  • 错误/PV占比
• 网络请求
  • 设备网络错误
  • HTTP异常状态码（例如：401、404、500等）
• 接口成功率
  • 调用次数
  • 接口成功率
• 自定义错误

性能监控

• 白屏时间
• 首屏时间
• 页面完全加载时间
• 静态资源加载耗时
• UA占比

业务监控

• PV/UV
• 业务转化
• 用户体验
• 用户行为

市面上常见的前端监控产品

ELK Stack

ELK提供了日志记录和汇总功能，将其牢牢地放置在可聚合的事件空间中，但是似乎在其他域中不断积累了更多功能，将其推向了中心。

阿里云ARMS

应用实时监控服务 (Application Real-Time Monitoring Service, 简称ARMS) 是一款应用性能管理产品，包含前端监控，应用监控和Prometheus监控三大子产品，涵盖了浏览器，小程序，APP，分布式应用和容器环境等性能管理，能帮助你实现全栈式的性能监控和端到端的全链路追踪诊断， 让应用运维从未如此轻松高效。 from 应用实时监控服务ARMS - 阿里云

Sentry

Sentry is an open-source application monitoring platform that helps you identify issues in real-time. from Sentry Documentation - Docs

Sentry 是一个实时事件日志记录和汇集的平台。其专注于错误监控以及提取一切事后处理所需信息而不依赖于麻烦的用户反馈。

CAT — 实时应用监控平台

CAT（Central Application Tracking）是一个实时和接近全量的监控系统，它侧重于对Java应用的监控，基本接入了美团点评上海侧所有核心应用。目前在中间件（MVC、RPC、数据库、缓存等）框架中得到广泛应用，为美团点评各业务线提供系统的性能指标、健康状况、监控告警等。自2014年开源。 from dianping/cat: CAT

实战经验与最佳实践

告警分级与响应预案

一般情况下，我们需要根据SLA对不同的告警进行分级，同时不同优先级的告警需要制定不同的响应预案。

一般公司会制定4种等级的告警：

• P0: 高优告警
• P1: 中优先级
• P2: 低优先级
• P3: 信息类警报

就时间而言，P0的SLA是分钟级别、P1的SLA是小时、P2的SLA是天、P3的SLA则没有时间限制。

响应预案也是很关键的，提前制定好预案可以更加快速的响应告警。

全链路监控需要依赖traceId

示例：根据eventId调出全链路日志，来自： Why and How to Test Logging

一般情况下，traceId是由后端自己生成的前端并不用关心这个traceId，只有在请求异常的情况下后端会返回这个traceId给前端做排查之用。在分布式架构中，这个traceId通常是由一个统一的服务颁发的，以保证全局饿的统一性。

由于前端日志中缺乏traceId，此时前端后端的监控是割裂的。一般情况下，前端的js错误也不需要traceId，通过查看请求参数（设备号UUID、用户ID）就可以定位到发生问题的用户及其设备。

有些场景下，需要打通前端后端的日志。这时候只能前端使用uuid工具生成一个traceId并通过请求header传给后端，后端会使用traceId来标记整个服务调用链路。这个方案有个缺点：不能保证traceId的全局唯一性。

数据的采样率

一般我们在接入一个监控平台的时候，首先要考虑到上报数据是全量的还是部分采样的，因为数据量大小影响数据的准确度。

何时采用“部分采样上报”？

如果是像淘宝那样前端页面访问量每月超过百亿（根据淘宝月活用户估计）的，如果全量上报数据可能对数据存储会产生非常大的压力。这时，采用“部分采样上报”是不错的选择，数据量够大的情况下，样本也能反应整体。

何时采用“全量上报”

• 数据量小
• 必须全量上报

告警的准确度

• 数据量太小导致指标波动幅度大。例如：10个请求中1个失败，那么成功率直接下降10%，触发告警。解决方案：将策略的统计时间拉长，单位时间内至少保证100条以上的数据。
• 噪声数据干扰告警。例如：同一用户一直上报问题数据，数据量达到直接影响整体数据。这时告警不能反映大盘。

理清核心指标

类似二八定律，20%的核心指标需要我们花80%的时间关注。

• 核心业务接口成功率
• 静态资源大盘
• 错误率(Error/PV)

结合大盘看数据

结合大盘看数据，大盘稳则小比例的问题影响不大。比如：出现某个市范围的“运营商DNS劫持”问题，这个市的数据一下子掉到正常水位下面，但是大盘还是没有啥问题的。这时候，影响面是比较小的。

实时告警的重要性

问题的发生会影响业务的开展，因此，告警的及时性非常重要。大多数的平台的告警都会有所延迟，如果延迟超过20分钟，就可能严重影响业务（比如：外卖服务的午高峰）

hash路由的影响

很多前端服务会采用hash路由，要注意的一点是：一般页面pv不会根据hash路由进行区分，多个路由的数据上报要手动进行标记区分。

数据（采集）隐私问题

• 采集需要合规。现在国内立法要求采集用户数据需要经过用户同意，同时采集过程中违规采集用户隐私数据也面临法律风险。
• 存储需要保障数据的安全。
• 使用数据需要保护用户隐私。可以使用差分隐私方式来保证个人隐私。

监控可视化

可视化面板让监控变得更加直观，也降低的用户上手难度。类似Grafana的监控面板是很重要的。

告警策略配置能力

实际上，前端对告警策略配置能力要求不高。下面几个策略能力基本满足所有的需要：

• 绝对值。PV绝对值、请求时长等
• 环比/同比。接口成功率同比、PV环比之类。
• 占比。“Error数/PV”等

核心基础数据

• 用于识别用户的数据
  • 用户跨平台唯一ID
  • 业务的userId
• 用于识别设备的数据
  • 用户设备的UUID
  • 浏览器UA
  • 软件版本
• 用于识别数据来源的数据
  • utm_source, utm_medium
  • 不同部门、不同产品线的标识

不同规模的团队（公司）如何进行监控选型？

• 大公司（阿里、美团点评级别）
  • 里一般团队都是采用公司统一的监控平台进行接入，方便快捷，队伍比较庞大的BU也会选择自己做一套自己BU业务定制的监控平台。以前我所在BU的前端团队差不多30几号人，我们选择自己搭建监控平台，开发维护（采用ELK+node埋点转发+前端采集SDK）平均需要1个全人力投入。
• 中小型公司（类似摩拜之类）
  • 中小型团队类似大公司里面的一个BU，一半会自己搭建一套监控平台（实际上搭建一套基础监控平台很简单，采用开源轮子几天搞定），很多团队会选择使用开源的Sentry、CAT、Grafana、ELK进行再次包装。
• 小型公司（10-50左右）
  • 直接使用免费的平台（Sentry、阿里云ARMS免费版）是比较直接的，或者直接把开源项目在自己的机器上跑起来、不做额外改造也是比较靠谱的。

参考资料

• Front-End Application Monitoring
• Peter Bourgon·度量，跟踪和日志记录

• [揭开神秘面纱的监视：有关日志记录，跟踪和指标的指南

  技术信标](https://techbeacon.com/enterprise-it/monitoring-demystified-guide-logging-tracing-metrics)

• Logs and Metrics - Cindy Sridharan - Medium
• Mon-ifesto第2部分：警报和图形-资本一技术-中
• 7 天打造前端性能监控系统 - FEX
• 前端异常监控解决方案研究 – 腾讯CDC