前端监控方案sentry整体概览

02-27 1662阅读 0评论

查看PDF

$前端监控方案sentry整体概览,前端监控方案sentry整体概览,词库加载错误:未能找到文件“C:\Users\Administrator\Desktop\火车头9.8破解版\Configuration\Dict_Stopwords.txt”。,使用,我们,访问,第1张$

（图片来源网络，侵删）

1. Sentry介绍

1.1. 编写目的

1.2. 名词定义

2. Sentry监控原理概述

2.1. 常见的性能优化指标及获取方式

$前端监控方案sentry整体概览,前端监控方案sentry整体概览,词库加载错误:未能找到文件“C:\Users\Administrator\Desktop\火车头9.8破解版\Configuration\Dict_Stopwords.txt”。,使用,我们,访问,第2张$

（图片来源网络，侵删）

2.2. 常见的前端异常及其捕获方式

3. Sentry 整体架构

4. Sentry安装部署

4.1. 前提条件

4.2. 安装

5. Sentry环境配置

$前端监控方案sentry整体概览,前端监控方案sentry整体概览,词库加载错误:未能找到文件“C:\Users\Administrator\Desktop\火车头9.8破解版\Configuration\Dict_Stopwords.txt”。,使用,我们,访问,第3张$

（图片来源网络，侵删）

5.1. 初始化配置

5.2. 应用服务配置

6. Sentry项目创建配置

6.1. 前端接入和使用

6.2. 域名解析配置示例

7. 常见问题解决

Sentry介绍

Sentry 是一套开源的实时的异常收集、追踪、监控系统。这套解决方案由对应各种语言的 SDK 和一套庞大的数据后台服务组成，通过 Sentry SDK 的配置，还可以上报错误关联的版本信息、发布环境。同时 Sentry SDK 会自动捕捉异常发生前的相关操作，便于后续异常追踪。异常数据上报到数据服务之后，会通过过滤、关键信息提取、归纳展示在数据后台的 Web 界面中。

1. 编写目的

此文档主要为帮助运维人员了解Sentry系统的原理、架构、配置、运行和维护，以确保软件系统的稳定性和可靠性，为自动化运维相关工作实施提供依据。

1. 名词定义

本文相关名词定义如下：

名称	说明
FP	first paint, 表示页面开始首次绘制的时间点，值越小约好。在 FP 时间点之前，用户看到的是导航之前的页面。
FCP	first contentful paint, lighthouse 面板的六大指标之一，表示首次绘制任何文本、图像、非空白 canvas 或者 SVG 的时间点，值越小约好。
FMP	first meaningful paint, 首次完成有意义内容绘制的时间点，值越小约好。
SI	speed index, 速度指标, lighthouse 面板中的六大指标之一，用于衡量页面加载期间内容的绘制速度，值越小约好。
LCP	lagest contentful paint, lighthouse 面板中的六大指标之一，完成最大内容绘制的时间点，值越小约好。
TTI	time to ineractive, 可交互时间， lighthouse 面板中的六大指标之一, 用于测量页面从开始加载到主要资源完成渲染，并能够快速、可靠地响应用户输入所需的时间, 值越小约好。
TBT	total blocking time，总的阻塞时间， lighthouse 面板中的六大指标之一，用于测量FCP到TTI之间的总的阻塞时间，值越小约好。
FID	first input delay, 首次输入延迟，测量从用户第一次与页面交互（例如当他们单击链接、点按按钮或使用由 JavaScript 驱动的自定义控件）直到浏览器对交互作出响应，并实际能够开始处理事件处理程序所经过的时间，指标的值越小约好。
CLS	Cumulative Layout Shift, 累积布局偏移，用于测量整个页面生命周期内发生的所有意外布局偏移中最大一连串的布局偏移情况，值越小，表示页面视觉越稳定。
DSN	Data Source Name , DSN告诉Sentry SDK 将事件发送到哪里，以便事件与正确的项目相关联。

实际在做性能分析时，上面列举的性能指标并不会全部使用。如果是本地通过 lighthouse 进行性能分析，会使用6大指标: FCP、LCP、SI、TTI、TBT、CLS。这些指标涵盖了页面渲染、交互和视觉稳定性情况。如果是通过 Sentry 等工具进行性能分析，会使用 4 大指标: FCP、LCP、FID、CLS。这些指标也涵盖了页面渲染、交互、视觉稳定性情况。

