前端监控体系建设思考——前端研发体系

前端监控示例图，来自 Real User Monitoring for improving frontend performance | Atatus Browser

前端监控系统设计简介

监控的分类

按照常见的部署架构能够将监控分为如下几类：

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

每一层的监控的侧重点都有所差别，本篇文章把范围限定在“前端应用监控(不含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异常状态码（例如：40一、40三、413等）
• 接口成功率
  • 调用次数
  • 接口成功率
• 自定义错误

性能监控

• 白屏时间
• 首屏时间
• 页面彻底加载时间
• 静态资源加载耗时
• 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·度量，跟踪和日志记录
• 揭开神秘面纱的监视：有关日志记录，跟踪和指标的指南| 技术信标
• Logs and Metrics - Cindy Sridharan - Medium
• Mon-ifesto第2部分：警报和图形-资本一技术-中
• 7 天打造前端性能监控系统 - FEX
• 前端异常监控解决方案研究 – 腾讯CDC