前端代码炸了？别慌，教你用 Sentry 自建监控，把 Bug 扒得底裤都不剩！

说个真事儿。

上个月客户大促，流量刚上来，客服那边就炸锅了。说是有个核心下单页面，部分用户点了“支付”没反应。我们一群人在会议室里大眼瞪小眼。后端看监控，QPS 正常，报错率为零；前端在复现，怎么点都能跳出二维码。

要是搁以前，这锅大概率就得运维背，什么“网络波动”、“CDN 缓存没刷”之类的理由先顶上。

但这次我有底气。我打开 Sentry 的控制台，直接过滤出那个时间段的报错。好家伙，一片红。点开一个具体的 Issue，报错堆栈清清楚楚写着：Uncaught TypeError: Cannot read property 'price' of undefined。

再一看用户的操作录屏（没错，Sentry 能录屏，后面细说），原来这几个用户都选了一个特定的优惠券组合，导致前端计算价格的逻辑崩了，变量没取到值。

直接把这个链接甩给前端负责人，他脸当时就绿了，回去改了一行代码，发布，问题解决。前后不超过十分钟。

这就是 Sentry 的威力。它让你从“猜 Bug”变成了“看 Bug”。

咱为啥非得自建？

有人说，Sentry 官方不是有 SaaS 服务吗？注册个账号把 SDK 一接不就完事了？

哥们，那是美元啊。

Sentry 的免费额度少得可怜，稍微有点流量的业务，那 Event 数量蹭蹭往上涨，账单能让你怀疑人生。再说了，咱们国内的企业，尤其是做金融、政企项目的，用户数据那是红线。Sentry 会采集用户的 IP、设备信息、甚至操作行为，这些数据你要是敢往国外服务器传，第二天合规部门就得请你喝茶。

所以，私有化部署（Self-hosted）是咱们唯一的出路。

好消息是，Sentry 官方挺良心，开源版本的功能跟 SaaS 版差别不大；坏消息是，这玩意儿架构是真的重。

准备动手：但这玩意儿真吃资源

我想强调一下，Sentry 不是你随便找个 1核 2G 的测试机就能跑起来的玩具。

它的底层用了 Postgres 做关系型存储，Redis 做缓存和队列，Kafka 做消息缓冲，最狠的是它用了 ClickHouse 做海量日志的分析存储。再加上它那一堆 Python 写的 Web 服务和 Worker……

我曾经试过用 4G 内存的机器跑，结果就是 Docker 容器起起伏伏，像在做仰卧起坐，死活起不来。

所以，听哥一句劝：最低配置 4核 8G，建议 16G 起步。 硬盘最好上 SSD，不然 ClickHouse 查起来能慢得让你怀疑人生。

环境准备很简单，别想着源码编译安装了，那依赖能把你环境搞崩。直接上 Docker 和 Docker Compose。现在的运维，要是还没装 Docker，那就真说不过去了。

1. 拉代码
   去 GitHub 上把 getsentry/onpremise 这个库拉下来。这是官方提供的部署脚本，虽然有时候脚本里也有坑，但比自己手搓 docker-compose.yml 强一万倍。

   git clone https://github.com/getsentry/onpremise.git
   cd onpremise

2. 安装脚本一把梭
   官方提供了一个 install.sh。这脚本干的事儿挺多：检查环境、生成随机密钥、拉取 Docker 镜像、初始化数据库、执行 Migration。

   ./install.sh

   看着挺简单是吧？这里头有个大坑。Sentry 的镜像非常多，而且有些很大。如果你的服务器在国内，拉镜像的速度可能会让你等到地老天荒，甚至直接超时失败。

   这时候，要么你给服务器挂个梯子（懂的都懂），要么你就得配置 Docker 的国内镜像加速。甚至有时候 install.sh 里面会去下载一些像 GeoIP 数据库之类的文件，这些下载链接也可能被墙。

   如果卡住了，别傻等，看日志，手动下载文件放到指定目录，或者改改脚本里的下载源。

   安装过程中会让你创建一个管理员账号，输入邮箱和密码，记好了，这也就是你待会儿登录 Superuser 的凭证。

3. 起飞
   脚本跑完如果没报错（这通常需要点运气），最后会提示你运行：

   docker-compose up -d

   敲下回车，看着那一排排 Creating... 和 Started，心里那个舒坦。

   启动完之后，不要急着访问。这帮容器内部还得做一堆初始化工作，尤其是 Kafka 和 ClickHouse 的握手。你用 docker-compose ps 看看，确保所有容器状态都是 Up 且 Healthy。要是哪个是 Exit 或者 Restarting，赶紧 docker-compose logs <service_name> 查原因。

   访问 http://你的IP:9000。看到那个紫色的登录框，恭喜你，成功了一半。
   
   

进阶配置：不发邮件的监控是没有灵魂的

Sentry 装好了，但默认配置下它是哑巴。报错了它知道，但它不告诉你。

你得配邮件服务。

在 onpremise 目录下，找到 sentry/config.yml。这里面是 Sentry 的核心配置。把 SMTP 那一块的注释解开：

mail.host: 'smtp.exmail.qq.com'  # 举个栗子
mail.port: 465
mail.username: 'alert@yourcompany.com'
mail.password: 'your_password'
mail.use-tls: true
mail.from: 'alert@yourcompany.com'