Sentry监控原理概述

衡量一个站点性能的好坏，我们通常看两个方面: 首屏性能和页面加载以后整个交互的流畅程度。这两个指标的好坏，决定了站点是否可以吸引用户和留住用户。为了能获得好的用户体验，我们常常需要对站点做性能优化。做性能优化，首先要对站点进行性能分析，寻找到底是哪个阶段性能较差，然后具体问题具体分析，找到对应的解决方案。最直接的方式是打开浏览器 performance、network、lighthouse 面板，然后对页面加载过程进行分析，这是一个有效的办法，但在实际使用时却存在非常大的局限性。也许，我们自己访问站点的时候性能很好，没有什么问题，但用户在实际访问时，由于设备、网络、使用姿势、使用人数、使用时间段、服务吞吐量等原因，整个体验很可能会没有达到我们的预期。这种情况下进行性能分析就非常麻烦了，首先我们无法感知，其次我们也无法在本地直接复现出用户的使用情形。

异常监控的核心作用就是通过上报的异常，帮开发人员及时发现线上问题并快速修复。要达到这个目的，异常监控需要做到以下 3 点: 线上应用出现异常时，可以及时推送给开发人员，安排相关人员去处理。上报的异常，含有异常类型、发生异常的源文件及行列信息、异常的追踪栈信息等详细信息，可以帮助开发人员快速定位问题。可以获取发生异常的用户行为，帮助开发人员、测试人员重现问题和测试回归。这三点，分别对应异常自动推送、异常详情获取、用户行为获取。

这个时候，我们可以借助监控工具来处理这个问题，如 Sentry这类工具，可以在用户访问站点时，将性能指标数据、异常详细信息通过接口上报给监控平台。监控平台接收到上报数据以后，对数据做汇总、计算，然后以可视化图表的方式展示。通过这些图表，我们就可以进行性能分析和快速定位问题，找到影响用户体验的因素或帮助开发人员、测试人员重现问题和测试回规，非常方便。

1. 常见的性能优化指标及获取方式

做性能分析，不管是在本地，还是通过工具，最重要的是要有数据支撑。目前，w3c 对性能相关数据，已经有了详尽的分类标准和与之配套的获取方式。详细分析常用的性能优化指标以及获取指标数据的方式。页面加载过程模型如下图：

这个加载过程模型，是web性能工作组早在 2012 年就针对页面加载过程制定的，定义了从上一个页面结束，到下一个页面从开始加载到完成加载的整个过程。基于这个模型，我们可以获取到页面加载过程中各个阶段的耗时情况，然后分析出页面加载性能。

通过 window.performance.timing 这个接口获取加载过程模型中各个阶段的耗时数据：

var timing = window.performance.timing;
// 返回数据格式
{
navigationStart, // 同一个浏览器上下文中，上一个文档结束时的时间戳。如果没有上一个文档，这个值会和 fetchStart 相同。
unloadEventStart, // 上一个文档 unload 事件触发时的时间戳。如果没有上一个文档，为 0。
unloadEventEnd, // 上一个文档 unload 事件结束时的时间戳。如果没有上一个文档，为 0。
redirectStart, // 表示第一个 http 重定向开始时的时间戳。如果没有重定向或者有一个非同源的重定向，为 0。
redirectEnd, // 表示最后一个 http 重定向结束时的时间戳。如果没有重定向或者有一个非同源的重定向，为 0。
fetchStart, // 表示浏览器准备好使用 http 请求来获取文档的时间戳。这个时间点会在检查任何缓存之前。
domainLookupStart, // 域名查询开始的时间戳。如果使用了持久连接或者本地有缓存，这个值会和 fetchStart 相同。
domainLookupEnd, // 域名查询结束的时间戳。如果使用了持久连接或者本地有缓存，这个值会和 fetchStart 相同。
connectStart, // http 请求向服务器发送连接请求时的时间戳。如果使用了持久连接，这个值会和 fetchStart 相同。
connectEnd, // 浏览器和服务器之前建立连接的时间戳，所有握手和认证过程全部结束。如果使用了持久连接，这个值会和 fetchStart 相同。
secureConnectionStart, // 浏览器与服务器开始安全链接的握手时的时间戳。如果当前网页不要求安全连接，返回 0。
requestStart, // 浏览器向服务器发起 http 请求(或者读取本地缓存)时的时间戳，即获取 html 文档。
responseStart, // 浏览器从服务器接收到第一个字节时的时间戳。
responseEnd, // 浏览器从服务器接受到最后一个字节时的时间戳。
domLoading, // dom 结构开始解析的时间戳，document.readyState 的值为 loading。
domInteractive, // dom 结构解析结束，开始加载内嵌资源的时间戳，document.readyState 的状态为 interactive。
domContentLoadedEventStart, // DOMContentLoaded 事件触发时的时间戳，所有需要执行的脚本执行完毕。
domContentLoadedEventEnd, // DOMContentLoaded 事件结束时的时间戳
domComplete, // dom 文档完成解析的时间戳， document.readyState 的值为 complete。
loadEventStart, // load 事件触发的时间。
loadEventEnd // load 时间结束时的时间。
}

