共计 6858 个字符，预计需要花费 18 分钟才能阅读完成。
背景
字节跳动倒退至今，线上曾经有数量级宏大的 Web 我的项目，服务着数以亿计的用户。
随着用户数量的一直增长，对于站点体验掂量的的需要也日益紧迫，用户会将产品和他们每天应用的体验最好的 Web 站点进行比拟。想着手优化，则必须先有相干的监控数据，能力隔靴搔痒。
性能是留住用户的要害。大量的钻研报告曾经表明了性能和商业问题的关系，蹩脚的性能会让您的站点损失用户数、转化率和口碑。谬误监控则可能让开发者第一工夫发现并修复问题，单靠用户遇到问题并反馈是不事实的，当用户遇到白屏或者接口谬误时，更多的人可能会重试几次、失去急躁而后间接关掉您的网站。
字节跳动开发团队依据外部数十款产品的体验监控需要，逐步打磨出了一版性能监控平台。通过一直的锻炼和积淀，正式在火山引擎上对外公布利用性能监控 全链路版。本文将会重点介绍它到底是一个怎么的监控平台，以及能够帮忙企业解决哪些痛点。
产品简述
利用性能监控全链路版是字节跳动旗下的企业级技术服务平台，为企业提供针对应用服务的品质、性能以及自定义埋点的 APM 服务。
基于海量数据的聚合剖析，平台可帮忙客户发现多类异样问题，并及时报警，做调配解决，同时平台提供了丰盛的归因能力，包含且不限于异样剖析、多维分析、自定义上报、单点日志查问等，联合灵便的报表能力可理解各类指标的趋势变动。更多功能介绍，详见各子监控服务的功能模块阐明。
产品亮点
该局部仅以整个产品的视角阐明了利用性能监控全链路版的亮点，更多技术亮点与劣势，咱们会在各功能模块中为您具体阐明。
更低的接入老本：非侵入式 SDK
在接入 SDK 时，只须要初始化几行代码即可接入胜利。
npm install @apm-insight-web/rangers-site-sdk
// 在我的项目最开始的中央引入上面的代码
import vemars from ‘@apm-insight-web/rangers-site-sdk/private’
vemars(‘config’, {
app_id: {{你的 appid}},
serverDomain: {{私有化部署服务器地址}},
})
或者通过一段 JavaScript 脚本，间接通过 CDN 接入：
<!– 脚本 –>
<!– 页面 <head> 标签顶部增加以下代码 –>
<script>
(function(i,s,o,g,r,a,m){i[“RangerSiteSDKObject”]=r;(i[r]=i[r]||function(){(i[r].q=i[r].q||[]).push(arguments)}),(i[r].l=1*new Date());(a=s.createElement(o)),(m=s.getElementsByTagName(o)[0]);a.async=1;a.src=g;a.crossOrigin=”anonymous”;m.parentNode.insertBefore(a,m);i[r].globalPreCollectError=function(){ir};if(typeof i.addEventListener===”function”){i.addEventListener(“error”,i[r].globalPreCollectError,true);i.addEventListener(‘unhandledrejection’, i[r].globalPreCollectError)}if(‘PerformanceLongTaskTiming’in i){var g=i[r].lt={e:[]};g.o=new PerformanceObserver(function(l){g.e=g.e.concat(l.getEntries())});g.o.observe({entryTypes:[‘longtask’]})}})(window,document,”script”,”{{你的 CDN 地址}}”,”RangersSiteSDK”);
</script>
<script>
window.RangersSiteSDK(“config”,{
app_id: {{你的 app_id}},
serverDomain: {{私有化部署服务器地址}},
});
</script>
更丰盛的异样现场还原能力
利用性能监控全链路版不仅帮忙您无死角地发现各类异样问题，还提供了丰盛的现场还原能力，包含且不限于堆栈回溯、用户交互还原等。
更灵便的采样形式，以节省开支
利用性能监控全链路版为您提供了采样配置，反对按功能模块设置采样、按用户设置采样，以帮忙您节俭事件量。
如此欠缺的性能监控平台，背地肯定有一套成熟的方法论。从平台设计之初，咱们就做好了具体的技术方案设计和衡量标准设计，接下来我会从更细节的角度来介绍这些设计，以及背地具体的原理。
怎么掂量 Web 体验
站点体验
首先，从站点体验方面来讲，Web Vitals 定义了 LCP、FID、CLS 指标，成为了业界支流的规范。
基于长期以来的体验指标优化积攒，最新的外围体验指标次要专一于加载、交互、视觉稳固，加载的速度决定用户是否能够尽早拜访到视觉上的图像，可交互的速度则决定用户心理上是否能够尽快感觉页面上的元素能够操作，而视觉稳定性则负责掂量页面的视觉抖动对用户造成的负面影响。
综合下来就是上面的 3 个指标：Largest Contentful Paint (LCP)
最大内容绘制，是用来测量加载的性能。这个指标上报视口中可见的最大图像或文本块的渲染的工夫点，为了提供良好的用户体验，LCP 分数最好保障在 2.5 秒以内。
First Input Delay (FID)
第一次输出提早，用于测量可交互性。FID 掂量的是从用户第一次与页面交互（例如，当他们点击链接，点击按钮，或应用自定义的 JavaScript 驱动的控件）到浏览器理论可能开始响应该交互的工夫，为了提供良好的用户体验，站点应该致力使 FID 放弃在 100 毫秒以内。
Cumulative Layout Shift (CLS)
累计布局位移，用于测量视觉稳定性。CLS 是掂量页面的整个生命周期中，产生的每次布局变动中的最大幅度的布局变动得分的指标。为了提供良好的用户体验，站点应该致力使 CLS 分数达到 0.1 或更低。
谬误监控
再从谬误监控来讲，当页面达到数以亿计的访问量时，无论公布前单元测试、集成测试以及人工测试过了再多轮，都难以避免的会漏掉某些边缘操作门路的测试，甚至偶然会呈现难以复现的玄学故障。哪怕这些谬误只有 0.1% 的呈现率，在亿级访问量的站点也会导致用户遭逢百万次故障。
这时候，欠缺的谬误监控体系就派上很大的用场。
咱们对 JavaScript 谬误、动态资源谬误以及申请谬误都提供了宏观的谬误数、错误率、影响用户数、影响用户比例等指标，高深莫测的关注到以后还存留的谬误以及对用户的影响，以帮助开发人员尽快修复问题。
同时对于申请的监控，为了进一步保障用户在获取数据上的体验，咱们还进一步的细化到了申请的成功率、慢查问相干的指标。
SDK 采集
有了这些衡量标准，咱们来具体看看 SDK 是怎么具体落地这些规范的。
须要采集什么指标？
RUM (Real User Monitoring) 指标，包含 FP, TTI, FCP, FMP, FID, MPFID。Navigation Timing **** 各阶段指标，包含 DNS, TCP, DOM 解析等阶段的指标。JS Error，解析后能够细分为运行时异样、以及动态资源异样。申请状态码，采集上报后，能够剖析申请异样等信息。如何采集这些指标？
RUM 指标的采集，次要依赖于 Event Timing API 进行测量。
以 FID 指标为例，先创立 PerformanceObserver 对象，监听 first-input 事件，监听到 first-input 事件后，利用 Event Timing API，通过事件的开始解决工夫，减去事件的产生工夫，即为 FID。
// Create the Performance Observer instance.
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
const FID = entry.processingStart - entry.startTime;
console.log('FID:', FID);
}
});
// Start observing first-input entries.
observer.observe({
type: ‘first-input’,
buffered: true,
});
Navigation Timing 指标，能够通过 PerformanceTiming 接口失去它们，以加载工夫的计算为例：
function onLoad() {
var now = new Date().getTime();
var page_load_time = now – performance.timing.navigationStart;
console.log(“User-perceived page loading time: ” + page_load_time);
}
JS Error 指标，通过 window.onerror 回调函数即可监听 JavaScript 运行时谬误 **：
window.onerror = function (message, source, lineno, colno, error) {
// 结构异样数据格式并上报
}
通过 unhandledrejection 事件监听 Promise rejections 异步谬误：
window.addEventListener(“unhandledrejection”, event => {
// 结构异样数据格式并上报
});
申请状态码，则能够通过覆写 window.fetch 和 XMLHttpRequest 对象来实现监听，以覆写 fetch 为例，以下是简化后的代码：
const _fetch = window.fetch;
window.fetch = (req: RequestInfo, options: RequestInit = {}) => {
// 省略一些逻辑……
return _fetch(req, options).then(
// 胜利
(res) => {
// 上报胜利申请信息
return res;
},
// 失败
(res) => {
// 上报失败申请信息
return Promise.reject(res);
},
);
};
服务端解决
SDK 数据采集结束后，会交由服务端端进行收集、荡涤以及存储等解决。
服务端接收数据后，对数据进行实时纬度解析补充，堆栈反解析等荡涤工作。依据不同平台产品性能，分门别类落地在不同类型的存储中：
无奈复制加载中的内容
数据收集层：数据收集层是无状态的 API 服务，逻辑较轻。只提供针对 SDK 上报数据的鉴权校验，拆包等工作，而后写入音讯队列 Kafka 供数据荡涤层生产
数据荡涤层：数据荡涤层是数据处理的逻辑核心。提供堆栈格式化，堆栈还原（SourceMap 解析），纬度补充（IP -> 地理位置，User-Agent -> 设施信息）等解决工作。为平台的多维分析统计，数据下钻等提供数据撑持。存储层：平台依据不同的性能需要，抉择不同类型的存储计划，实现实时秒级响应的平台查问。OLAP: 咱们抉择 Clickhouse 作为咱们数据分析的存储计划。Clickhouse 弱小的性能和字节外部针对性的优化，能够帮忙咱们实现每日千亿级别数据，秒级查问的成果。KV：字节外部自研高性能 KV 存储数据索引信息，联合 HDFS 存储详情。实现平台单点查问等详情追究性能。ES：对于一些自定义日志剖析搜寻场景，咱们应用 Elastic Search 作为存储，实现比拟灵便的日志搜寻剖析性能。在报警性能上，咱们通过实现形象的报警查问引擎（底层可适配不同数据源），对数据实时进行报警剖析。咱们反对灵便的报警规定配置，并接入各类第三方告诉平台作为音讯告诉的媒介。
在 SDK 的配置层面，咱们通过 SDK Setting 服务，实现平台化的采样率配置性能，实时管理控制上报数据。
可视化平台展现
通过了上文所述的采集上报 —— 存储荡涤 —— 统计分析等工作后，接下来就须要把这些数据交由用户来生产，可视化平台的性能也是至关重要的，接下来我将为您具体介绍平台中的各个性能。
性能剖析
性能剖析模块，分为页面加载和动态资源性能两个子模块。
页面加载监控是对用户会话过程中前端页面的性能监控。其中可查看的指标分类包含：实在用户性能指标和页面技术性能指标。通过页面加载监控，您能够对用户可感知到的耗时、页面性能有全面的理解。
实在用户性能指标也就是上文有所提及的 RUM 以及平台本人扩大的一些额定的指标，包含以下指标：
首次绘制工夫（FP）：即 First Paint，为首次渲染的工夫点。<!—->
首次内容绘制工夫（FCP）：即 First Contentful Paint，为首次有内容渲染的工夫点。<!—->
首次无效绘制工夫（FMP）：用户启动页面加载与页面出现首屏之间的工夫。<!—->
首次交互工夫（FID）：即 First Input Delay，记录页面加载阶段，用户首次交互操作的延时工夫。FID 指标影响用户对页面交互性和响应性的第一印象。<!—->
交互中最大延时（MPFID）：页面加载阶段，用户交互操作可能遇到的最大延时工夫。<!—->
齐全可交互工夫（TTI）：即 Time to interactive，记录从页面加载开始，到页面处于齐全可交互状态所破费的工夫。<!—->
首次加载 跳出率：第一个页面齐全加载前用户跳出率。<!—->
慢开比：齐全加载耗时超过 5s 的 PV 占比。在页面中，您能够残缺清晰的查看这些指标的情况：
页面技术性能指标
页面技术性能指标中提供的指标定义来自：Navigation Timing 的阐明。
无奈复制加载中的内容
慢加载列表列出了加载比拟迟缓的页面，不便您进行针对性优化：
在慢加载列表中，给出了具体的 URL 列表。点击 URL，可进入详情页具体分析该 URL 的耗时。
在多维分析性能中，您能够对会话性能所有的指标查问维度散布和占比状况。通过维度剖析，能够发现和定位某项异样。
动态资源性能的监控，也提供了相似于上述图表的性能，且反对通过瀑布图和耗时分布图来进行其余视角的浏览。
异样监控
异样监控次要分为 JS 谬误监控、申请谬误监控以及动态资源谬误监控，这些谬误监控模块的宏观生产维度都以谬误数、错误率、影响用户数、影响用户比例为主。
在 JS 谬误监控中，咱们提供了 JavaScript 谬误监控与剖析能力，同时反对上报自定义谬误。整体上分为大盘指标概览以及 issue 详情剖析。对 issue 进行状态的治理和解决人调配：
您还能够查问该条 issue 中每一条谬误事件中，用户的设施信息、版本信息等。点击 UUID / 会话 ID，可跳转至单点追究，查问该用户或单次 session 的具体日志。同时还有：
谬误堆栈：产生谬误的混同堆栈，如果上传了 SourceMap，则能够查看原始堆栈。<!—->
面包屑：用户在产生该谬误前后的操作行为记录，除了零碎主动收集的申请类型，还反对自定义埋点的交互事件类型。<!—->
自定义维度：除了零碎主动采集的维度外，反对上报自定义维度。动态资源谬误和申请谬误的模块都和 JS 谬误模块相似，提供概览、Issue 治理以及详情剖析等性能。
单点追究
单点追究的作用是能够针对特定的用户去查问在应用产品过程中的问题。目前反对了查问单个用户的日志，即日志查问。
通过输出 UUID（即用户 ID）或 Session_ID（即会话 ID）可查问单个用户一段时间内的前端日志，通过还原用户的操作门路，更好的定位事件产生的根因。
报警
对于监控平台来说，欠缺的报警零碎也是必不可缺的。针对各类数据、异样创立业务相干的报警机制，有助于尽早的发现和解决问题。
报警工作中，反对创立报警策略以及对已创立好的策略进行治理。
能够很不便的对接飞书中的报警告诉机器人，在接管到报警之后第一工夫反馈到飞书群里：
当然，在平台中您也能够查看报警的详情、历史列表。
总结
APM Plus 是字节跳动利用开发套件 MARS 下的性能监控产品，通过先进的数据采集与监控技术，为企业提供全链路的利用性能监控服务，解决企业对各端监控的需要。具备非侵入式监控、丰盛的异样现场还原能力，助力企业晋升异样问题排查与解决的效率、优化利用品质，以降低成本进步支出。
目前 MARS-APM 全链路版面向新用户提供试用 30 天的限时收费服务。其中蕴含 App 监控、Web 监控、Server 监控、小程序监控，App 监控和 Web 监控各 500 万条事件量，Server 与小程序监控限时不限量。
最初分享一个运维工具“猎报”，目前能够做到全面感知、精准告警、处理闭环、云端赋能、灵便部署。性能很弱小，页面很清晰。反对微信小程序查看设施状态，并且设施在线产生的 GTI 值能够换取商城里的小东西，当初每天可得两三百 GTI，举荐应用。
