作者：零售企业业务苏子刚
监控的背景和意义
在现代前端开发中，接入监控系统是一个很重要的环节，它可以帮助开发者、产品、运营了解应用的性能表现，用户的实际体验以及潜在的错误和问题，从而进一步优化用户体验，帮助产品升级迭代。
背景
•应用复杂性增加：随着单页应用（SPA）和渐进式网页应用（PWA）的流行，前端应用变得越来越复杂。
•网页加载性能要求提高：用户对网页加载速度和交互响应的要求越来越高，性能成为影响用户体验的关键因素。
•多样化的设备和网络环境：用户通过各种设备和网络环境访问应用，这些因素都可能影响应用的性能和用户体验。
•敏捷开发和持续部署：敏捷开发和 CI/CD 的实践要求开发团队能够快速的响应问题，并持续改进产品。
意义
•对应用性能监控，提升用户体验：监控页面的加载时间，交互时间等性能指标，帮助团队优化代码，提升用户体验。
•错误追踪，快速定位并解决问题：捕获前端错误和异常，快速定位问题源头，缩短故障的修复时间。
•用户行为分析，指导产品快速迭代：了解用户如何与应用互动，哪些功能用户喜欢，哪些路径导致转化，从而指导产品迭代升级。
•业务指标监控，保证主流程的稳定性：监控关键业务流程，如：购物车、商详、结算页等黄流，确保业务流程的稳定性。
•告警系统，异常情况能够快速响应：通过定时任务自动化巡检/实时监控，当出现性能异常时，能够快速响应。
监控的类别
从上面可看出，通过监控能够促使我们的系统更加健壮、稳定，体验更好。那我们团队也从去年开始逐步将各个应用接入了监控。到目前为止，我们的监控分为两个部分：
•实时监控：成功集成了 SGM 集团内部监控平台，并引入了相应的 SDK 来对前端应用进行实时监控。目前，我们所涉及的 100+ 个应用程序已经完全接入该系统。通过配置有效的告警机制，我们能够及时捕捉并上报线上环境中的错误和异常，确保业务的稳定运行。
•定时任务巡检：实现了定时任务的自动化设置，用于定期执行自动巡检，并自动上报检测结果，还能激活告警系统。通过这种方式，我们能够确保持续监控系统健康状况，并在发现潜在问题时能够迅速响应。
◦使用 Chrome 插件快速创建 UI 测试脚本，随后在 UI啄木鸟平台 上配置定时执行这些脚本进行系统巡检。这一流程实现了自动化的界面测试，确保应用的用户界面按预期工作，同时及时发现并解决潜在的 UI 问题；
◦自主研发一套脚本，这些脚本通过启动一个 Node.js 服务来进行系统巡检。这种方法使我们能够灵活地监控系统性能和功能，及时发现并处理潜在的问题，从而保障系统的稳定运行；
监控整体架构
监控建设实践
实时监控
通过整合 SGM 监控平台和告警系统，我们实现了对所有接入应用的实时监控。一旦检测到异常，系统会立即通过多种方式（如咚咚、邮件、电话等）通知相关团队成员，确保问题能够被迅速发现和解决。为了提高告警的有效性，我们精心设计了告警策略，确保只有真正的异常情况才会触发告警。以下是我们在优化告警设置过程中积累的一些关键经验和建议：
1.精确度与敏感度的平衡：过于敏感的告警会导致频繁的误报，而设置过于宽松则可能错过关键的异常。找到合适的平衡点至关重要。
2.分级告警机制：根据问题的严重程度设置不同级别的告警，以便采取相应的响应措施。紧急问题可以通过电话直接通知，而较为轻微的问题可以通过邮件或即时消息通知。
3.持续优化告警规则：定期回顾和分析告警的准确性和响应情况，根据实际情况调整告警规则，以提高告警的准确性和有效性。
4.明确责任分配：确保每个告警都有明确的责任人，这样一旦发生异常，能够迅速有人响应。
5.培训和意识提升：对团队成员进行定期的培训，提高他们对告警系统的理解和重视，确保每个人都能正确响应告警。
这些经验和建议是我们在实践中不断摸索和尝试的结果，希望能够帮助你们更有效地管理和响应系统告警，确保应用的稳定运行。
WEB端
用户体验
用户体验是指用户在使用网站过程中的整体感受、情绪和态度，它包括与产品交互的全程。对于开发者而言，打造出色的用户体验意味着关注网站的加载速度、视觉稳定性、交互响应时间、渲染性能等关键因素。Google 提出了一系列 Web 性能标准指标，这些指标旨在量化用户体验的不同层面。SGM 性能监控平台紧跟这些标准，对几项关键指标进行监控并提供反馈，以确保用户能够获得流畅且愉悦的网站使用体验。
•LCP：页面加载过程中最大的内容元素（图片、视频等）渲染完成的时间点。也可近似看作是首屏加载时间。Google 标准是 小于等于 2500ms。
最初，我们遵循了 Google 提出的标准来精确设定我们的告警系统。
配置告警后，我们注意到告警频率较高，主要是因为多数系统的实际网页最大内容绘制（LCP）值普遍超过了预期的 2.5s 标准。然而，这些告警并未实质性影响用户的正常使用体验。为了优化告警机制，我们经过仔细评估后，决定将部分系统的 LCP 阈值暂时调整至 5s，并相应调整了告警级别，以更合理地反映系统性能对用户体验的实际影响。
显然，当前调整的 LCP 阈值 5s 并非我们的最终目标。这一调整是基于应用当前的性能状况所做的临时措施，旨在优化告警的频率和质量。我们计划随着对各个应用性能的持续改进，最终将 LCP 阈值恢复至标准的 2.5s。
•CLS：从页面开始加载到生命周期状态更改为隐藏期间发生的所有意外布局偏移的累计得分。Web 给出的性能指标是 < 0.1
•FCP：从网页开始加载到有内容渲染的耗时。标准性能指标 1.8s
•FID：用户首次发出交互指令到页面可以响应为止的时间差。标准性能指标 100ms
•TTFB：客户端接收到服务器返回的第一个字节响应信息的耗时。标准性能指标 1000ms
从最初启用告警到目前决定关闭大部分告警，我们的决策基于以下考虑：
1.用户体验未受显著影响：即使某些性能指标超出了标准值，我们观察到这并未对用户操作网站造成实质性影响。
2.避免告警疲劳：频繁的告警可能导致开发团队对通知产生麻木感，从而忽视那些真正关键的、影响网站健康的告警。
3.指标作为优化参考：这些性能指标更多地被视为优化网站时的参考点，而对用户的直觉体验影响甚微。
4.有针对性的优化：在网站优化过程中，我们会将这些指标作为健康检查的一部分，进行针对性的改进，而无需依赖告警来频繁提醒。
基于这些理由，我们目前选择只对 LCP 指标保持告警启用，以确保关注到可能影响用户加载体验的关键性能问题。
| 健康度指标 | 告警开启 | 标准值 | 优化后值 | 告警阀值 | 告警级别 |
|---|---|---|---|---|---|
| LCP | 开启 | <=2500ms | 针对部分应用 <=5000ms | 1min 内 耗时>=5000ms（持续优化并更新阀值到2500ms） 调用次数：50 连续次数：1次 | 通知 |
| FCP | 关闭 | <=1800ms | - | - | |
| CLS | 关闭 | <=0.1 | - | - | |
| FID | 关闭 | <=100ms | - | - | |
| TTFB | 关闭 | <=1000ms | - | - |
页面性能
网页性能涉及从加载开始到完全可交互的整个过程，包括页面内容的下载、解析和渲染等多个阶段。在 SGM 监控平台上，我们能够追踪到一系列与页面加载性能相关的指标，如页面加载总时长、DNS 解析时长、DOM 加载完成时间、用户的浏览器和地理分布、首次渲染（白屏）时间、用户行为追踪、性能重现和热力图分析等。这些丰富的数据为我们优化页面性能提供了宝贵的参考。特别是首次渲染时间，或称为白屏时间，是我们监控中特别关注的一个关键指标，因为它直接影响用户的首次印象和整体体验。
•白屏时间：这一指标能够向开发者展示哪些页面出现了白屏现象。在利用此指标之前，我们需要为每个应用单独配置白屏时间的监控参数，以确保准确地捕捉到首次内容呈现的时刻。这有助于我们识别并优化那些影响用户首次加载体验的关键页面。
为了监控白屏时间，我们必须在应用的全局配置中的白屏监控项下，指定每个页面的 URL 及其关键元素。同时，我们还需设定监控的起始时间点和超时阈值。值得注意的是，URL 配置支持正则表达式，这为我们提供了灵活性，以匹配和监控一系列相似的页面路径。
•白屏检测的机制：白屏检测机制的核心在于验证页面上的关键元素是否已经被渲染。所谓关键元素，指的是在配置过程中指定的用于检测的 DOM 元素。这些元素的渲染情况是判断���面是否白屏的依据。
•告警设置：白屏告警功能已经启用，但目前还处于初期阶段，一些功能尚待完善。例如，当前的 URL 配置尚未支持正则表达式匹配。
面对当前的局限性，我们采取了双策略应对。一方面，我们利用白屏告警功能直接监控页面的白屏情况；另一方面，我们通过分析页面加载性能指标中的白屏时间来间接监测潜在的白屏问题。在设置平均耗时时间和告警级别时，我们综合考虑了多个因素，包括用户的网络环境、告警的发生频率以及告警的实际适用性，以确保监控方案的有效性和合理性。
| 网页性能 | 告警开启 | 优化前值 | 优化后值 | 告警阀值 | 告警级别 |
|---|---|---|---|---|---|
| 首包时间 | 关闭 | - | - | - | - |
| 页面完全加载时间 | 关闭 | - | - | - | - |
| 白屏时间 | 开启 | <=5000ms | <=10000ms | 1min 内 耗时>=10000ms，后期采用白屏告警替代 调用次数：30 连续次数：5 次 | 紧急 |
•此外，我们的页面追踪功能包括用户行为回溯、页面性能重现以及行为轨迹热力图，这些工具允许我们从多个维度和场景对用户行为进行深入分析，极大地便利了问题的诊断和排查。
JSError监控
我们通过配置错误关键词来匹配控制台的报错信息。报错阈值的设定可以参考各个项目的 QPS，因为在项目实施了恰当的降级策略后，即便控制台出现报错，页面通常仍能正常访问，不会对用户体验造成影响。因此，这个阈值可以适当设置得较高。
这里需要特别注意 "Script error" 的错误，这种错误给不到任何对我们有用的信息。所以需要采用一定的手段避免出现类似的报错：
•这种错误也称之为跨域错误，所以首先，我们需要开启跨域资源共享功能（CORS）。
xml
<script src="http://xxxdomain.com/home.js" crossorigin></script>•针对 Vue 项目，由于 Vue 重写了 window.onerror 事件，所以我们需要在 Vue 项目中增加 错误处理：
javascript
Vue.config.errorHandler = (err, vm, info)=> {
if (err) {
try {
console.error(err);
window.__sgm__.error(err)
} catch (e) {}
}
};•在某些情况下，"Script error" 可能是无关紧要的，我们可以选择忽略这类特定的错误。为此，可以关闭这些特定错误的监控，具体的错误可以通过它们的 hash 在错误日志中进行识别和过滤。
| 关键指标 | 关键字（支持正则匹配） | 触发次数 | 告警级别 |
|---|---|---|---|
| js错误 | null、undefined、error、map、filter、style、length... | 周期：1min ，错误次数：50/100/200（可参考 QPS 值设置），连续次数：1次 | 严重 |
API请求监控
这里我们的告警设置主要关注 HTTP 状态码和业务错误码。这两项指标的异常表明我们的应用可能遇到了问题，需要我们迅速进行检查和处理以确保系统的正常运行。
首先，我们必须在应用的监控配置中设定数据采集参数：
| 关键指标 | 错误码 | 业务域名 | 触发次数 | 告警级别 |
|---|---|---|---|---|
| http错误 | !200（Http响应非200报警） | xx1.jd.com xx2.jd.com | 周期：1min 错误次数：1 总调用次数：50 连续次数：1 | 严重 |
| 业务失败码 | errCode（根据实际业务线设置 -1，-2等） |
针对业务失败码：
1.由于现有应用跨不同业务条线存在异常码的差异，我们需要针对每个业务线收集并配置其特定的异常码。
| 应用来源 | 标准响应 | 针对性告警 |
|---|---|---|
| 慧采PC 企业购 | { "code":null, "success":true, "msg":"操作成功", "result":{} } | 业务异常码 code ·-1,-2 ·... |
| 锦礼 | { "code": 000, "data": {}, "msg": "操作成功" } | 业务异常码 code ·! (1000 && 3001等 ) |
| color | ·-1 echo ·1 echo | |
| 其他 | ... | .... |
2、对于新增应用，我们实施了后端服务异常码的标准化。因此，在监控方面，我们只需要配置一套统一的标准来进行监控。
json
{
"50000X": "程序异常，内部",
"500001": "程序异常，上游",
"500002": "程序异常，xx",
"500003": "程序异常，xx",
...
}资源错误
这里通常指的是 css、js、图片等资源的加载错误
| 关键指标 | 告警开启 | 告警阀值 | 告警级别 |
|---|---|---|---|
| 资源错误 | 开启 | 周期：1min 错误次数：200（也可参照QPS进行设置） 连续次数：1 | 严重 |
对于图片加载错误，只需在项目中实施适当的降级方案。在应用的监控配置中，我们可以设置为不收集图片错误相关的数据。
再来举个例子：
在企业业务的封闭场景中，例如慧采平台，我们集成了埋点 JavaScript 脚本。然而，由于某些客户的网络环境，导致我们的埋点相关静态资源延迟加载。
治理方案：
自定义上报
每个业务流程的关键节点或核心功能实施了专门的监控措施，以便对任何异常状况进行跟踪、监控并及时上报。
目前，几条业务线已经实施了自定义上报机制，其主要目的包括：
•利用自定义上报来捕获接口异常的详细信息，如入参和出参，以便在线上出现异常时，能够依据上报的数据快速进行问题的诊断和定位。
•在复杂的环境下，准确追踪用户行为导致的错误，并利用上报的信息进行有效的问题排查和定位。
锦礼酷兜： 用户在选择地址后，系统未能根据所选地址提供正确的信息，导致页面加载出现异常。
由于这个 H5 页面被嵌入到用户的 App 内，开发者难以直接复现用户遇到的问题。因此，我们利用监控平台的自定义上报功能来收集相关信息，以辅助进行问题排查。
•上报地址组件返回值
•上报接口入参
•然后根据自定义上报日志查看具体信息
E卡：外部引用资源异常上报（设备指纹，eid 等）
在结算页面提交订单时，系统需要获取设备ID。为此，我们实施了降级方案，并通过自定义上报机制对此过程进行监控，以确保流程的顺利执行。
降级方案：如果获取不到，后端会生成 uuid 给到前端。
企业购注销pc： 我们需要集成科技 SDK，以便在页面上完成用户注销后自动跳转到指定的 URL。上线后，收到客户反馈指出在完成注销流程后页面未能正确跳转。
接口异常： 在接口异常中，添加自定义监控，查看入参和出参信息。
尽管我们已经在应用中引入了自定义监控以便更好地观察和定位问题，但我们仍需进一步细化和规范化这些监控措施。目前，我们正积极对各业务线的功能点进行梳理，以实现更深入的细化监控。我们的目标是为每个业务线、每个应用的关键链路和功能点定制针对各种异常情况的精细化自定义监控（例如，某页面按钮的显示或点击异常）。
| 自定义告警 | 告警开启 | 告警阀值 | 告警级别 |
|---|---|---|---|
| 自定义编码 | 开启 | 1min内 调用次数：50 连续次数：1次 | 警告 |
小程序端
与 Web 端相比，小程序的监控存在一些差异，主要是缺少了如 LCP（最大内容绘制）等特定性能指标。然而，性能问题、JavaScript错误、资源加载错误等其他监控指标仍然可以被捕获。此外，小程序官方和开发者工具都提供了性能检测工具，这些工具便于开发者查看和优化小程序应用的性能。本文将不深入介绍 Web 端的监控指标，而是专注于介绍小程序中独有的监控和分析工具。
小程序官方后台
可以分析接口数据、js 分析等。
利用 SGM 的监控功能结合小程序官方的分析工具，对我们的小程序进行综合优化，是一个有效的策略。
原生应用
基础监控：mPaas、烛龙、SGM
mPaaS ：崩溃监控。应用崩溃对用户体验有显著影响，是移动端监控中的一个关键指标。通过不断的监控和优化，京东慧采移动端的崩溃率已经降至较低水平，目前的平均用户崩溃率大约为0.03122%。
烛龙：启动耗时、首屏耗时、启动且首焦耗时、卡顿。为了改善首屏加载时间，京东慧采采用了烛龙监控平台并实施了相应的优化措施。优化后，应用的整体性能显著提升，其中 Android 平台的tp95耗时大约为 2764ms，iOS 平台的tp95耗时大约为1791ms，均达到了较低的水平。
SGM：网络、WebView、原生页面等指标。
业务监控
京东慧采在多个业务模块中，其中登录、商详、订单详情 3 个模块接入了业务监控。
登录：登录接入 SGM 监控平台，自定义了整个流程错误码，并配置了告警规则
（1）600：登录正常流程（必要是可白名单开启）
（2）601：登录防刷验证流程异常监控
（3）602：登录魔方验证流程异常监控
（4）603：登录流程异常监控
商详、订单详情：在商品详情和订单详情页面，我们集成了业务监控 SDK。通过移动配置平台，我们下发了监控规则，以便在接口返回的数据不符合预期时，能够上报错误信息。目前，这些监控信息被上报到崩溃分析平台的自定义异常模块中，以便进行进一步的分析和优化。
（1）接口请求是否成功。
（2）banner 楼层：是否为空、楼层类型是否正常（1 原生）、数据/大小图地址是否为空。
（3）商品信息楼层：是否为空、楼层类型是否正常（2 动态）、数据/商品名称/价格是否为空。
（4）服务楼层：是否为空、楼层类型是否正常（1 原生）、数据/服务信息是否为空。
（5）spu 和物流楼层：是否为空、楼层类型是否正常（1 原生）、数据/sup信息是否为空。
（6）其他：其他/按钮数据/按钮名称是否为空、按钮类型是否正常（排除1/2/3/4/5/6/20000）。
订单详情监控信息：
（1）接口请求是否成功。
（2）基础信息楼层：是否为空、楼层类型是否正常（2 动态）、数据/地址信息是否为空。
（3）商品信息楼层：是否为空、楼层类型是否正常（2 动态）、数据/商品列表是否为空。
（4）支付信息楼层：是否为空、楼层类型是否正常（2 动态）、数据是否为空。
（5）价格楼层：是否为空、楼层类型是否正常（2 动态）、数据是否为空。
定时巡检
定时巡检可以通过两种方法实现：
•利用 UI 啄木鸟平台配置定时执行的任务。
•使用团队开发的自定义脚本，并通过自动启动的服务来执行这些检测任务。
UI 啄木鸟
定时巡检的主要目的是确保每个项目的核心流程在每次迭代中保持稳定。通过配置定时任务，我们能够及时发现并解决线上问题，从而维护系统的稳定性。
什么是 UI 啄木鸟
UI啄木鸟平台，由京东集团-京东科技开发，是一个自动化巡检工具，其主要功能包括：
•Chrome插件：用于录制项目的用户交互步骤。
•定时任务平台：用于在服务器端定期执行已录制的脚本进行巡检。
在使用Chrome插件过程中，我们遇到了一些问题。与京东科技团队沟通后，我们获得了共同开发和升级插件的机会。目前，我们已经添加了新功能并修复了一些已知问题。
1.打开录制和停止录制按钮，分别开启监听和关闭拦截页面事件功能；
2.新增点击录制后保留当前录制步骤功能；
3.在执行事件过程中，禁止再次点击执行，避免执行顺序错乱；
4.点击事件可切换操作类型为 focus 事件，便于监听滚动条滑动；
5.在步骤复现情况下，调整判断元素选择器和屏幕位置的顺序，避免位置出入点击位置错位；
6....
使用chrome扩展程序进行安装即可。
怎么使用
•新建录制脚本
•点击详情，开启录制
•监听步骤
•关联到啄木鸟平台
•啄木鸟平台（调试、配置 Cookie，开启定时任务）
自启动巡检工具
自动化巡检工具能够检测页面上的多种元素和链接，包括 a 标签的外链、接口返回的链接、鼠标悬停元素、点击元素，以及跳转后 URL 的有效性。该工具尤其适合用于频道页，这些页面通常通过投放广告和配置通天塔链接来生成。在大型促销活动期间，我们可以运行脚本来验证广告和通天塔链接的有效性。目前，工具的功能还相对有限，并且对于广告组等特定接口的支持不够通用，这也是我们计划逐步改进和优化的方向。
功能检测
•检测所有 a 标签和所有接口响应数据中包含所有通天塔活动外链是否有效。
json
{
"cookieThor":"", // 是否依赖cookie等登录态，无需请传空
"urlPattern": "pro\.jd\.com",// 匹配的链接，这里只匹配通天塔
"urls": ["https://b.jd.com/s?entry=newuser"] // 将要检测的url，可填多个
}运行结果：
•检测鼠标 hover 事件，收集用户交互后的接口响应数据，检测所有活动外联是否有效。
json
{
"cookieThor": "",
"urlPattern": "///pro.jd.com/",
"urls": [
{
"url": "https://b.jd.com/s?entry=newuser",
"hoverElements": [
{
"item": "#focus-category-id .focus-category-item", // css样式选择器
"target": ".focus-category-item-subtitle"
}
]
}
]
}•检查 click 事件，收集用户交互后的接口响应数据，检测所有通天塔活动外联是否有效。
json
{
"cookieThor": "",
"urlPattern": "///pro.jd.com/",
"urls": [
{
"url": "https://b.jd.com/s?entry=newuser",
"clickElements": [
{
"item": "#recommendation-floor .drip-tabs-tab"
}
]
}
]
}•检测点击后，跳转后的链接有效性。
json
{
"cookieThor": "",
"urlPattern": "///pro.jd.com/",
"urls": [
{
"url": "https://b.jd.com/s?entry=newuser",
"clickElements": [
{
"item": ".recommendation-product-wrapper .jdb-sku-wrapper"
}
]
}
]
}检测原理
监控后暴露的问题
•慧采 jsError：
用于埋点数据上报的API，但在一些封闭环境中，由于网络环境，客户可能无法及时访问埋点或指纹识别等 SDK，导致频繁的报错。为了解决这个问题，我们可以通过引入 try...catch 语句来捕获异常，并结合使用队列机制，以确保埋点数据能够在网络条件允许时正常上报。这样既避免了错误的频繁发生，也保障了数据上报的完整性和准确性。
typescript
public exposure(exposureId: ExposureId, jsonParam = {}, eventParam = '') {
this.execute(() => {
try {
const exposure = new MPing.inputs.Exposure(exposureId);
exposure.eventParam = eventParam; // 设置click事件参数
exposure.jsonParam = serialize(jsonParam); // 设置json格式事件参数，必须是合法的json字符串
console.log('上报 曝光 info >> ', exposure);
new MPing().send(exposure);
} catch (e) {
console.error(e);
}
});
}
private execute(fn: CallbackFunction) {
if (this._MPing === null) {
this._Queue.push(fn);
} else {
fn();
}
}•企业购订详异常：
总结
接入前
在过去，我们的应用上线后，对线上运行状况了解不足，错误发生时往往依赖于用户或运营团队的反馈，这使我们常常处于被动应对状态，有时甚至会导致严重的线上问题，如白屏、设备兼容性问题和异常报错等。为了改变这一局面，我们开始寻找和实施解决方案。从去年开始，我们逐步将所有 100+ 应用接入了监控系统，现在我们能够实时监控应用状态，及时发现并解决问题，大大提高了我们的响应速度和服务质量。
接入后
自从接入监控系统后，我们的问题发现和处理方式从被动等待用户反馈转变为了主动监测。现在我们能够即时发现并快速解决问题。此外，我们还利用监控平台对若干应用进行了性能优化，并为关键功能点制定了预先的降级策略，以保障应用的稳定运行。
•页面健康度监控表明，我们目前已有 50+ 个项目的性能评分达到或超过 85 分。通过分析监控数据，我们对每个应用的各个页面进行了详细分析和梳理。在确保流程准确无误的基础上，我们对那些性能较差的页面进行了持续的优化。目前，我们仍在对一些关键但性能表现一般的应用进行进一步的优化工作。
•通过配置 JavaScript 错误和资源错误的告警机制，我们在项目迭代过程中及时解决了多个 JavaScript 问题，有效降低了错误率和告警频率。正如前文所述，对于慧采PC 这类封闭环境，客户公司的网络策略可能会阻止埋点 SDK 和设备指纹等 JavaScript 资源的加载，导致全局变量获取时出现错误。我们通过实施异常捕获和队列机制，不仅规避了部分错误，还确保了埋点数据的准确上报。
•通过收集 HTTP 错误码和业务失败码，并设置相应的告警机制，我们能够在接到告警通知的第一时间内分析并解决问题。例如，我们成功地解决了集团内部遇到的 "color404" 问题等。这种做法加快了问题的响应和解决速度，提高了服务的稳定性和用户满意度。
•自定义监控：通过给接口异常做入参、出参的上报、在关键功能点上报有效信息等，能够在应用出现异常时，快速定位问题并及时修复。
•通过实施定时任务巡检，我们有效地避免了迭代更新上线可能对整个流程造成的影响。同时，巡检工具的使用也确保了外部链接的有效性，进一步保障了应用的稳定运行和用户体验。
规划
监控是一个持续长期的过程，我们致力于不断完善，确保系统的稳定性和安全性。基于现有的监控能力，我们计划实施以下几项优化措施：
1.应用性能提升：我们将持续优化我们的应用，目标是让 90% 以上的应用性能评分达到 90 分以上，并对资源错误和 JavaScript 错误进行有效管理。
2.深化监控细节：我们将扩展监控的深度和广度，确保能够捕捉到所有潜在的异常情况。例如，如果一个仅限采购账号使用的按钮错误地显示了，这应该触发自定义异常上报，并在代码层面实施降级处理。
3.巡检工具升级：我们将继续升级我们的 Chrome 巡检插件，提高其智能化程度和覆盖范围，以保持线上主要流程的健壮性和稳定性。
结尾
我们是企业业务大前端团队，会持续针对各端优化升级我们的监控策略，如果您有任何疑问或者有更好的建议，我们非常欢迎您的咨询和交流。