window.performance.timing 已被废弃，改用 window.performance.getEntriesByType('navigation')。window.performance.timing，返回的是一个 UNIX 类型的绝对时间，和用户的系统时间相关，分析的时候需要再次计算。而新的 api，返回的是一个相对时间，可以直接用来分析，非常方便。

页面何时开始渲染 - FP & FCP

FP, first paint, 表示页面开始首次绘制的时间点，值越小约好。在FP时间点之前，用户看到的是导航之前的页面。

FCP, first contentful paint, lighthouse 面板的六大指标之一，表示首次绘制任何文本、图像、非空白canvas或者SVG的时间点，值越小约好。

指标可以通过以下接口performance.getEntry、performance.getEntriesByName、performanceObserver 来获取示例如下：

performance.getEntries().filter(item => item.name === 'first-paint')[0]; // 获取 FP 时间
performance.getEntries().filter(item => item.name === 'first-contentful-paint')[0]; // 获取 FCP 时间
performance.getEntriesByName('first-paint'); // 获取 FP 时间
performance.getEntriesByName('first-contentful-paint'); // 获取 FCP 时间
// 也可以通过 performanceObserver 的方式获取
var observer = new PerformanceObserver(function(list, obj) {
var entries = list.getEntries();
entries.forEach(item => {
if (item.name === 'first-paint') {
...
}
if (item.name === 'first-contentful-paint') {
...
}
})
});
observer.observe({type: 'paint'});

页面何时渲染主要内容 - FMP & SI & LCP

FMP, first meaningful paint, 首次完成有意义内容绘制的时间点，值越小约好。

SI, speed index, 速度指标, lighthouse 面板中的六大指标之一，用于衡量页面加载期间内容的绘制速度，值越小约好。

LCP, lagest contentful paint, lighthouse 面板中的六大指标之一，完成最大内容绘制的时间点，值越小约好。

FMP,是一个已经废弃的性能指标。在实践过程中，由于FMP对页面加载的微小差异过于敏感，经常会出现结果不一致的情况，因此性能分析的时候不再使用这个指标。

SI和FMP一样，官方也没有提供有效的获取接口，只能通过lighthouse面板来查看，不作为Sentry 等工具做性能分析的指标。

通过 performanceObserver 这个接口，我们可以获取到 LCP 指标数据：

new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log('LCP candidate:', entry.startTime, entry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});

何时可以交互 - TTI & TBT

衡量页面何时可以交互，有两个指标: TTI 和 TBT。

TTI, time to ineractive, 可交互时间， lighthouse 面板中的六大指标之一, 用于测量页面从开始加载到主要资源完成渲染，并能够快速、可靠地响应用户输入所需的时间, 值越小约好。

和 FMP、SI 一样，官方并没有提供获取 TTI 的有效接口，只能通过 lighthouse 面板来查看，不会作为 Sentry 做性能分析的指标。

