作者： Matt Connor
Sentry 自托管替代方案：GlitchTip 资源对比
Sentry 自托管文档要求 16 GB 内存和 16 GB swap，GlitchTip 记录为 512 MB。对比磁盘增长、容器数量与升级负担，再选择方案。
存储第一个事件之前，自托管错误跟踪的成本
自托管错误跟踪有一个决定整体方案的指标：内存下限。Sentry 的自托管文档要求 4 个 CPU 核心、16 GB RAM、额外 16 GB swap，以及 20 GB 可用磁盘空间；这些资源需求发生在应用发送第一个事件之前。GlitchTip 的文档则记录为 512 MB。这里的所有选项都接受来自相同 Sentry SDK 的事件，因此这不是如何为代码添加埋点的问题，而是您愿意为多大的服务器付费并持续运行的问题。
各项目公布的资源数据对比
以下是各项目截至 August 2026 自行公布的数据。它们的测量口径不同，因此比较前请先阅读每一行的说明。
The data behind this chart
[
{
"tool": "Sentry self-hosted",
"published_ram_gb": 16,
"notes": "documented minimum, plus 16 GB of swap"
},
{
"tool": "Bugsink",
"published_ram_gb": 4,
"notes": "the vendor's own published benchmark box, 2 vCPU"
},
{
"tool": "GlitchTip",
"published_ram_gb": 0.5,
"notes": "documented recommendation, 256 MB stated as the minimum"
}
]Sentry 的 16 GB 是文档中明确说明的最低配置，同一页面还建议使用 32 GB。GlitchTip 的 0.5 GB 是建议配置；项目方说明，实际运行最低需要 256 MB，经过谨慎配置后，也可以使用 128 MB 加 swap。Bugsink 的 4 GB 则不属于上述两类：这是供应商用于自身吞吐量基准测试的服务器配置。公布的数据只能作为起点，不能据此保证适用于您的事件量。
Sentry 自托管：完整产品，以及完整账单
官方技术栈是 getsentry/self-hosted，这是一个 Docker Compose 项目，运行的组件与 Sentry 在生产环境中运行的组件相同。其文档将其描述为“功能完整，已打包，适用于低流量部署和概念验证”。这句话准确概括了实际情况。您可以获得全部功能，也需要运行支撑这些功能的所有组件。
请从带标签的发行版安装，不要从 master 安装：
VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/getsentry/self-hosted/releases/latest)
VERSION=${VERSION##*/}
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}
./install.sh然后启动：
docker compose up --waitSentry 默认监听 http://127.0.0.1:9000。要求使用 Docker Engine 19.03.6 或更高版本，以及 Docker Compose 2.32.2 或更高版本。较旧的 Compose 会因文件语法失败，而不是因 Sentry 本身失败。
查看实际启动的内容：
docker compose ps
free -hdocker compose ps 会列出技术栈中的所有服务，列表很长：Postgres、ClickHouse、Kafka、Redis、Relay、Snuba、Symbolicator，以及多个 worker 和 cron 进程。请先数一遍，因为这个数量就是您的维护负担。每一项都是一个可能崩溃、占满磁盘或迁移失败的进程。
如果某个服务处于 Restarting 状态，请先检查内存：
dmesg -T | grep -i 'out of memory'类似 Out of memory: Killed process 3412 (java) 的一行表示内核的 OOM killer（out of memory killer，内存不足终止程序）终止了某个容器，因为服务器的 RAM 已耗尽。因此该服务不会变为 healthy 状态，整个技术栈也无法完成启动。这是在低于文档规定最低配置的环境中运行完整技术栈时的常见结果。文档还特别提示磁盘速度问题：iowait 高于 10% 表示机器无法跟上数据摄取管道。您可以从 top 的 wa 列读取该值；如果已安装 sysstat，也可以从 iostat -x 5 读取。
升级是人们最容易低估的部分
Sentry 自托管版本按照 CalVer 发布。CalVer 是一种基于日历的版本方案，每月 15 日发布主要版本。您不能从旧版本直接跳到最新版本。项目定义了硬性停留版本，您必须按顺序检出每个版本，以执行对应的数据库迁移。截至 August 2026，已发布的硬性停留版本为 9.1.2、21.5.0、21.6.3、23.6.2、23.11.0、24.8.0、25.5.1、26.5.0 和 26.7.0。文档还列出了因迁移问题需要跳过的版本，包括 23.7.0、25.9.0、25.12.0，以及 26.3.0 到 26.4.0 的版本范围。
升级就是检出版本，然后重新运行安装程序：
git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait开始前请为服务器创建快照，因为大型 ClickHouse 数据集的迁移可能运行数小时；如果中途失败，数据库会停留在两个 schema 之间。大多数 Sentry 自托管升级失败的直接原因是：服务器一年都停留在同一个版本，因此一次升级跨越了多个硬性停留版本，其中一个被跳过的迁移正是必要迁移。
在决定采用之前，还需要了解一点。Sentry 自托管采用 Functional Source License（FSL），该许可证由 Sentry 自行推出。它属于公平源代码许可证，不是 OSI 批准的开源许可证：您可以自行运行它，但不能将其作为竞争性服务销售。每个版本在发布两年后转换为 Apache 2.0。
GlitchTip：512 MB 解决方案
GlitchTip 使用 MIT 许可证，并可接收 Sentry 开源 SDK 发送的事件。因此，已完成埋点的应用只需修改一个值即可迁移：DSN（数据源名称，即 SDK 发布事件的 URL）。它需要 PostgreSQL 14 或更高版本。Valkey 或 Redis 7 或更高版本是可选项，可提升较大实例的运行速度。
安装只需要 Docker 和一个 compose 文件：
sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml启动任何服务前，先编辑环境变量部分。必须设置的值包括密钥、域名和邮件路径：
SECRET_KEY: <output of openssl rand -base64 50>
GLITCHTIP_DOMAIN: https://errors.example.com
DEFAULT_FROM_EMAIL: errors@example.com
EMAIL_URL: smtp://user:password@smtp.example.com:587示例已将 DATABASE_URL 连接到自带的 postgres 服务。除非您要连接自行运行的数据库，否则不要修改这一行。GLITCHTIP_DOMAIN 必须包含协议。开头缺少 https:// 时，告警邮件中的链接会生成错误，并指向无法响应的 URL。
启动服务并监控首次启动过程：
docker compose up -d
docker compose logs -f web截至 2026 年 8 月，示例中的镜像标签为 postgres:18、valkey/valkey:9 和 glitchtip/glitchtip:6。请固定这些标签。包含 latest 的 compose 文件会在下次 docker compose pull 时升级数据库引擎。在运行中的实例上直接升级 Postgres 主版本，可能导致原本正常运行的错误跟踪器无法启动。
要运行在 256 MB 到 512 MB 的内存范围内，可根据示例文件中的注释关闭相应功能，首先关闭 Valkey，以及可选的日志和运行时间功能。不使用 Valkey 时，GlitchTip 会改用数据库处理缓存和队列任务。这样速度较慢，但功能仍然正确。All in one 模式会在 Web 进程中运行 worker，因此只需维护一个应用容器，而不是两个。
在它前面配置代理。GlitchTip 文档要求使用能够缓冲请求并处理分块 Transfer-Encoding 的代理或负载均衡器，并以 nginx 作为示例。未启用缓冲时，慢速客户端会在整个上传过程中持续占用应用 worker。因此，少数慢速发送方就可能占满所有 worker，正常客户端也会开始超时。
升级最简单：
docker compose pull
docker compose stop
docker compose up -d数据库迁移会在启动时自动运行。但仍应先创建转储，因为自动迁移仍然是迁移。
Bugsink：一个容器，以及一份必须阅读的许可证
Bugsink 是三者中最轻量的一个。它支持 Sentry SDK 协议，运行时不需要消息队列，除数据库外也不依赖其他外部服务。默认使用 SQLite；当规模超出其承载能力后，也可以使用 MySQL 和 PostgreSQL。
如果只是想在正式部署前查看界面，可以先运行一个临时实例：
docker pull bugsink/bugsink:latest
docker run \
-e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
-e CREATE_SUPERUSER=admin@example.org:admin \
-e PORT=8000 \
-p 8000:8000 \
bugsink/bugsink打开 http://localhost:8000/，使用在 CREATE_SUPERUSER 中传入的地址和密码登录。该容器停止后不会保留任何数据。正式部署时，请使用项目提供的 compose 示例。该示例将 bugsink/bugsink:2 与 postgres:17-alpine 配对，并设置 DATABASE_URL、BASE_URL 和 BEHIND_HTTPS_PROXY。请正确生成密钥：
openssl rand -base64 50BASE_URL 必须与用户和 SDK 实际使用的 URL 匹配，包括协议部分。如果通过 https://errors.example.com 访问服务器，却仍将其设置为 http://localhost:8000，通知邮件中的每个链接都会指向收件人无法解析的主机。若 nginx 或 Caddy 在 Bugsink 前端终止 TLS（传输层安全），请将 BEHIND_HTTPS_PROXY 设置为 true。否则，Bugsink 会在您的 https:// 代理后生成 http:// URL，浏览器会阻止其中的混合内容。
供应商公布的吞吐量数据为：每秒 18 个事件，每个事件大小为 50 KB；在 2 vCPU 和 4 GB VPS 上，每天约可处理 1.5 million 个事件。请将其视为该工具的性能规模，而不是对您实际工作负载的保证。这些数据表明，其上限远高于一个小型应用通常产生的事件量。
接下来是许可证。这部分应在将其纳入技术栈之前阅读。Bugsink 依据 PolyForm Shield License 1.0.0 发布。该许可证允许查看源代码，但不属于开源许可证：您可以运行和修改 Bugsink，但不能用它构建与 Bugsink 竞争的产品。对于内部错误跟踪系统，这项限制通常不会产生影响。如果您的公司销售开发者工具，请先让专业人员阅读许可证文本。
错误跟踪和 LLM 可观测性仍然是两类工具
搜索同时提供错误跟踪和大语言模型（LLM）可观测性的工具时，您会看到一些产品声称同时支持两者。但两类数据的结构不同，因此它们一直没有真正合并。错误跟踪工具接收带堆栈跟踪的异常，根据异常计算指纹，再将数千次出现折叠为一个问题，并记录出现次数。LLM 跟踪工具接收包含提示词、响应、token 数量和延迟的 span，但必须保留每一条记录，因为即使两次调用的输入完全相同，它们仍是值得单独查看的事件。
因此，请同时运行这两类工具。将异常发送到错误跟踪工具，并将模型调用发送到专为此类数据构建的系统：用于代理跟踪的自托管 Langfuse覆盖这一部分，自托管 AI 可观测性则从不同角度处理相同的问题。您的应用已经会产生这两类故障。模型调用即使返回看似确定但完全错误的内容，也不会抛出任何异常，因此错误跟踪工具永远不会显示这类问题。
磁盘增长是迟早会出现的故障
每个错误跟踪器本质上都是写入量很大的数据库，并且输入没有上限。应用决定写入多少数据。热路径中的一个新 bug 就可能在一夜之间产生一百万个事件。
GlitchTip 发布过一个值得据此规划的数字：每月处理一百万个事件的实例可能需要 30 GB 磁盘空间。这只覆盖该速率下一个月的写入量。保留窗口决定你同时存储多少个月的数据。
Bugsink 采用了另一种方式。它不会使用固定配额，而是根据事件数量和事件年龄应用保留算法，并直接公开限制：整个安装的 MAX_RETENTION_EVENT_COUNT、每个项目的 MAX_RETENTION_PER_PROJECT_EVENT_COUNT，以及作为绝对上限的 MAX_EVENT_AGE_DAYS。设置整个安装范围的事件预算，是估算磁盘需求的可靠方法，因为该预算实际上就是磁盘需求。
在服务器上监控实际数值：
df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*docker system df -v 会输出各卷的大小，因此你可以确认具体是哪个服务在持续增长。如果某个卷每周增加数 GB，而流量没有变化，通常说明从未配置数据保留策略，因此数据从未被删除，唯一的限制就是分区容量。
内存问题只是换了一种表现形式。没有限制的服务栈会耗尽内核提供的所有内存。机器内存耗尽时，OOM killer 会选择占用内存最大的进程，而这个进程很可能是 Web 服务器，而不是导致问题的错误跟踪器。为每个服务设置上限：Docker Compose 中的内存限制介绍配置语法，以及容器达到上限时的行为。容器因达到自身限制而被终止，属于受控故障。容器被内核终止时，可能会连带终止其他服务。
哪种 VPS 适合哪种技术栈
- 1 GB，或有余量的 2 GB：使用单体模式运行 GlitchTip，并关闭 Valkey；或者在 SQLite 上运行 Bugsink。这两种方案都能轻松支持少量应用。
- 4 GB：使用 PostgreSQL 的 Bugsink，或启用 Valkey 并运行独立 worker 服务的 GlitchTip。到这个配置后，通常无需继续调优，直接运行即可。
- 8 GB：仍低于官方 Sentry 技术栈的要求。无论选择哪种轻量方案，都应将内存用于延长保留时间窗口，并为其配置更大的磁盘。
- 至少 16 GB，建议 32 GB：运行官方 Sentry 自托管技术栈，但仅适用于需要轻量项目未实现的 Sentry 功能的情况。请先根据各项目的文档检查具体功能，因为兼容的项目已经覆盖常见功能。
无论运行哪种方案，错误跟踪器都无法报告自身已停止运行。请从另一台机器对其进行检查：从另一台主机监控的 Uptime Kuma 会告知您跟踪器已停止运行，而此时应用通常正开始抛出无人记录的错误。
托管方案更划算的情况
当数据驻留规则要求自行托管，或事件量高到按事件计费的成本难以接受时，自行托管错误跟踪服务才更划算。在其他情况下，应如实计算成本。Sentry 文档要求的最低配置是 16 GB 内存、4 个核心和高速磁盘，这种配置的 VPS 并不便宜。还要加上运维工作：按顺序处理每个硬性阻断点，并在每次迁移前创建快照，而且每年要进行数次。
GlitchTip 和 Bugsink 会完全改变这个成本计算，因为 512 MB 到 4 GB 的服务器价格较低，而升级只需 docker compose pull。因此，提出这个问题的大多数人最后会选择其中一个兼容项目，而不是官方技术栈。他们需要的是错误跟踪，而不是需要持续维护的分布式数据管道。
如果您还在确定服务器上到底应部署哪些服务，更完整的自托管服务列表会将错误跟踪服务与其他争用相同 RAM 的服务放在一起。
FAQ
我可以在 2 GB VPS 上自行托管 Sentry 吗？
不可以。Sentry 的自托管文档要求至少 4 个 CPU 核心、16 GB RAM、16 GB swap，以及 20 GB 可用磁盘空间。该堆栈会同时运行 Postgres、ClickHouse、Kafka、Redis 和多个 worker 进程，因此在小型 VPS 上，安装完成前内核就会终止容器。使用 dmesg -T | grep -i 'out of memory' 可以确认这一点；该命令会输出包含被终止进程名称的一行内容。对于 2 GB VPS，请使用 GlitchTip；其文档标明最低需要 512 MB。也可以使用 Bugsink；它可作为单个容器运行在 SQLite 上。
从 Sentry 切换到 GlitchTip 或 Bugsink 时，必须修改应用代码吗？
不需要。两者都接受 Sentry 开源 SDK 发送的事件，因此可以保留已安装的 SDK，只需修改一个值：DSN，即 SDK 发布事件的 URL。如果 DSN 仍硬编码在代码中，请将其移到环境变量，然后将其指向新主机，再触发一个测试异常并监控事件是否到达。如果没有任何内容出现，请检查 DSN 中的项目标识符是否对应新服务器上已存在的项目，并确认防火墙允许应用访问该主机和端口。
自托管错误跟踪需要多少磁盘空间？
这取决于事件量和保留时长，而不是具体工具。GlitchTip 公布的配置是：处理每月 1000000 个事件的实例需要 30 GB。Bugsink 允许通过 MAX_RETENTION_EVENT_COUNT 和 MAX_EVENT_AGE_DAYS 直接设置磁盘预算，因此可以自行设定上限，所需磁盘空间也由此决定。请在第一天就配置保留策略。没有保留策略的错误跟踪系统会持续增长，直到 df -h 显示 100%；此时事件接收会停止，而你最需要查看的错误也会丢失。
为什么升级自托管 Sentry 总是失败？
因为升级跳过了必须经过的版本。Sentry self-hosted 规定了包含数据库迁移的特定版本，必须依次经过这些版本。截至 2026 年 8 月，这些版本是 9.1.2、21.5.0、21.6.3、23.6.2、23.11.0、24.8.0、25.5.1、26.5.0 和 26.7.0。直接从旧版本升级到最新版本会跳过这些迁移，导致数据库架构与代码不一致，升级在中途停止。请按顺序检出每个必须经过的版本，并在每个版本上运行 ./install.sh。开始前先创建服务器快照，并阅读文档中列出的应避免版本，其中包括 23.7.0、25.9.0 和 25.12.0。