错误追踪系统搭建？

访客全栈框架 2026-06-06 09:51:50 2

本文目录导读：

核心需求与目标
主流方案选择
开源自建技术栈推荐（最成熟组合：Sentry Self-Hosted）
自建Sentry的详细步骤（Docker Compose方式）
关键优化与避坑指南
替代方案（不想折腾Sentry）
总结建议

搭建一套有效的错误追踪系统（Error Tracking System），通常是为了解决线上应用“出了Bug不知道、知道了找不到根因、找到了修好了不知道效果”的问题，目前业界主流方案分为开源自建和SaaS服务两类。

这里我们重点讨论技术方案选型与自建架构设计,帮你做出决策。

核心需求与目标

在搭建前,先明确系统要解决什么问题：

实时告警：应用报错后，1-5分钟内通知到负责人。
错误聚合：100个人访问报错，不会生成100条记录，而是归并为同一条错误。
上下文回溯：能看到报错时的堆栈、用户操作、请求参数、浏览器版本、设备信息。
源码定位：对于前端打包后的代码，自动映射回源码（Source Map）。

主流方案选择

方案A：使用SaaS服务（推荐小团队/初创公司）

Sentry：业界标杆，功能强大，提供免费额度，支持前后端（JS、Python、Go、Java等）。
- 优点：开箱即用，托管服务，完全跳过运维成本。
- 缺点：企业版价格较高，数据存储在第三方。
Fundebug / ARMS（阿里云）：国内服务，网络延迟低，适合合规要求严格的企业。

方案B：开源自建（推荐中大型团队/对数据隐私敏感）

这是自建的核心,下面详细介绍。

开源自建技术栈推荐（最成熟组合：Sentry Self-Hosted）

核心组件：

事件收集：Sentry SDK（客户端/服务端）。
数据处理：Sentry Relay（代理层，用于数据清洗、限流、压缩）。
后端服务：Sentry Server（Python Django框架，负责事件存储、聚合、告警）。
数据库：
- PostgreSQL：存储元数据（项目、用户、告警规则）。
- ClickHouse：【关键】存储事件详情，Sentry 22+ 版本强制使用ClickHouse作为主事件存储，保证了极快的聚合和查询速度（亿级数据秒级查询）。
- Redis：缓存、任务队列。
- Kafka：事件流缓冲，防止高并发时雪崩。
前端：Sentry Web UI（React）。

架构图（简化版）

用户/应用 -> Sentry SDK -> [可选] Relay Proxy -> Kafka/Redis -> Sentry Server -> ClickHouse + PostgreSQL -> Web UI

自建Sentry的详细步骤（Docker Compose方式）

这是目前最稳的部署方式。

环境准备：
- 服务器：建议最低配置 4核8G内存，100G SSD（ClickHouse吃IO）。
- Docker & Docker Compose（v2.x 版本）。
- Git。

获取正式安装包（Sentry 官方推荐）：

# 克隆官方仓库
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
# 执行安装脚本（会自动处理配置检查、SSL、数据库初始化）
./install.sh

配置核心参数（安装前修改）：
- sentry/config.yml：设置 system.url-prefix 为你的域名（如 https://sentry.yourcompany.com）。
- sentry/sentry.conf.py：配置邮箱服务（用于发送告警邮件）。

启动服务：

docker compose up -d
# 创建初始管理员账号
docker compose run --rm web createuser --email admin@example.com --password [password] --superuser

集成SDK：

前端（Vue/React）：在项目中安装 @sentry/vue 或 @sentry/react。
后端（Node.js/Java）：安装对应的 @sentry/node 或 sentry-java。

关键配置：

// 以 Vue 为例
import * as Sentry from "@sentry/vue";
Sentry.init({
  app,
  dsn: "https://[your-public-dsn]@[your-sentry-domain]/[project-id]",
  integrations: [new Sentry.BrowserTracing()],
  tracesSampleRate: 1.0, // 采样率，生产环境建议设为0.2-0.5降低流量
  release: "v1.0.0", // 关联版本号
});

关键优化与避坑指南

前端 Source Map 处理（最重要）：
- 一定不要将源码映射文件（.map）放在生产CDN上对外暴露（易被反编译代码）。
- 使用 sentry-cli 或 @sentry/webpack-plugin 在CI/CD流程中仅上传到Sentry。
- 配置示例（webpack.config.js）：
```
new SentryCliPlugin({
    release: process.env.RELEASE_VERSION,
    include: './dist',
    ignore: ['node_modules'],
    configFile: '.sentryclirc', // 包含auth token
    urlPrefix: '~/your-app/static/js/', // 匹配服务器上的路径
})
```
数据采样与限流：
- 当并发量很大（每秒数万报错）时，ClickHouse会扛不住。
- 在Relay层配置 sample_rate（采样率）。
- 设置 quota（配额），防止恶意刷报错导致ClickHouse磁盘写爆。
告警通知：
- 推荐集成企业微信/钉钉/飞书机器人。
- 在Sentry UI中配置 Alerts -> Create Alert。
- 规则示例：count() > 10 in 5 minutes 且 level = error，则发送到Webhook。

替代方案（不想折腾Sentry）

方案	特点	适用场景
Mozilla Sentry	继续使用Sentry但不想自建	有运维能力但不想折腾，直接用官方SaaS
Grafana + Loki + Tempo	统一日志、指标、链路追踪	已经有Grafana全家桶的公司，需自己写告警规则
Honeycomb / Datadog	商业APM工具，自带错误追踪	预算充足、追求极致体验的团队
自己造轮子（不推荐）	用ELK收集日志，手写聚合规则	特定需求，或作为Sentry的补充（如只监控第三方服务）

总结建议

小团队（<10人）：直接用 Sentry SaaS，每月约 $26/月起（团队版），省去运维烦恼。
中型团队（10-50人）：如果对数据安全有要求，自建Sentry Self-Hosted，硬件成本约 500元/月（服务器），人力成本约 0.5天/周维护。
大公司（>50人）：考虑 Sentry SaaS 企业版 或 自建+定制化开发（修改Sentry的告警逻辑或UI）。

最后一步：搭建完成后的第一件事，就是观察生产环境的error数量曲线，并设置好针对核心接口报错的即时告警，否则这个系统就是一座数据孤岛。

标签：错误追踪系统搭建