改完配置，记得重启 Web 服务。不用全部重启，只要：

docker-compose restart web worker

这就行了。进去之后发个测试邮件，能收到就妥了。以后谁的代码炸了，邮件直接怼到他脸上。

前端接入：别让 Source Maps 坑了你

服务端搞定了，接下来是前端接入。这块其实是前端开发的工作，但作为运维，你得指导他们，不然他们配错了还得赖平台不好用。

以 Vue 项目为例（React 也差不多），安装官方的 SDK：

npm install --save @sentry/vue @sentry/tracing

然后在 main.js 里初始化：

import * as Sentry from "@sentry/vue";
import { Integrations } from "@sentry/tracing";

Sentry.init({
  Vue,
  dsn: "http://你的公钥@你的IP:9000/2", // 在Sentry后台创建项目后能拿到
  integrations: [new Integrations.BrowserTracing()],
  tracesSampleRate: 1.0, // 采样率，生产环境别设1.0，太费流量，建议0.1
});

这时候，如果页面报错，Sentry 后台就能收到了。

但是！ 重点来了。

现在的 Web 项目都是打包压缩过的，JS 代码混淆得连亲妈都不认识，变量名全是 a, b, c, d。你在 Sentry 里看到的报错堆栈大概长这样：

TypeError: t.a is not a function at app.js:1:2345

这看了有个屁用？鬼知道 t.a 是什么。

这时候就需要 Source Maps。这玩意儿就像是一个藏宝图，能把混淆后的代码映射回原始的源码。

你需要让前端在构建打包的时候（比如用 Webpack 或 Vite），把 .map 文件生成出来。但是，千万别把 .map 文件传到生产环境的公网服务器上，不然别人能反编译你的源码。

正确的姿势是：用 Sentry 提供的 sentry-cli 或者 Webpack 插件，在打包构建的 CI/CD 流程里，自动把 Source Maps 上传到咱们自建的 Sentry 服务器上，传完之后把本地的 .map 删了，再发布代码。

这样，Sentry 后台拿到报错时，就会自动去匹配你上传的 Source Maps，把那堆乱码还原成：

src/components/Payment.vue 第 54 行：calculateTotal() 方法出错

这才是人看的日志！这一点一定要跟前端强调，不然 Sentry 就是个摆设。

那些让你眼前一亮的功能

除了抓报错，Sentry 还有几个功能特别能打。

一个是 Performance（性能监控）。它能画出页面的加载瀑布图。有时候用户说慢，后端查了 API 很快，这时候你看瀑布图，发现是前端一张高清大图加载了 5 秒，或者是某个 JS 脚本阻塞了渲染。这就很直观。

另一个是 Session Replay（回放）。这个功能有点像以前的“按键精灵”录制。它不是录视频，而是把 DOM 的变化录下来了。

你能看到用户进页面后，鼠标怎么动的，点了哪里，滚轮滚到哪里，最后在哪里停住不动了（可能这时候报错了）。这种“案发现场”还原，对于复现那种偶发性 Bug 简直是神技。不过这功能挺占存储的，自建的话硬盘要够大。

运维的噩梦：磁盘爆炸

好了，吹了这么多，该说点扎心的了。

Sentry 是个吃硬盘的怪兽。

ClickHouse 存日志，Kafka 存消息队列，如果你的业务量大，或者有一天前端写了个死循环疯狂报错，你的磁盘可能会在几小时内被填满。

我之前就遇到过一次。半夜两点，监控报警说磁盘满了。上去一看，Kafka 的日志目录干了几百 G。

所以，上线 Sentry 之后，第一件事就是配置 Cleanup（清理策略）。

在 sentry.conf.py 里或者系统设置里，把日志保留时间设短点。默认可能是 90 天，对于错误日志，说实话，留个 14 天或者 30 天足够了。一个月前的 Bug 还没修？那估计也没人关心了。

另外，Sentry 自带了一个清理脚本，建议写进 crontab 里每天跑一次：

docker-compose run --rm web cleanup --days 30

这个命令会清理 Postgres 和 ClickHouse 里的旧数据。

还有，Kafka 有时候会产生很多积压，如果磁盘告急，可以手动去调 Kafka 的保留策略，或者暴力一点，直接重置 Kafka（会丢数据，慎用）。

总结一下

以前没上 Sentry 的时候，前端出了问题就是“玄学”，全靠猜和用户截图。上了 Sentry 之后，那就是“科学”。

虽然部署这玩意儿有点费劲，吃资源，还要维护，但它带来的价值是巨大的。它打通了前端和运维之间的那堵墙，让报错变得透明。作为运维，帮公司把这套系统搭起来，不仅能减少无意义的扯皮，还能实实在在提升系统的稳定性，这绩效不就来了吗？

技术这东西，不怕你不会，就怕你不知道有更好的工具。Sentry 绝对值得你花一个下午去折腾。

如果你在部署过程中遇到什么坑，比如 Docker 镜像拉不下来，或者 Source Maps 怎么都匹配不上，欢迎在评论区留言，咱们一起探讨。

公众号：运维躬行录

个人博客：躬行笔记