TBT, total blocking time, 总的阻塞时间， lighthouse 面板中的六大指标之一，用于测量 FCP 到 TTI 之间的总的阻塞时间，值越小约好。和 TTI 一样，官方也没有提供获取 TBT 的有效接口，只能通过 lighthouse 面板来查看，不会作为 Sentry 做性能分析的指标。

交互是否有延迟 - FID & MPFID & Long Task

衡量交互是否有延迟，有3个指标: FID、MPFID、Long Task。其中，FID和MPFID可用来衡量用户首次交互延迟的情况，Long Task用来衡量用户在使用应用的过程中遇到的延迟、阻塞情况。

FID, first input delay, 首次输入延迟，测量从用户第一次与页面交互（例如当他们单击链接、点按按钮或使用由 JavaScript 驱动的自定义控件）直到浏览器对交互作出响应，并实际能够开始处理事件处理程序所经过的时间。FID 指标的值越小约好。

MPFID, Max Potential First Input Delay，最大潜在首次输入延迟，用于测量用户可能遇到的最坏情况的首次输入延迟。和FMP一样，这个指标已经被废弃不再使用。

Long Task，衡量用户在使用过程中遇到的交互延迟、阻塞情况。这个指标，可以告诉我们哪些任务执行耗费了 50ms 或更多时间。

通过 performanceObserver，我们可以获取到 FID 指标数据示例如下：

new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
const delay = entry.processingStart - entry.startTime;
console.log('FID candidate:', delay, entry);
}
}).observe({type: 'first-input', buffered: true});

页面视觉是否有稳定 - CLS

衡量页面视觉是否稳定，有 1 个指标: CLS

CLS, Cumulative Layout Shift, 累积布局偏移，用于测量整个页面生命周期内发生的所有意外布局偏移中最大一连串的布局偏移情况。CLS, 值越小，表示页面视觉越稳定。

通过 performanceObserver，我们可以获取到 CLS 指标数据示例如下：

