Superlog：用 AI agent 自愈的开源可观测性工具，装之前先看清它的边界
Open-source observability tool that uses AI agents to self-heal your software
秒懂
- 它是什么？
- Superlog 把 OTLP 的 traces、logs、metrics 收进来，按 fingerprint 归组成 incident，再交给可插拔的 agent runner 去调查。社区版默认的 community runner 只写一份本地 incident 摘要，这一点决定了它现在的真实定位。
- 适合谁用？
- 如果你已经在往某个 OTLP 端点发数据，又想在一个自托管的工作区里把噪音信号先归组成 incident 再谈调查，Superlog 值得花一个下午跑通 docker compose up -d 这条链路，重点验证三件事：packages/fingerprint 的归组规则在你的真实数据上会不会把不同故障合并成一条 incident；community runner 写出的摘要是否已经覆盖你的值班判断；以及 ClickHouse 与 Postgres 并存的部署成本你是否愿意承担。如果你要的是开箱即用的告警路由、值班排班和成熟的规则引擎，现在不要选它，社区版的 agent runner 记录的是本地摘要，不是自动修复动作，把它当成能替你改代码的系统会直接失望。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
Superlog 想解决的是信号太多而不是信号太少
生产系统的常见状态不是没有数据，而是数据太多。一个服务抖动五分钟，OTLP 管道里可能落进几千条 span 和日志，值班的人要在这堆东西里找出「这其实是同一件事」。Superlog 的定位就卡在这个环节：README 说它「ingests traces, logs, and metrics, groups noisy signals into incidents」，先归组，再谈调查。
目标用户写得很清楚，是「teams a local-first product surface for debugging production systems」，本地优先，自托管。仓库里同时列了 Web app、API、OTLP ingest proxy、worker、Postgres schema、ClickHouse 查询层和 agent runner 接口，这不是一个只做前端展示的壳子，而是一套要自己跑起来的服务集合。
它不适合谁也很明确。如果你的团队还没有统一的 OTLP 出口，或者你期待的是 SaaS 那种注册即用，这个仓库给的是社区版，README 里另有一段说明托管云版本存在，有免费额度和按量付费计划。社区版和云版的能力边界，README 没有逐项对比，这一点需要你自己去官网确认。
从 OTLP 入口到 incident 摘要的数据流
按仓库布局推断，数据先落到 apps/proxy，也就是 OTLP intake proxy，默认监听 4101。这一层的职责是接收入口流量，而不是直接对外提供查询。写入之后由 packages/db 里的 Drizzle schema 和 migrations 定义的结构承载，而 README 明确说 telemetry 查询是 ClickHouse-backed，也就是说 Postgres 和 ClickHouse 在系统里分工不同：一套存元数据和业务对象，一套扛时序查询。
归组这一步落在 packages/fingerprint，README 把它描述为 telemetry fingerprinting helpers。worker 进程负责 incident grouping 和后台任务，agent 编排也在 apps/worker 里。最后的调查环节由 agent runner 接口承接，README 用的是「pluggable investigation runtimes」这个说法，意味着 runner 是可替换的，而不是写死一种实现。
默认实现叫 community runner，README 的原话是它「records a local incident summary」。这句是整篇文档里信息量最大的一句，也是很多人容易读漏的一句：默认 runner 产出的是摘要记录，不是自动执行修复。仓库描述里写的 self-heal 是产品方向，社区版当前给出的默认能力要按摘要来理解。
跑起来只需要三条命令，但前置条件别跳过
README 的 Quick Start 给的前置条件是 Node.js 20+、pnpm 9+ 和 Docker。装依赖是 pnpm install，起本地栈是 docker compose up -d，然后跑迁移 pnpm --filter @superlog/db db:migrate，最后 pnpm dev。
默认端口三个：Web 在 5173，API 在 4100，OTLP intake 在 4101。这里有个容易踩的点，4101 是给采集端用的，不是给人看的，浏览器打开它不会得到界面。类型检查用 pnpm typecheck。
安装路径还有一条 README 主推的方式，用 coding agent 里的 skills：Run npx skills add superloglabs/skills --all，然后让 agent 用这些 skills 把 Superlog 装进当前项目。这条路径把安装动作交给了 agent，好处是省事，代价是你要接受 agent 去改你的项目文件。README 没有说明 skills 具体会写入哪些配置，如果你对仓库改动敏感，建议先走上面那四条命令的手动路径。
community runner 是默认值，也是当前最大的限制
把 self-heal 当成开箱能力是这个项目最容易产生的误判。README 在描述社区版内容时，对 agent runner 的表述是「Agent runner interfaces for pluggable investigation runtimes」，紧接着一句是「A default community agent runner that records a local incident summary」。接口是开放的，默认实现是记录摘要。
这意味着如果你想要的是「系统发现异常后自动回滚、自动改配置、自动提 PR」，社区版仓库当前没有给出这样的默认行为。要实现这类动作，路径是在 apps/worker 的 agent runner 接口上自己接一个运行时，而 README 没有提供 runner 的接口签名、注册方式或配置键，这些只能去读源码。
第二个限制来自归组本身。归组是双刃剑：把噪音压成 incident 的前提是 fingerprint 规则足够准。规则过宽，两个不相关的故障会被合并成一条 incident，值班的人会沿着错误的线索查下去；规则过窄，incident 数量又回到噪音水平。packages/fingerprint 是这套判断的核心，README 只说它是 helpers，没有给规则说明。上生产前，这一层必须拿你自己的历史数据回放验证。
和 SigNoz 的差别在归组这一层，不在 OTLP 接入
同类的自托管 OpenTelemetry 方案里，SigNoz 是常被拿来对比的一个。两者都接收 OTLP，都自托管，都提供 traces、logs、metrics 的查询界面。差别不在接入层，而在接入之后系统替你做了什么。
SigNoz 的路线偏向传统可观测性平台：你定义告警规则、阈值和通知渠道，系统按规则触发，判断逻辑由人写死。Superlog 的路线是把判断前移到归组：先由 fingerprint 把信号压成 incident，再由 agent runner 去调查这个 incident。前者是可预测的，后者在归组准确的前提下能省掉大量人工写规则的成本。
代价也很直接。SigNoz 的告警规则是你写什么就触发什么，行为可解释；Superlog 的 incident 是系统归出来的，你需要信任 fingerprint 的判断，并且接受它在规则不准时给出的错误分组。另外 Superlog 的社区版 agent runner 默认只记录摘要，调查深度受限于你接的运行时；SigNoz 在这条链路上不承诺 agent 能力，也就没有这个预期落差。选哪一个，取决于你更怕漏报还是更怕误分组。
维护成本主要来自双存储和 worker 编排
这套架构要同时维护 Postgres 和 ClickHouse。README 说 Postgres 承载 Drizzle schema 和 migrations，telemetry 查询走 ClickHouse。两套存储意味着两套备份策略、两套容量规划和两套升级路径，对只有一两个人的平台团队来说，这是实打实的运维负担。
升级方面，仓库没有检索到 release 记录，README 也没有给版本兼容策略或迁移回滚说明。packages/db 里有 migrations，但跨版本升级时 schema 变更如何处理，文档没有交代。这意味着升级前你需要自己在测试环境跑一遍 pnpm --filter @superlog/db db:migrate，确认迁移脚本的行为。
许可证是 Apache License 2.0，仓库根目录有 LICENSE.md。这是宽松许可证，允许商用和修改，但 README 同时说明了存在托管云版本，也就是 open-core 模式。哪些能力留在社区版、哪些只在云版，README 没有列清单。如果你打算基于社区版做二次开发或对外提供服务，需要先确认这条边界，具体条款以 LICENSE.md 原文为准，这里不做法律判断。
谁该现在装，谁该再等等
适合现在动手的是这类团队：已经有 OTLP 数据出口，愿意自己跑 Docker 和数据库，痛点是告警噪音而不是缺少告警，并且团队里有能读 TypeScript 源码的人，因为 agent runner 的接口细节需要从 apps/worker 里挖。
该再等等的是另一类：需要成熟告警路由、值班排班、SLA 统计的团队，这些在 README 里没有出现；以及把 self-heal 理解为自动修复的团队，社区版默认 runner 只写本地摘要。
验证顺序建议这样排：先跑通 docker compose up -d 和 db:migrate，确认本地栈能起来；再往 4101 发一批你自己的真实 OTLP 数据，看 packages/fingerprint 归出来的 incident 数量和你人工判断的故障数量差多少；最后读 apps/worker 里 community runner 的实现，判断它的摘要输出能不能直接进你的值班流程。这三步任何一步不成立，继续投入的时间就要重新算。
编辑结论
如果你已经在往某个 OTLP 端点发数据，又想在一个自托管的工作区里把噪音信号先归组成 incident 再谈调查，Superlog 值得花一个下午跑通 docker compose up -d 这条链路，重点验证三件事：packages/fingerprint 的归组规则在你的真实数据上会不会把不同故障合并成一条 incident；community runner 写出的摘要是否已经覆盖你的值班判断；以及 ClickHouse 与 Postgres 并存的部署成本你是否愿意承担。如果你要的是开箱即用的告警路由、值班排班和成熟的规则引擎，现在不要选它，社区版的 agent runner 记录的是本地摘要，不是自动修复动作，把它当成能替你改代码的系统会直接失望。
社区笔记