一般情况下都是通过重写js原生事件然后拿到错误信息，比如ajax请求，通过重写xhr、fetch事件来截取接口信息，所以我们需要优先编写一个易于重写事件的函数来复用。 所有的请求第三方库都是基于xhr、fetch二次封装的，所以只需要重写这两个事件就可以拿到所有的接口请求的信息…

团队开始前端错误监控方向的开发。经历了一些列的迭代和发展，从监控SDK、上报、数据治理、看板集成、APM自研可视化初步完成了一条完整且适合B站前端监控。

上一篇「前端监控:监控SDK手摸手Teach-架构篇(已开源)」讲的是SDK的整体架构，这篇讲的是监控代码的具体实现

本文的主要目的是介绍一种可扩展性较好的SDK架构，让后续业务迭代的代码更清晰明朗。这种架构已经在开源监控SDK:mitojs实践，有兴趣的小伙伴可以去瞅瞅~

常常会苦恼，平常做的项目很普通，没啥亮点；面试中也经常会被问到：做过哪些亮点项目吗？ 前端监控就是一个很有亮点的项目，各个大厂都有自己的内部实现，没有监控的项目就是在裸奔

在前端开发中，我们常常需要进行日志监控和错误排查，以便快速定位并解决问题。为了实现日志监控，我们需要搭建一个上报SDK，将前端产生的日志信息上报至后端。本文将介绍如何搭建前端日志监控的上报SDK

一个完整的前端监控平台包括三个部分：数据采集与上报、数据整理和存储、数据展示。 本文要讲的就是其中的第一个环节——数据采集与上报。下图是本文要讲述内容的大纲，大家可以先大致了解一下： 仅看理论知识是比

如何选择上报策略？监控SDK如何设计成多平台支持？如何进行SDK的代码结构组织？错误监控、性能监控的细节？等等问题，都会在文章中一个一个的来聊一聊

最近在负责团队前端监控系统搭建的任务。因为我们公司有统一的日志存储平台、日志清洗平台和基于 Grafana 搭建的可视化看板，就剩日志的采集和上报需要自己实现了，所以决定封装一个前端监控 SDK 来完