new PerformanceObserver(function(list) {
var perfEntries = list.getEntries();
for (var i = 0; i /dev/null || echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sudo /sbin/sysctl -p /etc/sysctl.conf
#.2.setup-docker-ce
sudo curl -L https://download.docker.com/linux/static/stable/x86_64/docker-20.10.8.tgz -o /opt/docker-20.10.8.tgz
sudo tar -xvf /opt/docker-20.10.8.tgz --directory=/opt/
sudo mv /opt/docker/* /usr/bin/
sudo mv /opt/docker.service /etc/systemd/system/
sudo rm -rf /opt/docker
sudo chmod +x /etc/systemd/system/docker.service
sudo systemctl daemon-reload
sudo systemctl start docker
sudo systemctl is-active docker
#.3.set-on-start
sudo systemctl enable docker
sudo systemctl is-enabled docker
#################################################################
#.4.do-it-again
# systemctl stop docker
# systemctl disable docker.service
# rm -rf /opt/{docker,docker.service}
# rm -f /etc/systemd/system/docker.service
# rm -f /usr/bin/{docker*,containerd*,ctr,runc}

第2步 - 安装docker-compose

sudo curl -L "https://github.com/docker/compose/releases/download/v2.5.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/bin/docker-compose
sudo docker-compose --version

第3步 - 安装sentry

#将一键部署项目onpremise的源代码克隆到工作台目录
mkdir -p /data/app/ && cd /data/app/
git clone GitHub - getsentry/self-hosted: Sentry, feature-complete and packaged up for low-volume deployments and proofs-of-concept

onpremise部署主要文件结构和作用：

clickhouse/config.xml：clickhouse 配置文件

cron/：定时任务的镜像构建配置和启动脚本

nginx/nginx.conf：nginx 配置

relay/config.example.yml：relay 服务配置文件

sentry/：sentry-onpremise-local镜像的构建和基于此镜像启动的主服务的配置都在这个文件夹下

Dockerfile：sentry-onpremise-local 的镜像构建配置，会以此启动很多服务
requirements.example.txt：由此生成 requirements.txt，需要额外安装的 Django 插件需要被写在这里面
config.example.yml：由此生成 config.yml，一般放运行时不能通过管理后台修改的配置
sentry.conf.example.py：由此生成 sentry.conf.py，为 python 代码，覆盖或合并至 sentry 服务中，从而影响 sentry 运行。
.env：镜像版本、数据保留天数、端口等配置

docker-compose.yml：Compose工具配置，多docker的批量配置和启动设置

install.sh：Sentry 一键部署流程脚本

执行一键部署脚本：
1. cd onpremise
2. # 直接运行 ./install.sh 将 Sentry 及其依赖都通过 docker 安装
3. ./install.sh
执行onpremise的根路径下install.sh此即可完成快速部署，脚本运行的过程中，大致会经历以下步骤：
1. 环境检查
2. 生成服务配置
3. docker volume 数据卷创建（可理解为 docker 运行的应用的数据存储路径的创建）
4. 拉取和升级基础镜像
5. 构建镜像
6. 服务初始化
7. 设置管理员账号（如果跳过此步，可手动创建）
在执行结束后，会提示创建完毕，运行 docker-compose up -d 启动服务

删除服务：
1. # 停止所有运行
2. docker-compose down
3. # 移除所有 volume
4. docker volume prune
重启服务：
1. # 关闭服务
2. docker-compose down
3. # 启动服务
4. docker-compose up -d
1. Sentry环境配置
  1. 初始化配置
第一次访问管理后台，可以看到欢迎页面，完成必填项的配置，即可正式访问管理后台。
1. Root URL：异常上报接口的公网根地址（在做网络解析配置时，后台服务可以配置到内网外网两个域名，只将上报接口的解析规则 /api/[id]/store/ 配置到公网环境，保证数据不会泄密）。
2. Admin Email：在 install.sh 阶段创建的管理员账号。
1. Outbound email：这部分内容为邮件服务配置，可以先不配置。
2. 设置语言和时区
Sentry部署成功之后，我们可以进行一些设置。点击头像【User settings】 -【 Account Details】来设置语言何时区等
1. 1. 应用服务配置
一键部署的 Sentry 服务总会有不符合我们使用和维护设计的地方，需要通过对部署配置的修改来满足自己的需求。
1. Docker数据存储位置修改
在服务运行的过程中，会在docker volume数据卷挂载位置存储数据，如Postgres、运行日志等，docker volume默认挂载在/var目录下，如果你的/var目录容量较小，随着服务的运行会很快占满，需要对docker volume挂载目录进行修改。
1. # 在容量最大的目录下创建文件夹
2. mkdir -p /data/var/lib/
3. # 停止 docker 服务
4. systemctl stop docker
5. # 将 docker 的默认数据复制到新路径下，删除旧数据并创建软连接，即使得存储实际占用磁盘为新路径
6. /bin/cp -a /var/lib/docker /data/var/lib/docker && rm -rf /var/lib/docker && ln -s /data/var/lib/docker /var/lib/docker
7. # 重启 docker 服务
8. systemctl start docker
1. 使用独立数据库确保数据稳定性
在数据库单机化部署的情况下，一旦出现机器故障，数据会损坏丢失，而onpremise的一键部署就是以 docker的形式单机运行的数据库服务，且数据库数据也存储在本地。可以看到 Sentry 的数据库有两个，Postgres和ClickHouse。虽然Sentry不是业务应用，在宕机后不影响业务正常运行，数据的稳定并不是特别重要，但是Postgres中存储了接入Sentry的业务应用的id和token与对应关系，在这些数据丢失后，业务应用必须要修改代码以修改 token 重新上线。为了避免这种影响，且公司有现成的可容灾和定期备份的Postgres数据库，所以将数据库切换为外部数据库。

修改 sentry.conf.example.py 文件中 DATABASES 变量即可：
1. DATABASES = {
2. 'default': {
3. 'ENGINE': 'sentry.db.postgres',
4. 'NAME': '数据库名',
5. 'USER': '数据库用户名',
6. 'PASSWORD': '数据库密码',
7. 'HOST': '数据库域名',
8. 'PORT': '数据库端口号',
9. }
10. }
将Postgres相关信息从docker-compose.yml文件中删除：
1. depends_on:
2. - redis
3. - postgres # 删除
4. # ...
5. services:
6. # ...
7. # 删除开始
8. postgres:
9. return 403;}