上周三下午，Soumit还在给第五个 side project 配 Sentry。账单跳出来：5人团队，每月130美元起步，还没抓到第一个 bug。他盯着屏幕看了三秒，打开终端，开始写一个新 gem。
三个月后，FindBug 0.5.0 发布了。一个 Rails engine，MIT 协议，零 SaaS 绑定，所有数据躺在自己的服务器上。
这不是又一个开源替代品的故事。这是一个关于"成本到底该跟什么挂钩"的重新算账。
传统监控工具的定价逻辑是按人头。团队从2人扩到5人，费用从52美元涨到130美元，交付的价值没变，账单先翻倍。FindBug 的假设是：错误追踪的成本应该跟基础设施走，跟团队规模解耦。
更隐蔽的痛点是数据主权。Sentry、Bugsnag、Rollbar 的数据都在别人服务器上。大多数应用无所谓，但一旦涉及 PII、GDPR 或 SOC 合规，这就从"技术选型"变成"法务风险"。FindBug 的所有数据进自己的数据库，Redis 做缓冲，30秒批量刷盘，没有外部网络依赖。
网络依赖还有个更实际的场景：Sentry 的 edge 节点抽风时，你恰恰最需要 telemetry。FindBug 的架构设计了一条铁律——捕获错误绝不能阻塞用户请求。
具体实现是：请求进 middleware，PII 脱敏，LPUSH 进 Redis 缓冲池，Thread.new 异步执行，耗时约1-2毫秒。后台线程每30秒批量刷100条进数据库。Dashboard 挂载在 /findbug 路径，直接读库渲染。Redis 连续5次失败触发熔断，30秒内直接丢弃，保证应用速度。
连接池是独立的，跟应用的 Redis/Sidekiq 隔离。错误量暴增不会饿死缓存。这个设计针对的是 Rails monolith 的真实运行态：错误风暴往往和流量高峰重叠，不能让监控反过来压垮业务。
安装流程被压缩到四行：Gemfile 加 gem，bundle install，生成配置，跑 migration。Unhandled exception 自动捕获，HTTP 性能、SQL 查询、N+1 模式自动埋点。不需要 API key，没有环境专属的 DSN，没有多 dashboard 来回切换，没有 SDK 版本漂移。
手动捕获的 API 设计得很 Rails。想吞掉异常但保留记录：
begin
risky_operation
rescue => e
Findbug.capture_exception(e, user_id: current_user.id)
end
非异常事件：
Findbug.capture_message("Rate limit exceeded", :warning, user_id: 123)
性能追踪：
Findbug.track_performance("external_api_call") do
ExternalAPI.fetch_data
end
Controller 层可以挂请求级上下文，每个错误自动带上当前用户、套餐类型、组织 ID。Breadcrumb 的 API 是 findbug_breadcrumb("User clicked checkout", category: "ui")，语义直白。
这个项目的背景板是 Rails 生态的长期尴尬：官方生态很完整，但现代监控工具往往把 Rails 当成"众多支持语言之一"，体验是通用的，定价是 SaaS 的，数据是租来的。FindBug 的选择是做深不做广——只服务 Rails monolith，利用 engine 机制做到零配置侵入，用 MIT 协议降低采纳门槛。
0.5.0 版本的功能集已经覆盖小型团队的核心需求：异常捕获、性能监控、基础 dashboard、数据自托管。没有分布式追踪，没有机器学习聚类，没有 Slack 集成的花式模板。这些缺失是故意的，也是诚实的——作者给自己的 side project 写工具，只解决自己真实遇到的问题。
开源社区的反应还在早期。GitHub 仓库有基础文档，RubyGems 可下载，官网 findbug.dev 挂了更详细的 setup 指南。对于正在经历"监控账单膨胀"的 Rails 团队，这是一个值得试用的选项。对于想研究"如何在不阻塞请求的前提下做错误捕获"的工程师，代码本身可能比功能更有价值。
Soumit 没有打算颠覆 Sentry。他只是证明了：在特定约束下（Rails monolith、成本敏感、数据主权优先），存在一个更简单的解。这个解的边界很清晰——它不适用于微服务架构，不适用于需要跨语言统一监控的场景，不适用于需要企业级 SLA 的合同谈判。
但那些"不适用"恰恰是大多数 side project 和早期团队的真实状态。FindBug 的价值可能不在于它做了什么，而在于它没做什么。
热门跟贴